> ---------- Forwarded message ---------- > From: Aaron J. Grier <agr...@poofygoof.com>
> 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. > it sounds like you need to look at the character draw routines. are you > using truetype, or the plain bitmap fonts? We are using freetype2, the only font we use is DejaVu Sans Bold at 48, 36, 30, 24 and 18 points. We call setfont() one time for each of these values when starting up the application; if we didn't, the application would hang for a while when the font was used for the first time. 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? > I recall putting quite a bit of work into speeding up font draws on the > branch at work, but only some of these changes made it back into the > official trunk. the most radical outstanding change was the > introduction of a low-level text draw routine, which I heavily optimized > for the hardware at hand. the code is available at > http://frye.com/~aaron/microwin-frye-nanosteve.1.tar.bz2 . "nanosteve" > is just an internal name of the branch. Thanks! I took a look at your code and the datasheet for the 506 graphics controller. Thanks to that and Michael's previous messages, I can understand the role of the bitblt engine. As I see, sometimes you can just sit back and feed its fifo with data. Nice! > one of the worst CPU-sucking offenders for text draw (which still > appears to be in the CVS tree) is drawbitmap, which draws > pixel-by-pixel. the per-pixel overhead is a killer -- just moving > direct framebuffer access into the loop saves a significant number of > cycles. see FB7k_DrawText() in drivers/scr_fryebox.c . I see. So, if I decide to start hacking the code this would be one of the most promising starting points. > a lot of accelerated video cards also have the ability to do 1bpp > expansion to the native screen depth, and this can give even more speed. > see FB7kBitBLT_DrawText() in drivers/scr_fryebox.c . Awesome. Maybe 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? > 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? > 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... :) Thanks for sharing your thoughts! Ricardo Jasinski. --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
