Subject:
Re: [nanogui] Ways to speed up a simple application?
From:
"Ricardo P. Jasinski" ####@####.####
Date:
13 Mar 2009 18:40:23 -0000
Message-Id: <ee9633130903131139h193df532w70d2d1c560aced52@mail.gmail.com>
Hi John,
thanks for sharing your thoughts. Please let me elaborate a little more on
the description of our system.
Our hardware has two video outputs: one regular DB-15 connector for standard
PC monitors (SVGA resolution) and one LVDS output for a TFT LCD display
(LG-Philips LB104S01-TL01) which is always attached.
The hardware that we based our design on featured only the SVGA output; so,
we just added a custom hardware component that converts the VGA signals to
the serial LVDS interface used by the LCD. It has yielded excellent results
and there is no flickering at all.
I think I've used a poor choice of words when I said "switching between
screens"; we are actually switching between application windows, which
happen to be maximized and take up the full screen. Sorry if it mislead you.
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.
Thanks again,
Ricardo.
2009/3/13 Bosch, John <...>
> Hi Ricardo Jasinski,
>
> I have not used nano-x but do get the emails and have worked on TFT
> displays as well as rasterized. TFT are nice and have great clarity.
> The rasteriezed display was a major pain (very bad and contradictory
> documentation on the glass) with only okay results on clarity. And the
> processor chip did not really support rasterized as advertized. Current
> design has no problem flipping between screens instantaneously. You may
> be limited by the hardware design.
>
> I would optimize the driver.
> Use three buffers. One that is always being copied from to the display
> buffer while the other is getting rendered to, after each copy to the
> display buffer flip which one is getting copied from and which one is
> getting rendered to.
>
> Render ---> BUFA
>
> BUFB -------> DISPLAYBUFF
>
>
>
> BUFA -------> DISPLAYBUFF
>
> Render ---> BUFB
>
>
> The display buffer should be DMA to the actual display. The DMA should
> drive the flip, if I remember correctly.
>
> This works very well with no flicker in the display at all and no
> worries for the application level in how and when it updates the
> display.
>
>
>
>
> -----Original Message-----
> From: ####@####.#### ####@####.#### On Behalf Of
> Ricardo P. Jasinski
> Sent: Thursday, March 12, 2009 9:41 PM
> To: ####@####.####
> Subject: [nanogui] Ways to speed up a simple application?
>
> 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.
>
