Hi Arun,

I had a similar problem. Rendering did work faster when I put a sleep() statement into my mouse driver:

static int AM_Poll(void)
{
_sleep(0.05);
return 1;
}

My assumption is that the mouse is polled very (too) often and the sleep() frees some time slices to the processor allowing it to spend this time on rendering. Greg suggested that I rather put the sleep() into the GsSelect() routine which is probably better.

Georg


----- Original Message ----- From: "Arun Ram M" <arunra...@gmail.com>
To: <nanogui@linuxhacker.org>
Sent: Monday, August 20, 2012 5:05 AM
Subject: [nanogui] Performance : FLTK + Nxlib + Nano-X


Re posting because the earlier post was sidetracked with freetype
support related discussion.

Hello,

Am using FLTK 1.3 , Nxlib (development head) , Nano-X (development
head) for an ARM touch screen target.

I upgraded it from FLTK 1.1.7+Nxlib 0.45 + Nano-X .91 to add UTF-8 support.

On a button press, am displaying text in an information box. I see a
long delay for the text to be rendered. But if i keep the touch screen
pressed after the button press, the rendering is quick.

I tried this with FLTK1.1.7 + the latest of nxlib+nano-x and this
delay was not seen.

Am using a touch screen device. So i reduced touch screen reads by
half. This improved performance but reduced the touchscreen response
itself.
I was using the same touch screen drivers with the earlier versions
without any sort of performance delay.

It seems like some sort of threading issue with the newer versions of
the code, but am unable to figure out. Any ideas ?

Thanks,
Arun

---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org



---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org

Reply via email to