Nasty Event delay on debian

Hi,
I just switched my operating system from windows 2000 to Debian (lenny). SDL used to work great for me, but when now there are significant delays in input events. When i click the mouse or press a key, it can take up to 5 seconds for the event to reach my application, and sometimes it doesn’t reach it at all. Framerate is still really nice, and mouse position is coming in instantly like normal, its just events like mouse clicks and key presses. I doubt its my code, because it was working just fine before, and i haven’t changed it at all. Also, if i use OpenGL instead of 2d stuff, similar issues except that mouse position is also horribly delayed.

Has anyone seen this before or know what it could be? I’m hoping it’s just some configuration mismatch somewhere. I’m using SDL 1.2 in C with GCC. It’s the default installation of SDL from Debian package system.
Any help would be great.

Hi.

Does a minimal SDL application demonstrate the same problem? Write an
app where when you move the mouse the colour of the screen changes in
response to the mouse position, or something along those lines.

– Brian.On Thu, Nov 12, 2009 at 1:14 AM, apefish wrote:

Has anyone seen this before or know what it could be? I’m hoping it’s just
some configuration mismatch somewhere. I’m using SDL 1.2 in C with GCC. It’s
the default installation of SDL from Debian package system.
Any help would be great.


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

Don’t know if it’s the same thing, but I’ve noticed that I need to hold down the
mouse button for a longer time in the Linux builds of my game to get an effect.
Like, in the Windows version, you just tap the mouse button and it registers,
but in the Linux (Ubuntu 32 and 64 bit, that is) version, sometimes the click
isn’t registered if you tap it as fast as in Windows. It’s not a five second
delay like you’re getting, but it’s kinda annoying sometimes when the click
isn’t registered.

I’m not having any problems on Debian Lenny, but I’m willing to help.
The package hasn’t changed since I installed it.

Jonny DOn Thu, Nov 12, 2009 at 11:01 AM, Christian Knudsen wrote:

Don’t know if it’s the same thing, but I’ve noticed that I need to hold down the
mouse button for a longer time in the Linux builds of my game to get an effect.
Like, in the Windows version, you just tap the mouse button and it registers,
but in the Linux (Ubuntu 32 and 64 bit, that is) version, sometimes the click
isn’t registered if you tap it as fast as in Windows. It’s not a five second
delay like you’re getting, but it’s kinda annoying sometimes when the click
isn’t registered.


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

How are you measuring the time it takes for an event to reach your
application’s event processor? How can you be sure the delay isn’t in
the feedback? Given no other information, some kind of audio or visual
latency seems much more likely to me any day than a delay on receiving
user input events!On Wed, Nov 11, 2009 at 8:14 PM, apefish wrote:

Hi,
I just switched my operating system from windows 2000 to Debian (lenny). SDL
used to work great for me, but when now there are significant delays in
input events. When i click the mouse or press a key, it can take up to 5
seconds for the event to reach my application, and sometimes it doesn’t
reach it at all. Framerate is still really nice, and mouse position is
coming in instantly like normal, its just events like mouse clicks and key
presses. I doubt its my code, because it was working just fine before, and i
haven’t changed it at all. Also, if i use OpenGL instead of 2d stuff,
similar issues except that mouse position is also horribly delayed.

Has anyone seen this before or know what it could be? I’m hoping it’s just
some configuration mismatch somewhere. I’m using SDL 1.2 in C with GCC. It’s
the default installation of SDL from Debian package system.
Any help would be great.


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


http://codebad.com/

Thanks for helping, I managed to find the problem: on Linux, SDL seems to generate more mousemotion events (true?), and a bug in my code was causing my event loop to bail on the first mousemotion event, so it would get through one mousemotion event per frame, which delayed all the other events. I feel dumb for that bug.
Anyways, it works good now but I still have the same problem with OpenGL. I’ve created a pretty minimal application that just draws a triangle at the pointer, and the triangle jumps to the mouse every few seconds instead of being on it all the time. I don’t know whats causing it, but I’ll look into it and ask further if i find a problem that isn’t my fault.

Thanks again.

