SDL_PollEvent vs SDL_WaitEvent

Question

So I was reading this article which contains 'Tips and Advice for Multithreaded Programming in SDL' - https://vilimpoc.org/research/portmonitorg/sdl-tips-and-tricks.html

It talks about SDL_PollEvent being inefficient as it can cause excessive CPU usage and so recommends using SDL_WaitEvent instead.

It shows an example of both loops but I can't see how this would work with a game loop. Is it the case that SDL_WaitEvent should only be used by things which don't require constant updates ie if you had a game running you would perform game logic each frame.

The only things I can think it could be used for are programs like a paint program where there is only action required on user input.

Am I correct in thinking I should continue to use SDL_PollEvent for generic game programming?

Halogenate

Answer 1

If your game only updates/repaints on user input, then you could use SDL_WaitEvent. However, most games have animation/physics going on even when there is no user input. So I think SDL_PollEvent would be best for most games.

One case in which SDL_WaitEvent might be useful is if you have it in one thread and your animation/logic on another thread. That way even if SDL_WaitEvent waits for a long time, your game will continue painting/updating. (EDIT: This may not actually work. See Henrik's comment below)

As for SDL_PollEvent using 100% CPU as the article indicated, you could mitigate that by adding a sleep in your loop when you detect that your game is running more than the required frames-per-second.

Kurt

Hi, thank you for the feedback. This is pretty much what I had come to think so just wanted to check I hadn't missed something totally obvious. I have implemented frame rate capping to prevent CPU maxout. – Halogenate

In my humble opinion you WANT to allow the system to perform tasks (like other threads, etc), so the use of SDL_WaitEvent is a better choice. No one is going to move (twitch) anywhere close to 10 ms. If you need to run a physics engine, you can set a timer to go off to handle that. Chewing up 100% of the processor JUST IN CASE is a bad idea. – Ledge

From the SDL2 documentation: "As this function implicitly calls SDL_PumpEvents(), you can only call this function in the thread that initialized the video subsystem. " Using SDL_Wait in a separate thread whilst another thread is doing the painting, this might be really dangerous. And SDL_Poll does not use 100% of the cpu. SDL_Poll merely checks if there is an event in the event queue and then pops it to the provided pointer. – Anything

Answer 2

If you don't need sub-frame precision in your input, and your game is constantly animating, then SDL_PollEvent is appropriate.

Sub-frame precision can be important for, eg. games where the player might want very small increments in movement - quickly tapping and releasing a key has unpredictable behavior if you use the classic lazy method of keydown to mean "velocity = 1" and keyup to mean "velocity = 0" and then you only update position once per frame. If your tap happens to overlap with the frame render then you get one frame-duration of movement, if it does not you get no movement, where what you really want is an amount of movement smaller than the length of a frame based on the timestamps at which the events occurred.

Unfortunately SDL's events don't include the actual event timestamps from the operating system, only the timestamp of the PumpEvents call, and WaitEvent effectively polls at 10ms intervals, so even with WaitEvent running in a separate thread, the most precision you'll get is 10ms (you could maybe approximate smaller by saying if you get a keydown and keyup in the same poll cycle then it's ~5ms).

So if you really want precision timing on your input, you might actually need to write your own version of SDL_WaitEventTimeout with a smaller SDL_Delay, and run that in a separate thread from your main game loop.

