On Fri, Mar 13, 2009 at 07:39:21PM +0100, Ricardo P. Jasinski wrote: > It is visually noticeable that what is taking so much time is the > drawing part of the process. The screen (window) goes blank for a > while, and then it gets updated almost at once (from right to left, > since we are in portrait mode). The time it stays blank is roughly > proportional to the number of elements (e.g., characters) that must be > drawn.
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. it sounds like you need to look at the character draw routines. are you using truetype, or the plain bitmap fonts? 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. this is technically a cousin of 0.89. merging with 0.90 and later has been on my todo list for years, but since doing so won't help my employer ship product, it's necessarily always at the bottom of the list. 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 . 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 . in hindsight, creating a low-level DrawBitmap function (as indicated in engine/devdraw.c) would likely give the widest benefit. how deep down the rabbit hole do you want to go? (= -- 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