Could you post the code to this minimal application? That might help someone track down the problem…________________________________
From: wtivy1@my.bcit.ca (apefish)
To: sdl at lists.libsdl.org
Sent: Fri, November 13, 2009 3:01:35 PM
Subject: Re: [SDL] Nasty Event delay on debian

Thanks for helping, I managed to find the problem: on Linux, SDL seems to generate more mousemotion events (true?), and a bug in my code was causing my event loop to bail on the first mousemotion event, so it would get through one mousemotion event per frame, which delayed all the other events. I feel dumb for that bug.
Anyways, it works good now but I still have the same problem with OpenGL. I’ve created a pretty minimal application that just draws a triangle at the pointer, and the triangle jumps to the mouse every few seconds instead of being on it all the time. I don’t know whats causing it, but I’ll look into it and ask further if i find a problem that isn’t my fault.

Thanks again.

Yeah, you know what they say, “Many eyes makes light reading”… Or
something like that.

Jonny DOn Fri, Nov 13, 2009 at 6:05 PM, Mason Wheeler wrote:

Could you post the code to this minimal application?? That might help
someone track down the problem…


From: apefish
To: sdl at lists.libsdl.org
Sent: Fri, November 13, 2009 3:01:35 PM
Subject: Re: [SDL] Nasty Event delay on debian

Thanks for helping, I managed to find the problem: on Linux, SDL seems to
generate more mousemotion events (true?), and a bug in my code was causing
my event loop to bail on the first mousemotion event, so it would get
through one mousemotion event per frame, which delayed all the other events.
I feel dumb for that bug.
Anyways, it works good now but I still have the same problem with OpenGL.
I’ve created a pretty minimal application that just draws a triangle at the
pointer, and the triangle jumps to the mouse every few seconds instead of
being on it all the time. I don’t know whats causing it, but I’ll look into
it and ask further if i find a problem that isn’t my fault.

Thanks again.


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

Hi,
I just switched my operating system from windows 2000 to Debian (lenny). SDL used to work great for me, but when now there are significant delays in input events. When i click the mouse or press a key, it can take up to 5 seconds for the event to reach my application, and sometimes it doesn’t reach it at all. Framerate is still really nice, and mouse position is coming in instantly like normal, its just events like mouse clicks and key presses. I doubt its my code, because it was working just fine before, and i haven’t changed it at all. Also, if i use OpenGL instead of 2d stuff, similar issues except that mouse position is also horribly delayed.

Has anyone seen this before or know what it could be? I’m hoping it’s just some configuration mismatch somewhere. I’m using SDL 1.2 in C with GCC. It’s the default installation of SDL from Debian package system.
Any help would be great.

I have seen this before with some games that use SDL, ie. enemy
territory and UrbanTerror. For enemy territory, after some
searching I found that executing this before starting the game seems to
fix the problem for me:

export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0
export SDL_VIDEO_X11_MOUSEACCEL="1/1/1"

A google search form “sdl mouse lag sdl_mouse_relative” or similar
should find some more info (and people having similar problems, too).
Sorry I can’t be more specific - I don’t really know what causes it,
it seems to be a problem with SDL mouse handling under Linux. Hope
that helps anyway.On Wed, 11 Nov 2009 17:14:56 -0800 “apefish” wrote:

Hi,
I’ve done a few test cases and some probing in my minimal OpenGL program. It’s definitely acting strange.
I’ve made the program print out how many frames have gone by since the last event, and how many events it got this frame whenever it gets an event.
The events come from me waving the mouse around to generate motion events.
RESULTS:
With one big (across screen) textured polygon getting drawn every frame, and me waving the mouse around, it consistently allows all the events in exactly every 54 frames. That is, every 54 frames, I get all the events in that frame for the past 54 frames. I’m seeing 127 events come in at once a lot of the time (queue limit?). With me waving the mouse, i get 127 events in one frame every 54 frames.

Without the polygon, just GL_Swapbuffers, I get the same thing happening except i get 127 events in one frame evry 132 frames.

Without any GL calls, just set up window and run event loop (huge fps) I obviously can’t generate enough events to saturate the queue, but I’m getting approximately 1 to 5 events every approx 200 - 800 frames at full mouse waving speed. This result is different from the other two: the others have a constant period (54 frames and 132 frames) this one does not have constant period. The other loose their constant period when I generate less events, so this case probably acting the same, I just can’t saturate it.

