nanogui: Ways to speed up a simple application?
Subject:
Re: [nanogui] Re: Ways to speed up a simple application?
From:
"Ricardo P. Jasinski" ####@####.####
Date:
19 Mar 2009 18:47:45 -0000
Message-Id: <ee9633130903191146i36eac12fq3ad739ceb324d156@mail.gmail.com>
> at the FLTK level, this might be as simple as calling
> Window::set_double_buffer() .
Thanks, that did the trick! =)
There was no visible difference in the rendering time, but we no
longer stare at a blank screen while flipping through the pages.
> start working on nano-X only if you've determined that freetype is a
> problem. as a sanity check, see if you use a built-in font (say,
> "System") and see if the speed changes.
I ran some quick tests:
1. Using the default system font, page rendering went from 8 secs
down to less than 1 sec. Very nice to see!
2. I converted DejaVu Sans 18 bold to a C source file using
convfnt, replaced the system font with it and recompiled nano-X. So,
this became the new "System" font. Rendering delay is still under 1
sec, which is nice. However, I lost anti-aliasing, and that makes the
font almost unreadable... It won't be a solution, then.
I'm still not sure what conclusions we can draw from this...
> do you have a profiler? what is it showing you?
>
> if freetype is eating all your cycles, working on nano-X is not going to
> help you.
Unfortunately, gprof is not supported by our toolchain, so we are a
little in the dark here.
> low or zero-overhead copy/write loops are usually a big win for
> graphics. I imagine that an accelerator like the Epson can take
> advantage of DRAM's constant refreshing for blitting. I don't know how
> much of this would be feasable with your hardware.
Things that can be easily accelerated in hardware are logical and
arithmetic operations, operating on a few words of data and producing
another word as an output. For instance, given 32 "background" bits
and 32 "foreground" bits I could perform any kind of operation on
them. However, loop constructs are not that hardware-friendly.
Another issue is that my framebuffer memory (SDRAM) is physically the
same as my program memory, so any hardware accelerator that requires
memory access would "dispute" bandwidth with the processor itself and
the VGA controller.
> on the 68331 I was using, knowing the C constructs that translated into
> zero-overhead loops gave big speed wins. (the i386 equivalent to "rep
> stos")
This is good to know. I'll keep that in mind in case I have to go that
far (compare C source code with the compiled assembly output). Right
now, I don't have a clue what my CPU instructions look like.
> removing per-pixel overhead when doing 1-to-screenbpp expansion writes
> gave me a significant speed gain even on a dumb framebuffer.
So this would be a good place to hack. Thanks.
> sounds like you need to answer the following before worrying about
> nano-X:
>
> - is FLTK double-buffering?
I believe so, since now I have enabled it on a per-window basis with
set_double_buffer(). However, the time needed to draw the window is
approximately the same in either case.
> - is freetype eating your CPU time?
If I had gprof, I think I could determine it from compiling both
nano-X and my application with profiling flags. Maybe it would be
better to LINK_APP_INTO_SERVER in nano-X config. However, without a
proper profiling tool, do you have any other ideas on how I could find
that out?
I believe I could port my application to a desktop PC and then profile
it there... It would be a reasonable amount of work, and I'm not sure
that the results could be trusted... But, anyway, it is something I
could try.
Thanks again for your great help and excellent ideas!
Ricardo.