Further unfortunately, SDL_PumpEvents must be run on the thread that initialized the video subsystem (per https://wiki.libsdl.org/SDL_PumpEvents ), so the whole idea of running your input loop on another thread to get sub-frame timing is nixed by the SDL framework.

In conclusion, for SDL applications with animation there is no reason to use anything other than SDL_PollEvents. The best you can do for sub-framerate input precision is, if you have time to burn between frames, you have the option of being precise during that time, but then you'll get weird render-duration windows each frame where your input loses precision, so you end up with a different kind of inconsistency.

Gerstner

Answer 3

In general, you should use SDL_WaitEvent rather than SDL_PollEvent to release the CPU to the operating system to handle other tasks, like processing user input. This will manifest to you users as sluggish reaction to user input, since this can cause a delay between when they enter a command and when your application processes the event. By using SDL_WaitEvent instead, the OS can post events to your application more quickly, which improves the perceived performance.

As a side benefit, users on battery powered systems, like laptops and portable devices should see slightly less battery usage since the OS has the opportunity to reduce overall CPU usage since your game isn't using it 100% of the time - it would only be using it when an event actually occurs.

Wageworker

Just double checked the SDL documentation, and looked at the source code. Apparently in SDL 2, they changed it so that SDL_WaitEvent just loops until an event takes place rather than passing control back to the OS. That being the case, I guess I can't see any reason to justify using SDL_WaitEvent over SDL_PollEvent, at least for performance reasons in SDL 2... :-( – Wageworker

Hi, thank you for your response. Yes SDL_WaitEvent is essentially a blocking function. This is why I couldn't see how it would fit in a game loop. I guess it might work if the event handling was split into a separate thread – Halogenate

Answer 4

This is a very late response, I know. But this is the thread that tops a Google search on this, so it seems the place to add an alternative suggestion to dealing with this that some might find useful.

You could write your code using SDL_WaitEvent, so that, when your application is not actively animating anything, it'll block and hand the CPU back to the OS.

But then you can send a user-defined message to the queue, from another thread (e.g. the game logic thread), to wake up the main rendering thread with that message. And then it goes through the loop to render a frame, swap and returns back to SDL_WaitEvent again. Where another of these user-defined messages can be waiting to be picked up, to tell it to loop once more.

This sort of structure might be good for an application (or game) where there's a "burst" of animation, but otherwise it's best for it to block and go idle (and save battery on laptops).

For example, a GUI where it animates when you open or close or move windows or hover over buttons, but it's otherwise static content most of the time.

(Or, for a game, though it's animating all the time in-game, it might not need to do that for the pause screen or the game menus. So, you could send the "SDL_ANIMATEEVENT" user-defined message during gameplay, but then, in the game menus and pause screen, just wait for mouse / keyboard events and actually allow the CPU to idle and cool down.)

Indeed, you could have self-triggering animation events. In that the rendering thread is woken up by a "SDL_ANIMATEEVENT" and then one more frame of animation is done. But because the animation is not complete, the rendering thread itself posts a "SDL_ANIMATEEVENT" to its own queue, that'll trigger it to wake up again, when it reaches SDL_WaitEvent.

And another idea there is that SDL events can carry data too. So you could supply, say, an animation ID in "data1" and a "current frame" counter in "data2" with the event. So that when the thread picks up the "SDL_ANIMATEEVENT", the event itself tells it which animation to do and what frame we're currently on.

This is a "best of both worlds" solution, I feel. It can behave like SDL_WaitEvent or SDL_PollEvent at the application's discretion by just sending messages to itself.

For a game, this might not be worth it, as you're updating frames constantly, so there's no big advantage to this and maybe it's not worth bothering with (though even games could benefit from going to 0% CPU usage in the pause screen or in-game menus, to let the CPU cool down and use less laptop battery).

But for something like a GUI - which has more "burst-y" animation - then a mouse event can trigger an animation (e.g. opening a new window, which zooms or slides into view) that sends "SDL_ANIMATEEVENT" back to the queue. And it keeps doing that until the animation is complete, then falls back to normal SDL_WaitEvent behaviour again.

It's an idea that might fit what some people need, so I thought I'd float it here for general consumption.

Undertone

Answer 5

You could actually initialise the SDL and the window in the main thread and then create 2 more threads for updates(Just updates game states and variables as time passes) and rendering(renders the surfaces accordingly). Then after all that is done, use SDL_WaitEvent in your main thread to manage SDL_Events. This way you could ensure that event is managed in the same thread that called the sdl_init.

I have been using this method for long to make my games work in windows and linux and have been able to successfully run 3 threads at the same time as mentioned above.

I had to use mutex to make sure that textures/surfaces can be transformed/changed in the update thread as well by pausing the render thread, and the lock is called every once 60 frames, so its not going to cause major perf issues.

This model works best to create event driven games, run time games, or both.

Sideshow

How did you achieve the multithreading? I'm battling with trying to parallelize my game right now. – Lorou

Sorry, am replying this after a while now. Its better to use Mutexes for every class function that you think will be executed in multiple threads. Also mark any function thats supposed to be executed in a specific thread only. – Sideshow

You will likely need to create the render thread, then the update thread then start both. Then before you join those threads, you need to execute the event loop. Once one of the threads changed the done to true, it comes out of the loop and joins all threads and the program closes. I prefer to have a render function that keeps calling render in loop, then an Update function that calls Update() of every sprite object in a loop. I will update my answer that includes a snippet of how i managed to pull it off. – Sideshow

Answer 6

Ngl but I think the best answer is just switching between the two, minimizing performance when not needed, control the variable gamestate and switch upon mouse click or keyboard tap,... and while minimizing or hidden window:

if (gamestate != ACTIVE_RENDERING_NEEDED || SDL_GetWindowFlags(win) & (SDL_WINDOW_MINIMIZED | SDL_WINDOW_HIDDEN)) {
        SDL_WaitEvent(&ev);
    }
    else {
        SDL_PollEvent(&ev);
    }
switch (ev.type) {//handle}

Matsu