CONCLUSION:
Something is causing events to pile up and then get released all at once. This is causing the big delay I’m seeing because the events are waiting for a while before coming in. It seems to have the same behavior no matter what I do. I’m afraid I suspect SDL or X for this one. Beyond what i’ve posted here, I’m totally lost. Anyone have any ideas? I’d like to post the code too, but I can’t figure out how to cut and paste, or post a file.[/code]

Ok I figured out how to paste. Here is my problem program:

Code:

#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
#include <stdio.h>

static const int w=640, h=480;

int setup_screen(void) {
const Uint32 flags = SDL_OPENGL;
if (SDL_Init(SDL_INIT_VIDEO)) {
printf(“fuckup: sdl fucked up\n”);
return -1;
}
//SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );
if (SDL_SetVideoMode(w, h, 0, flags) == NULL) {
return -1;
}

glEnable( GL_TEXTURE_2D );
glClearColor(0,0,0,0);
return 0;

}

int manage_events(void)
{
static int emptys = 0;
SDL_Event event;
int numevents = 0;
while (SDL_PollEvent(&event)) {
switch (event.type) {
case SDL_KEYDOWN:
case SDL_QUIT:
return 0;
default:
++numevents;
break;
}
}
if (numevents) {
printf("%d frames\n", emptys+1); /+1 for this frame/
printf("%d events\n", numevents);
emptys = 0;
} else {
++emptys;
}

return 1;

}

GLuint load_texture(char *filename)
{

SDL_Surface *image = SDL_LoadBMP(filename);

GLuint texhandle;
glGenTextures(1, &texhandle);
glBindTexture(GL_TEXTURE_2D, texhandle);

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);

glTexImage2D(GL_TEXTURE_2D, 0, 3, image->w, image->h, 0, GL_BGR, GL_UNSIGNED_BYTE, image->pixels);

SDL_FreeSurface(image);

return texhandle;

}

int main(int argc, char **argv)
{
setup_screen();

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho( 0, w, h, 0, -1, 1 );

GLuint tex = load_texture("texture.bmp");

int x = 0, y = 240;
while (manage_events()) {
	x %= 640;
	/*
	//SDL_GetMouseState(&x, &y);
	//glClear( GL_COLOR_BUFFER_BIT );
	glBindTexture(GL_TEXTURE_2D, tex);
	glBegin(GL_TRIANGLES);
		glTexCoord2d(0,0);
		glVertex2f(x, y);
		glTexCoord2d(1.0,0.0);
		glVertex2f(0, 0);
		glTexCoord2d(0.0,1.0);
		glVertex2f(0, 480);
	glEnd();
	*/
	SDL_GL_SwapBuffers();
	++x;
}

SDL_Quit();
return 0;

}

I have seen this before with some games that use SDL, ie. enemy
territory and UrbanTerror. For enemy territory, after some
searching I found that executing this before starting the game seems to
fix the problem for me:

export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0
export SDL_VIDEO_X11_MOUSEACCEL=“1/1/1”

Thanks, I tried that but it doesn’t seem to do anything. I’ll search around for more info though.

Hi,
I’ve done a few test cases and some probing in my minimal OpenGL program.
It’s definitely acting strange. I’ve made the program print out how many
frames have gone by since the last event, and how many events it got this
frame whenever it gets an event. The events come from me waving the mouse
around to generate motion events. RESULTS:
With one big (across screen) textured polygon getting drawn every frame,
and me waving the mouse around, it consistently allows all the events in
exactly every 54 frames. That is, every 54 frames, I get all the events in
that frame for the past 54 frames. I’m seeing 127 events come in at once a
lot of the time (queue limit?). With me waving the mouse, i get 127 events
in one frame every 54 frames.

Without the polygon, just GL_Swapbuffers, I get the same thing happening
except i get 127 events in one frame evry 132 frames.

Without any GL calls, just set up window and run event loop (huge fps) I
obviously can’t generate enough events to saturate the queue, but I’m
getting approximately 1 to 5 events every approx 200 - 800 frames at full
mouse waving speed. This result is different from the other two: the
others have a constant period (54 frames and 132 frames) this one does not
have constant period. The other loose their constant period when I
generate less events, so this case probably acting the same, I just can’t
saturate it.

