SDL_PollEvent busy‑wait causing high CPU usage in idle loops

Managing CPU Usage in SDL Event Loops

An idle SDL_PollEvent loop should ideally consume near 0% CPU. If your application is consuming a full CPU core while waiting for input, it is because SDL_PollEvent is non-blocking; it returns 0 immediately when the queue is empty, allowing the while loop to spin at the maximum clock speed of the processor.

Reducing Load Without Significant Lag

Adding a minimal SDL_Delay(1) is often sufficient to drop CPU usage from 100% to negligible levels. Because most operating system schedulers have a minimum sleep granularity (often 1ms to 15ms), even a 1ms delay forces the thread to yield its time slice, preventing the "busy-wait" scenario.

Trade-offs for different loop strategies:

• SDL_PollEvent + SDL_Delay: Reduces CPU load significantly. A 1ms delay is generally imperceptible to users but prevents core saturation.
• SDL_WaitEvent: The most efficient method for non-real-time apps (e.g., tools, editors). It puts the thread to sleep entirely until an event occurs, resulting in 0% idle CPU. However, it halts all rendering and logic updates.
• Frame-rate Limiting: For games, use SDL_GetTicks() to calculate the time elapsed and delay only the remaining duration of the frame. This maintains consistent input latency while capping CPU usage.

Thread Safety and Event Handling

In SDL2 and SDL3, the event queue is designed to be pumped on the main thread (the thread that initialized the video subsystem). While some internal SDL functions are thread-safe, calling SDL_PollEvent or SDL_WaitEvent from multiple threads simultaneously is not supported and can lead to race conditions or crashes.

To handle input without blocking the main logic thread, the recommended pattern is to serialize access: poll all events on the main thread and push the processed data into a thread-safe queue or state object that other threads can read.

Verification Steps

To verify the fix, monitor the process via htop (Linux) or Task Manager (Windows) during an idle state:

1. Baseline: Run the loop with SDL_PollEvent only. CPU should spike to 100% of one logical core.
2. Throttled: Insert SDL_Delay(1). CPU should drop significantly.
3. Blocking: Replace with SDL_WaitEvent. CPU should drop to ~0%.

Note: To provide a more specific recommendation on delay timing, please specify if your application requires a fixed frame rate (e.g., 60 FPS) or is an event-driven utility.