> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
