On SDL_WaitEvent's behavior

Hi all,

I wanted to ask about SDL_WaitEvent’s current and possibly future behavior. From reading the docs, I thought that calling SDL_WaitEvent would do something like a blocking wait using select() but after taking a look at the source code, it just seems like a semi-busy loop (the SDL_Delay call blocks for 10ms repeatedly)

I’ve read that a few other event loops (glib and Qt come to mind) use select() or similar mechanisms to try and idle when there isn’t a lot of activity in an application. For desktops, tying up the CPU a bit more probably isn’t a big deal, but I can imagine that idling would be beneficial on mobile targets like iOS and Android.

It also seems like at some point this behavior was either proposed or existed in SDL (https://forums.libsdl.org/viewtopic.php?t=7369&highlight=sdlwaitevent)

So I have a few general questions:

  • Are there any plans to implement event based blocking/wake ups in SDL?
  • Has anyone compared SDL resource usage vs. similar toolkits/frameworks on either desktop or mobile?
  • Are there any guidelines to keep CPU usage to a minimum where possible?

2015-01-11 3:18 GMT-03:00, phobitor :

I’ve read that a few other event loops (glib and Qt come to mind) use
select() or similar mechanisms to try and idle when there isn’t a lot of
activity in an application. For desktops, tying up the CPU a bit more
probably isn’t a big deal, but I can imagine that idling would be beneficial
on mobile targets like iOS and Android.

Actually, it can be a big deal with desktops too, since I’ve been
noticing that calling SDL_Delay here doesn’t seem to help bring down
CPU time at all (so it’s stuck at 100% usage no matter what I do). I
guess I missed some library when building for Linux and it’s just
taking the busy loop option or something like that, on Windows I’m not
having this issue.

At first that may not seem like a serious problem since the program
will yield the excess CPU time to other processes anyway, but if
you’re running on a laptop, that will drain the battery FAST, so it’s
better to avoid it.