nanogui: Ways to speed up a simple application?
Subject:
Ways to speed up a simple application?
From:
"Ricardo P. Jasinski" ####@####.####
Date:
13 Mar 2009 02:42:08 -0000
Message-Id: <ee9633130903121941n2de7bfd9g515fc1960119f60e@mail.gmail.com>
Hi everyone,
we are currently developing an application using nano-X, FLTK2 and uClinux;
our hardware platform is a 32-bit Nios-II processor running at 100 MHz.
Our application presents a series of screens sequentially. Each screen
consists of some text, shown over a background image (jpg/png). Whenever the
user presses a button, the application should advance to the next screen.
This screen switching process should happen as fast as possible.
We have a working prototype, and it looks really great when the application
is running, but unfortunately there's a noticeable lag when switching
between the screens. I have profiled it (with my stopwatch) and determined
that it takes up to 8 seconds to flip from one screen to the next (this
figure is for 1.000 characters drawn on the screen).
The screen changing takes place inside a callback function, which is
activated when the user presses any button (this button is a flt::Button
widget). We have profiled this callback, and it takes about 100 milliseconds
altogether, including a call to fltk::redraw(). It is evident that most of
the time is spent after the callback is finished, when the process returns
to the fltk::run() loop.
Just to be clear, all windows are created when the application is
initialized, which takes about 30 seconds. During this period, all fonts and
images are created (with SharedImage::get and fltk::setfont). Afterwards,
the screen changing is done by updating the widgets (labels) and bringing to
front the appropriate window (via GrRaiseWindow and GrSetFocus).
I'll give a little more detail further in this message, but the essential
question is: con you think of any way (or ways) to speed up this process? I
really feel that it shouldn't be taking that long just to draw a few strings
of text.
Here are some suggestions of my own:
- create duplicate windows and update the widgets before the user presses
any button. This way, the screens would be drawn beforehand, and not take
any time after the button press. The drawback is that many duplicate windows
would have to be created and updated, since the text contents also depend on
the button that has been pressed
- profile and optimize any drivers and low-level code where all this time
might be being spent
- draw everything off screen and later just copy it to the visible
region, somehow
- (your ideas here, please!)
Here's a little more detail:
- screen resolution: 600x800 (portrait mode), framebuffer
(Packed-16bit-5/5/5)
- amount of text per screen: usually between 50 and 250 characters (UTF8)
- all text is drawn as the "text" attribute of fltk::Button and
fltk::Widget objects
- we are using a slightly modified fbportrait_left.c file, provided by Uwe
Klatt in this mailing list (thanks, Uwe!)
- the screen is not drawn any faster when there's not a background image
- the application doesn't need to process mouse input; users interact via
special hardware buttons which, when pressed, notify the application via
GrInjectKeyboardEvent. The fltk::Button widget receives this event because
the Button::shortcut attribute is set accordingly.
Another thing that I'd appreciate to have some confirmation on is: we are
running the application mode in portrait mode (setportrait left). I have a
slight impression that things would be faster in "normal" (landscape) mode.
Does it make any sense?
Please guys, any help on this matter would be greatly appreciated, since in
the current stage our application is not really "usable". We are running out
of ideas that can be easily tried, so before starting any other tests I
would really like to hear from you guys!
Thanks a lot for any thoughts,
Ricardo Jasinski.
