Nasty Event delay on debian

It definitely sounds like you’re hitting software rendering and all the CPU
is being used to run that.

What’s the output of glxinfo?On Sat, Nov 14, 2009 at 2:01 PM, apefish wrote:

Quote:

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.

Quote:

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?


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

What’s the output of glxinfo?

bash: glxinfo: command not found

Why does it do this funny stuff when it eats up the CPU? I would think it would just slow down.

I’ll look around for how to get it to do hardware rendering, and see where it goes from there.