SDL events much slower than GLUT input on Linux/Mesa

Hi
I have an x86 linux machine with software renderer. Recently
I decided to advance to SDL from GLUT, but I’ve noticed that
SDL keyboard events introduce annoying latency, whilst
glutKeyboardFunc supports keyboard events in realtime. (Setting
sdl program’s niceness to -20 and running it as root didn’t help).

What could possibly cause this anomaly?
I’ve attached extracts from both versions.

Thanks in advance
Wieslawa Strakowska----------------------------------------------------------------------
Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c
-------------- next part --------------
A non-text attachment was scrubbed…
Name: glutfast.c
Type: application/octet-stream
Size: 1171 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050416/8462b4c9/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdlslow.c
Type: application/octet-stream
Size: 2047 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050416/8462b4c9/attachment-0001.obj

Whereas the GLUT built-in event loop most certainly processes all
pending input events before rendering another frame, your SDL code
processes only one SDL event per frame, allowing events to queue up
if your frame rate is lower than the rate of incoming events.

  • if(SDL_PollEvent(&event)) {
  • while(SDL_PollEvent(&event)) {

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Saturday 16 April 2005 12.14, kaczfan at poczta.fm wrote:

Hi
I have an x86 linux machine with software renderer. Recently
I decided to advance to SDL from GLUT, but I’ve noticed that
SDL keyboard events introduce annoying latency, whilst
glutKeyboardFunc supports keyboard events in realtime. (Setting
sdl program’s niceness to -20 and running it as root didn’t help).

What could possibly cause this anomaly?
I’ve attached extracts from both versions.

I followed your advice and modified the code (using "do while"
instead of “while”, though), but the problem seems to be of
different kind - the event is supported, but only after a few
frames are drawn. (Thanks for your help anyway, I’ll make use
of it in future). It looks like the SDL_PollEvent is informed about
the occurrence of the event with slight delay.

Perhaps this is kernel’s fault, (I’m using 2.4.26 slackware default)
does anybody know anything about it? Is there any way

Wieslawa Strakowska

PS Sorry I attached source code as “non-text” previously but
I’m a newbie on mailing lists.------------------------------------------------------------------
Teraz na tapecie mamy najwiekszego z silaczy.
Sciagnij >> http://link.interia.pl/f1873 <<

Why a do-while loop? A do-while wouldn’t work properly unless you went to all
the trouble of making it behave exactly like a while loop.

There’s another problem with the SDL code, too. It only increments X after
it calls glRotatef, NOT before. That guarantees there’s a delay of one more
frame before the change to delta effects the position of the cube.

How does this attached code work for you? It uses a proper while loop for
events, increments X before rotating, and uses the SDL_EVENTTHREAD flag. I
also slowed down the cube so I could see it.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdlfast.c
Type: text/x-csrc
Size: 2175 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050416/e2377b8c/attachment.cOn Saturday 16 April 2005 07:04, Wieslawa Strakowska wrote:

I followed your advice and modified the code (using "do while"
instead of “while”, though),

Wieslawa Strakowska wrote:

I followed your advice and modified the code (using "do while"
instead of “while”, though), but the problem seems to be of
different kind - the event is supported, but only after a few
frames are drawn. (Thanks for your help anyway, I’ll make use
of it in future). It looks like the SDL_PollEvent is informed about
the occurrence of the event with slight delay.

sdl, at least on linux, does event polling in a thread, and to not hook
the cpu, uses SDL_Delay() in every iteration. your 2.4.26 kernel has a
timer granularity of 10ms so events might be delayed about 0-10ms.

you could give the sdl-fastevents library a try.

best regards …
clemens

sdl, at least on linux, does event polling in a thread, and to not hook
the cpu, uses SDL_Delay() in every iteration. your 2.4.26 kernel has a
timer granularity of 10ms so events might be delayed about 0-10ms.

I think I wouldn’t notice 10ms delay. I estimate it to 300-400ms. I

you could give the sdl-fastevents library a try.

Oh, I gave. Same effect. I’m going to ask my friend to test it on his
GNU/Linux. Now I’m trying to determine whether the Mesa renderer could
be the reason.

Wieslawa Strakowska----------------------------------------------------------------------
Wszystko o MOTORYZACJI >>> http://link.interia.pl/f186a

There’s another problem with the SDL code, too. It only increments X after
it calls glRotatef, NOT before. That guarantees there’s a delay of one more
frame before the change to delta effects the position of the cube.

The problem doesn’t lay in one frame. Actually, there are many more frames
drawn before the event takes an effect.

How does this attached code work for you? It uses a proper while loop for
events, increments X before rotating, and uses the SDL_EVENTTHREAD flag. I
also slowed down the cube so I could see it.

I tried your code but it’s still very inertial (delays seem to be of hundred
miliseconds range). Does the program (either yours or mine) reveal the behavior
described by me on your system?

Wieslawa Strakowska----------------------------------------------------------------------
Wszystko o MOTORYZACJI >>> http://link.interia.pl/f186a

400ms!? That IS horrible. I get nothing like that, something must be
seriously wrong somewhere. I’d try a systrace, to see what’s happening
when…On Monday 18 April 2005 13:43, Wieslawa Strakowska wrote:

I think I wouldn’t notice 10ms delay. I estimate it to 300-400ms. I

you could give the sdl-fastevents library a try.
Oh, I gave. Same effect. I’m going to ask my friend to test it on his
GNU/Linux. Now I’m trying to determine whether the Mesa renderer could
be the reason.

Wieslawa Strakowska