nanogui: Ways to speed up a simple application?
Subject:
Re: Ways to speed up a simple application?
From:
"Aaron J. Grier" ####@####.####
Date:
16 Mar 2009 19:23:27 -0000
Message-Id: <20090316192218.GC3628@arwen.poofy.goof.com>
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." | ####@####.####
