On Tue, Mar 17, 2009 at 10:47:23PM -0300, Ricardo Jasinski wrote: > Aaron J. Grier <agr...@poofygoof.com> wrote: > > to mitigate this a little, don't clear the existing screen until the > > new one is ready. draw the new screen to an off-screen buffer, then > > copy off-screen to on-screen. this won't make the change operation > > any faster, but it will mean less time staring at a blank screen. > > Good point, I'll look into that. However, I'm not sure how it could be > done, since all I do is update the button labels; everything else is > done after the callback function ends, and control returns to the > fltk::run loop.
at the FLTK level, this might be as simple as calling Window::set_double_buffer() . > What do you think, should we implement these fonts as "built-in" / > "compiled-in" fonts? Do you believe this could result in a significant > speed boost? 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. 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. > Maybe [1-bit expansion] this is something I can implement in our > system, since we are using a soft-core processor and custom > instructions may be added to its instruction set. Btw, maybe you have > an idea for an operation that could speed things up significantly if > implemented in hardware? 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. 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") > > in hindsight, creating a low-level DrawBitmap function (as indicated > > in engine/devdraw.c) would likely give the widest benefit. > > Do you mean in case I had hardware accelerated graphics? Or is it > something I can do with the framebuffer only? removing per-pixel overhead when doing 1-to-screenbpp expansion writes gave me a significant speed gain even on a dumb framebuffer. > > how deep down the rabbit hole do you want to go? (= > > Let me think. I think I would start with the first choice in the list > below, and go down all the way to the bottom, until I achieve the > performance we need: > - some structural change in my application source code > - some hardware tweaking that could be done without touching any > source code > - driver optimizations that could be done without touching the > application code > > And, what would be the most fun of all, implement some sort of > hardware acceleration, but I don't think I'd have the time to do that > within our current deadlines. Anyway, given enough dead ends, I've > seen many deadlines change... :) sounds like you need to answer the following before worrying about nano-X: - is FLTK double-buffering? - is freetype eating your CPU time? nano-X might end up being a wild goose chase... -- Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
