Not really. Keep in mind that while you can use SDL for stuff that isn’t games, games are the main focus. The traditional game loop is something like
If you’re trying to create a regular GUI app then it might be better to use something like Qt or WxWidgets. You’ll still run into the problem of bad things potentially happening if you do graphics or input handling off the main thread, depending on what platform your app is running on, but their interaction and event model is more like traditional UI toolkits. Like, you write callback functions that respond to buttons being clicked, keys being pressed, that sort of thing, instead of having to loop through events or use functions like
If the main thread goes for too long without processing events the operating system will think your program is hung. On macOS you get the beachball/pinwheel cursor, on Windows you get the “This application is not responding” warning or whatever, etc.
Can you miss events while the main thread is sleeping? Yes, depending on how you’re processing them and how long it sleeps. If you’re using functions like
SDL_GetKeyboardState() then you will miss anything that happened while the main thread was sleeping; if the main thread slept too long and the user pressed and released the Escape key while it was sleeping, your input code won’t see it when it wakes up and calls
SDL_GetKeyboardState(). If you’re just doing the standard
while loop with
SDL_PollEvent() then no, you won’t miss any events.
Another potential issue is if you’re trying to manually put the thread to sleep yourself. Implementations of
sleep that aren’t just busy waits can only guarantee that the thread will sleep for at least the specified amount of time. It’s common that it’ll sleep longer (even several milliseconds), and if you’re trying to manually hit 60hz then you may not be able to consistently do so.
What you can do is use
SDL_Renderer’s vsync support. Create the renderer with the flag
SDL_RENDERER_PRESENTVSYNC. When you call
SDL_RenderPresent() it will submit whatever drawing needs to be done and then block until the next display refresh after the drawing is complete. Doing a little test app with vsync on that draws a square every frame and nothing else, CPU usage sits around 1-3%.
If you’re worried about CPU usage when idle, this is an area where “traditional” UI toolkits have the upper hand if you aren’t making a game. If your program isn’t doing anything, and the user isn’t doing anything, your program’s main thread will be blocked and get no CPU time at all. The OS will wake up your program when there are new events to handle (user clicked a button, moved the mouse over your program’s window, a timer expired, etc) and once those are handled it goes back to sleep.