I tested your code sample, and I can’t get more than 12 events per frame when
I have VSync (Sync to VBI) enabled from nvidia settings. And for this I also
have to press mouse buttons. So as your code runs fast in none GL mode I would
suspect that your system is using Mesa instead of HW accelerated OpenGL.

PS. If I disable VSync I can only get 1 event per multiple frames.

CONCLUSION:
Something is causing events to pile up and then get released all at once.
This is causing the big delay I’m seeing because the events are waiting
for a while before coming in. It seems to have the same behavior no matter
what I do. I’m afraid I suspect SDL or X for this one. Beyond what i’ve
posted here, I’m totally lost. Anyone have any ideas? I’d like to post
the code too, but I can’t figure out how to cut and paste, or post a
file.[/code]

If my assumption is correct the delay is due to the display update taking so
long.On Saturday 14 November 2009 03:10:26 apefish wrote:

I have seen this before with some games that use SDL, ie. enemy
territory and UrbanTerror. For enemy territory, after some
searching I found that executing this before starting the game seems to
fix the problem for me:

export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0
export SDL_VIDEO_X11_MOUSEACCEL=“1/1/1”

Thanks, I tried that but it doesn’t seem to do anything. I’ll search around for more info though.

Did you execute those lines in the same terminal (xterm,
gnome-terminal, etc.) before running your program? Else SDL won’t see
the environment variables.

I’m pretty sure this is the problem I saw though. It happened with
various games and definately on hardware-accelerated OpenGL, using
the fglrx driver, with quite high framerates (100+). I strongly suspect
this is a problem with SDL or X.

How many FPS do you get with your code example?

If you have amdcccle (ATI driver settings app) or the NVidia control
panel, try toggling the vsync option, see if that changes anything…On Fri, 13 Nov 2009 23:22:51 -0800 “apefish” wrote:

Did you execute those lines in the same terminal (xterm,
gnome-terminal, etc.) before running your program? Else SDL won’t see
the environment variables.

Yeah a did it right before i ran it, in same terminal, but I still get same results.

I tested your code sample, and I can’t get more than 12 events per frame when
I have VSync (Sync to VBI) enabled from nvidia settings. And for this I also
have to press mouse buttons. So as your code runs fast in none GL mode I would
suspect that your system is using Mesa instead of HW accelerated OpenGL.

I’ll look around and try to figure out what kind of OpenGL my system is using, and how to tweak it, thanks for the help.
I don’t think it’s what you said though, because even if i don’t flip the buffer, the events are still coming in unevenly. Maybe I misunderstand, or maybe this involves more dark magic than i think. Thanks.

I have suspicions about your test code here. The main loop is not the usual
way I see it done in SDL, so it’s harder to read. You’re not using any
SDL_Delay() in the loop, so it’s really no surprise that events get piled up
in a single frame (after many more have passed). It seems that the computer
is plowing through the frames much faster than the event queue gets updated
(mouse events being added to it, perhaps in groups at a few millisecond
intervals). I’m not too sure what I’m looking for, though…

Jonny DOn Sat, Nov 14, 2009 at 2:13 PM, apefish wrote:

Quote:

Did you execute those lines in the same terminal (xterm,
gnome-terminal, etc.) before running your program? Else SDL won’t see
the environment variables.

Yeah a did it right before i ran it, in same terminal, but I still get same
results.

Quote:

I tested your code sample, and I can’t get more than 12 events per frame
when
I have VSync (Sync to VBI) enabled from nvidia settings. And for this I
also
have to press mouse buttons. So as your code runs fast in none GL mode I
would
suspect that your system is using Mesa instead of HW accelerated OpenGL.

I’ll look around and try to figure out what kind of OpenGL my system is
using, and how to tweak it, thanks for the help.
I don’t think it’s what you said though, because even if i don’t flip the
buffer, the events are still coming in unevenly. Maybe I misunderstand, or
maybe this involves more dark magic than i think. Thanks.


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

