Input latency in OpenGL?

SDL Development
1

I’m on a Windows box with an ATI Radeon X1950 and the latest drivers. In my
programs, keyboard and joystick events seem to take longer to be processed in
OpenGL than in software or DirectX. If other OpenGL/SDL programs are lagging,
I’m not seeing it.

Even if it is just me, even if this delay won’t be noticed in real gameplay, I’m
interested in whatever I can do to improve input response time. I use Bob
Pendleton’s Fast Events but it doesn’t appear to make a difference.

2

Try updating your drivers…video card and mobo both.

I’ve seen this a lot and updating the drivers usually fixes it> ----- Original Message -----

From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Iori Branford
Sent: Friday, January 18, 2008 10:06 PM
To: sdl at libsdl.org
Subject: [SDL] Input latency in OpenGL?

I’m on a Windows box with an ATI Radeon X1950 and the latest drivers. In my
programs, keyboard and joystick events seem to take longer to be processed
in
OpenGL than in software or DirectX. If other OpenGL/SDL programs are
lagging,
I’m not seeing it.

Even if it is just me, even if this delay won’t be noticed in real gameplay,
I’m
interested in whatever I can do to improve input response time. I use Bob
Pendleton’s Fast Events but it doesn’t appear to make a difference.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

Already got Catalyst 8.1 today and redid my chipset drivers yesterday. No dice.

Alan Wolfe <Atrix2 cox.net> writes:>

Try updating your drivers…video card and mobo both.

I’ve seen this a lot and updating the drivers usually fixes it

4

What version of Windows are you on? I’ve heard some things about Vista being slower with GL.

A friend of mine who has comparable computer stats to mine [geForce 8600 (same video card) and Core 2 Duo (2.2gHz each core on his; 2.4 gHz on each core of mine)] and the only really difference is the OS. I’m on Vista, he’s on XP. Even on full-screen and disabling a bunch of my services, GL/SDL was still actually 10-20 fps behind his (I was still rendering around 90-120 for complex screens) (he was about 120-150).

Taylor> To: sdl at libsdl.org

From: ioribranford at gmail.com
Date: Sat, 19 Jan 2008 07:22:41 +0000
Subject: Re: [SDL] Input latency in OpenGL?

Already got Catalyst 8.1 today and redid my chipset drivers yesterday. No dice.

Alan Wolfe <Atrix2 cox.net> writes:

Try updating your drivers…video card and mobo both.

I’ve seen this a lot and updating the drivers usually fixes it

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Climb to the top of the charts!? Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

5

I’ve found something that helps: disabling vsync.

The next problem, then, is how to do something during the vsync waiting period.

6

Your problem then might be that you are not handling all the events that
have happened this far, before you start to draw your scene.

You should have something like this:
Event loop taken from SDL Wiki->SDL_PollEvent

SDL_Event event; /* Event structure */

while(game_running) {
/* Check for events /
while(SDL_PollEvent(&event)) { / Loop until there are no events left
on the queue /
switch(event.type) { / Process the appropiate event type /
case SDL_KEYDOWN: / Handle a KEYDOWN event /
printf(“Oh! Key press\n”);
break;
case SDL_MOUSEMOTION:
.
.
.
default: / Report an unhandled event */
printf(“I don’t know what this event is!\n”);
}
}
// Update positions etc according to the events that have been handled
// Draw next frame
// Swap buffers to show the new graphics
}On Saturday 19 January 2008, Iori Branford wrote:

I’ve found something that helps: disabling vsync.

The next problem, then, is how to do something during the vsync
waiting period.

7

I’m on a Windows box with an ATI Radeon X1950 and the latest drivers. In my
programs, keyboard and joystick events seem to take longer to be processed in
OpenGL than in software or DirectX. If other OpenGL/SDL programs are lagging,
I’m not seeing it.

Even if it is just me, even if this delay won’t be noticed in real gameplay, I’m
interested in whatever I can do to improve input response time. I use Bob
Pendleton’s Fast Events but it doesn’t appear to make a difference.

That’s good the hear, it shouldn’t make a difference.

Check a couple of things, how are you managing buffer swapping in
OpenGL? Also, check to see if any of your screen settings are
synchronized with V-Blank. Those settings may be different for OpenGL
and the other graphics systems you mentioned. Check to see if you are
using glFlush or glFinish at the end of your gl rendering calls. You
"should" call glFlush and probably not call glFinish. The last thing is
to make sure you are processing all pending events before you swap the
buffers.

Bob PendletonOn Sat, 2008-01-19 at 06:06 +0000, Iori Branford wrote:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±-------------------------------------+

8

