SDL_WaitEvent/PushEvent slowness?

SDL Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,
My application event loop looks like the following:

while(true)
{
repaint();

// Point A (see below)

while(SDL_PollEvent(&e))
{
ProcessEvent(&e);
} // end while events waiting.

} // end while true

This event loop runs beautifully, provides very fast response times, etc. The
only problem I have with it is that it busy waits [while(true)] and uses 100% of
the CPU. So, I figured, I’d make it wait until an event appeared with some code
that looks like this:

    if (SDL_WaitEvent(&e) == 1)
    {
    SDL_PushEvent(&e);
    }

which I would insert at “Point A” above. That mostly worked. CPU usage was now
low, but the WaitEvent/PushEvent combination was adding a very perceptible lag
to my application’s response time. (Not LARGE, but perceptible if you were
looking for it, I’d guestimate in the range of 70-100ms.)

I eventually used the following code instead:

   while( SDL_PeepEvents(&peep,1,
            SDL_PEEKEVENT,SDL_EVENTMASK(SDL_KEYDOWN)) == 0)
    {
            SDL_PumpEvents();
            SDL_Delay(10);
    }

This works as I expected (lowering CPU usage to around 4% when idle), and
provides the snappy response time I’m trying for.

My question: Is this a problem with SDL_WaitEvent or SDL_PushEvent? I imagine
that SDL_WaitEvent is implemented something like my PeepEvent code above
internally, perhaps with a larger Delay than 10?

Why doesn’t a combination of SDL_WaitEvent/PushEvent deliver the same
performance as my PeepEvent code? It’s simpler from a programmers prospective,
and easier to understand.

Thanks,
Jay

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iQCVAwUBRIidirWkkhmZq4xxAQKbWQQAj+Z/m1CwKNxm2ZnFpzIkvkmbqxkuET5M
z7jFypasRLMiuXBzbNaek6c8ciKPjMsFDsuAbfkUEA4FCdC9sWcQIOtPRRHM11K8
TRvtdOq2m89buixFH/p4urzNaMfzoGvpoW/kcfhSeXczzdta8pFS162igLQi8c7V
I7Fi5lrBZro=
=p060
-----END PGP SIGNATURE-----

2

SDL_WaitEvent does exactly what it says, it waits for events. If there are
no events, it blocks. So your event will never be pushed until an external
event arrives. I’ve found that a SDL_Delay of around 10 ms just after my
render call achieves what you are looking for. You need a bit more work if
you have a specific framerate/logic rate in mind. No need for peekevent, etcOn 6/8/06, Jay Summet wrote:

Why doesn’t a combination of SDL_WaitEvent/PushEvent deliver the same
performance as my PeepEvent code? It’s simpler from a programmers
prospective,
and easier to understand.

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know an event is appearing. (The user presses a key.) I’m talking about "lag"
between when the user presses the key and when the corresponding feedback
appears on the screen. It’s longer using WaitEvent than when using PeekEvent.

Jay

Brian Barrett wrote:

SDL_WaitEvent does exactly what it says, it waits for events. If there
are no events, it blocks. So your event will never be pushed until an
external event arrives. I’ve found that a SDL_Delay of around 10 ms just
after my render call achieves what you are looking for. You need a bit
more work if you have a specific framerate/logic rate in mind. No need
for peekevent, etc

Why doesn't a combination of SDL_WaitEvent/PushEvent  deliver the same
performance as my PeepEvent code? It's simpler from a programmers
prospective,
and easier to understand.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iQCVAwUBRIjFW7WkkhmZq4xxAQJQvgP+IPlCA93mUNdSp1iUuxTATL3B67f7xzOG
gPxquhwjC6ari/yJ7bIGkLjlGBqAmnDQ49iYz5cf3vlR+ElP/E8OT7f0ezAaf3te
eWl9oUAgKdgGwnGZ/0wB1+dppIORH5ZQ64POlVSD5T4aEkNStXDFfpoetqVquY7/
uzCCC0uWqPo=
=IZTw
-----END PGP SIGNATURE-----> On 6/8/06, Jay Summet <@Jay_Summet mailto:Jay_Summet> wrote:

4

I don’t have your post in front of me, but… IIRC, you seemed to be handling
only one event at a time.

e.g.:

if (SDL_WaitEvent…

whereas handling all of them makes a lot more sense; you could end up
getting a TON of events if you’re not filtering out mouse-motion, for example.
So this might be better:

while (SDL_WaitEvent…

and, of course, I’m kind of worried about infinite loops by pushing events
back onto the event queue in response to reading events, but again, I don’t
have your code in front of me, and am not 100% sure what the point of your
code was, so apologies if my response is way off. ;)On Thu, Jun 08, 2006 at 08:48:28PM -0400, Jay Summet wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know an event is appearing. (The user presses a key.) I’m talking about "lag"
between when the user presses the key and when the corresponding feedback
appears on the screen. It’s longer using WaitEvent than when using PeekEvent.

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

5

Hello all,
My application event loop looks like the following:

while(true)
{
repaint();

// Point A (see below)

while(SDL_PollEvent(&e))
{
ProcessEvent(&e);
} // end while events waiting.

} // end while true

This event loop runs beautifully, provides very fast response times, etc. The
only problem I have with it is that it busy waits [while(true)] and uses 100% of
the CPU. So, I figured, I’d make it wait until an event appeared with some code
that looks like this:

   if (SDL_WaitEvent(&e) == 1)
   {
   SDL_PushEvent(&e);
   }

which I would insert at “Point A” above. That mostly worked. CPU usage was now
low, but the WaitEvent/PushEvent combination was adding a very perceptible lag
to my application’s response time. (Not LARGE, but perceptible if you were
looking for it, I’d guestimate in the range of 70-100ms.)

Not only that, but it contains a race condition: If SDL_WaitEvent
returns a DOWN event, your event loop may recives it’s UP event before the
DOWN event.

Better to use SDL_WaitEvent(NULL) instead.On Thu, 8 Jun 2006, Jay Summet wrote:

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mattias Karlsson wrote:

Not only that, but it contains a race condition: If SDL_WaitEvent
returns a DOWN event, your event loop may recives it’s UP event before the
DOWN event.

As I’m only reacting to down events, it doesn’t really matter for my case, but
that could be a nasty bug…

Better to use SDL_WaitEvent(NULL) instead.

Ahhh…I hadn’t realized that it was possible to NOT accept the event, excellent
answer!

Ok, so I’ve tested
SDL_WaitEvent(NULL);

vs

    while( SDL_PeepEvents(&peep,1,
            SDL_PEEKEVENT,SDL_EVENTMASK(SDL_KEYDOWN)) == 0)
    {
            SDL_PumpEvents();
            SDL_Delay(10);
    }

And they both seem to have the exact same behavior, including the same fast
response time, so I’m going to summarize that the SDL_PushEvent was causing the
slowdown in the following code:

if (SDL_WaitEvent(&e) == 1)
{
SDL_PushEvent(&e);
}

Thanks,
Jay

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iQCVAwUBRIlcNLWkkhmZq4xxAQI6QwQAmgY9svWJCjzHFmKEwNrSTHvlIeZ63i/f
TmCDUafVbXzL4vNIS2zj9QbZpQzl9p2X/RrlGo7xAu7zKVC1IY7WUo8d/qrfT+Ul
uPJWpg/Q5J3i3Ae+ShCGWyX6dUuv+EYEEobqoN1cAsqlJUwvb7jiciNay1h1kPPk
ZnYYuM5ltfI=
=T13d
-----END PGP SIGNATURE-----