SDL_Delay() isn’t mandatory. In fact, unconditionally calling it every frame
can cause issues; e.g. if you want to hit a 60 fps deadline. In any case,
using SDL_Delay() could only cause more events to pile up. Your description
of the event loop is such that either I am totally misunderstanding you or
you don’t understand how the event queue works in SDL.

– BrianOn Sat, Nov 14, 2009 at 8:48 PM, Jonathan Dearborn wrote:

I have suspicions about your test code here. The main loop is not the
usual way I see it done in SDL, so it’s harder to read. You’re not using
any SDL_Delay() in the loop, so it’s really no surprise that events get
piled up in a single frame (after many more have passed). It seems that the
computer is plowing through the frames much faster than the event queue gets
updated (mouse events being added to it, perhaps in groups at a few
millisecond intervals). I’m not too sure what I’m looking for, though…

Jonny D

I have suspicions about your test code here. The main loop is not the usual
way I see it done in SDL, so it’s harder to read. You’re not using any
SDL_Delay() in the loop, so it’s really no surprise that events get piled up
in a single frame (after many more have passed). It seems that the computer
is plowing through the frames much faster than the event queue gets updated
(mouse events being added to it, perhaps in groups at a few millisecond
intervals). I’m not too sure what I’m looking for, though…

Are you suggesting that SDL_Delay() is necessary in the event loop for
events to be properly processed? I haven’t read about this anywhwere in
the docs, and I think it shouldn’t be necessary.

I don’t see anything unusual or wrong with the test code either, it’s
not that hard to read.On Sat, 14 Nov 2009 15:48:21 -0500 Jonathan Dearborn wrote:

It may be that the OpenGL hardware driver is hogging processing time
and the X server isn’t given any time to process events.

Try sticking an SDL_Delay(1) in your loop and see if that fixes it.On Sat, Nov 14, 2009 at 1:26 PM, Johannes Kroll wrote:

On Sat, 14 Nov 2009 15:48:21 -0500 Jonathan Dearborn wrote:

I have suspicions about your test code here. ?The main loop is not the usual
way I see it done in SDL, so it’s harder to read. ?You’re not using any
SDL_Delay() in the loop, so it’s really no surprise that events get piled up
in a single frame (after many more have passed). ?It seems that the computer
is plowing through the frames much faster than the event queue gets updated
(mouse events being added to it, perhaps in groups at a few millisecond
intervals). ?I’m not too sure what I’m looking for, though…

Are you suggesting that SDL_Delay() is necessary in the event loop for
events to be properly processed? I haven’t read about this anywhwere in
the docs, and I think it shouldn’t be necessary.

I don’t see anything unusual or wrong with the test code either, it’s
not that hard to read.


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


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

It seems that the computer is plowing through the frames much faster than the event queue gets updated (mouse events being added to it, perhaps in groups at a few millisecond intervals).

It certainly isn’t plowing through frames. I haven’t measured it, but the framerate is pretty lowfor what it’s drawing, just judging based on it printing out how many frames have passed every now and then. And if the queue gets updated every few milliseconds, that wouldn’t account for me being able to consistently overflow the queue(127 events in one frame). It is acting like it gets updated every 54 or 132 frames though(depending what i draw), which is about every second.

Your description of the event loop is such that either I am totally misunderstanding you or you don’t understand how the event queue works in SDL.

I’m afraid I don’t fully understand the queue either; If someone could give me a rough idea of how the queue system works (with X.org) that might help my tests.

Also, I’ve done some further tweaks, made it only draw when it gets events in that frame(to reduce useless drawing). And I’m getting some new disturbing results:
The triangle is supposed to follow the mouse around. When i move the mouse in circles(or whatever shape) the events come in in their usual uneven way, and stop coming in pretty much when i stop the mouse. But the triangle lags behind the mouse quite a bit and keeps going in circles after I stop. This makes me think the GL calls don’t block(true?), and they are piling up and waiting to be executed, but GL can only render them so fast, so they queue up and get delayed. So now there are two problems:
Problem 1 is that the input events are waiting and flooding the queue all at once. Is this SDL or X.org or what?
Problem 2 is that my program is generating GL instructions faster than the pipeline can handle them. I suppose it makes sense to have the calls not block, but there should be a way to block until the pipeline has gotten to everything from the previous frame. Anyone know how?