Turns out I was drawing the scene way more times than I needed, probably causing
excess v-blank waiting. When the draw rate is clamped to my target framerate,
instead of drawing after every input/logic update, the latency is practically
gone. All I need now is a way to calculate the screen refresh rate so I can
clamp the draw rate to that instead.

9

Turns out I was drawing the scene way more times than I needed,
probably causing excess v-blank waiting. When the draw rate is
clamped to my target framerate, instead of drawing after every
input/logic update, the latency is practically gone.

That certainly explains it. :slight_smile:

All I need now is a way to calculate the screen refresh rate so I
can clamp the draw rate to that instead.

That’s not how you’d normally do it - at least not in any normal
applications. Might work in a simulator, console or arcade machine
where you can guarantee that you always maintain a steady full frame
rate, ie constantly rendering one frame per display refresh - but
even then, you may have to deal with different systems (ie PAL vs
NTSC in consoles) having different display refresh rates. Normally,
you’ll also have to deal with the frame rate sometimes or constantly
dropping below the display refresh rate, in predictable or
unpredictable ways.

The best you can do, that’s still generally safe, is to time each
frame, grab all input and (one way or another) advance your logic to
match the expected time of the next frame displayed. There are many
ways of doing this (scaling logic “steps” by delta times, fixed logic
frame rate, logic in a separate fixed rate thread etc), but the
general idea is that you make your application somehow dynamically
scale with the actual rendering frame rate. You need to separate
logic timing from video frame timing.

For extremely sensitive applications (fast games and simulators), you
may improve input timing accuracy by gathering input in a high
priority background thread that timestamps events as they come in.
(It’s a tried and tested solution for audio/MIDI applications on
reasonably well behaved multimedia operating systems.) That said, I’m
not sure you can actually do this portably with SDL, and in my
experience, it doesn’t work reliably on Windows systems; at least not
with a single CPU/single core. It’s a technically sound design for
suitable platforms, but you can’t assume that your average general
purpose OS will handle it properly.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Sunday 20 January 2008, Iori Branford wrote:

10

IIRC, SDL doesn’t allow to run event polling and rendering code in separate
threads. Am I wrong?..On Wednesday 23 January 2008 16:50:47 David Olofson wrote:

For extremely sensitive applications (fast games and simulators), you
may improve input timing accuracy by gathering input in a high
priority background thread that timestamps events as they come in.

–
Sincerely,
Vladimir “Farcaller” Pouzanov Hack&Dev Team
PGP/GPG: 0x3A40FF29 http://hackndev.com
Fingerprint: FA36 877A 2DC3 B56F CAB5 7DB3 4C97 A596 3A40 FF29
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080123/e40e6b58/attachment.pgp

11

If it doesn’t allow event polling on a separate thread, you can pass events easily enough doing something like this:

Main thread polls events as part of the execution loop. When it receives an input event, instead of handling it, (which could end up throwing off the timing of the main thread, which should remain as uncluttered as possible and dedicated to drawing,) it creates a simple object describing the input and pushes it onto a global-scope queue.

Running in another thread you have a very simple infinite loop: Check to see if the queue is not empty. If it isn’t, pop the first entry off the queue, interpret the data, and call the game engine’s input-handling routine, which is now run on the dedicated input-handling thread. Then, optionally pop all remaining events off the queue and discard them (prevents event-overload), and sleep() or SDL_Delay() for the duration of one frame, wash, rinse, repeat until program ends.> ----- Original Message -----

From: farcaller@gmail.com (Vladimir Pouzanov)
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Wednesday, January 23, 2008 8:27:42 AM
Subject: Re: [SDL] Input latency in OpenGL?

IIRC, SDL doesn’t allow to run event polling and rendering code in
separate
threads. Am I wrong?..

–
Sincerely,
Vladimir “Farcaller” Pouzanov Hack&Dev Team
PGP/GPG: 0x3A40FF29 http://hackndev.com
Fingerprint: FA36 877A 2DC3 B56F CAB5 7DB3 4C97 A596 3A40 FF29

12

That’s what I’m using now. I’ve been thinking of a way to reduce number of
threads, but currently 4 is the minimum I have:

  • main thread to fetch events; render and play async sounds
  • second thread to handle events
  • third one for network I/O
  • fourth for in-game python interpreter that handles logic.

Sometimes that’s a hell to debug…On Wednesday 23 January 2008 20:21:05 Mason Wheeler wrote:

If it doesn’t allow event polling on a separate thread, you can pass events
easily enough doing something like this

–
Sincerely,
Vladimir “Farcaller” Pouzanov Hack&Dev Team
PGP/GPG: 0x3A40FF29 http://hackndev.com
Fingerprint: FA36 877A 2DC3 B56F CAB5 7DB3 4C97 A596 3A40 FF29
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080123/4ecd7af6/attachment.pgp