non-game software with a polling event loop

[Sauer2]

Hi,

I'm thinking about writing an application with a GUI using SDL.

Now you might know that SDL 1.x had the ability to wait for the OS to pass events (like mouse movements, keyboard input and window related things) to the application like this:

{l Code}: {l Select All Code}

SDL_Event* ev;

while(SDL_WaitEvent(ev)) {
    handleEvent(ev)
}


SDL_WaitEvent() would pass control to the OS, blocking the program from executing and therefore would play nice with the scheduler.

In SDL 2 however, this is no longer the case, as it seems that the same function now polls for events every 10 ms internally.
Filtering events also requires a polling loop, so I guess I'd have to accept a polling main loop when using SDL 2.

Do you know if that is still acceptable for a normal application? Is that still sufficient in regards of the scheduler of a modern OS, the CPU usage and therefore fan and battery usage?

Thanks in advance.

[CryHam]

I'd say it's okay to wait 10ms every frame.
For games (especially those demanding) it's obviously not.

But, unless you have some visualization that needs to have 60 Fps it shouldn't matter.
I have a 5 ms sleep in my audio player (this one), since I have visualizations (and want them to be smooth). It has mostly always 60 Fps and takes about 1% of CPU playing (on my i7) was like 4% on an older laptop.

Worst thing would be having no sleep and wasting CPU on waitng.
But too much delay (>10ms?) would be bad too since it'd also drop frames or cause visible delay. (16.6ms is exactly 1/60Hz).

[Sauer2]

Worst thing would be having no sleep and wasting CPU on waitng.

That's actually the thing I'm worried about. I don't want a simple note taking application to drain the battery, just because it can't shutdown until the OS pushes another event.

EDIT: That said, for an audio player I guess it's ok to keep the CPU busy, but for some standard waiting-for-input applications, the scheduler should be able to nap.
EDIT2: I was told that even waiting 10 ms messes with the scheduler, so I'm curious how bad it actually is...

[CryHam]

IMO shouldn't hurt scheduler anyhow. Even 100% CPU for an hour shouldn't, but that's probably the only case that could disrupt it IMO.

Anyways, I had a look into SDL2 sources:
src/events/SDL_events.c
so just like I thought: SDL_PollEvent polls and doesn't wait.
See in code it does call SDL_WaitEventTimeout(event, 0); with 0 delay, and then that method below does return immediately for case when

{l Code}: {l Select All Code}

if (timeout == 0) {
  return 0;


So if using SDL_PollEvent in you application, you should put

{l Code}: {l Select All Code}

SDL_Delay(10);

yourself in the while loop (or use any other value to wait).
Otherwise it will probably saturate full 1 CPU use.

[Sauer2]

IMO shouldn't hurt scheduler anyhow.

Thanks, I should probably give it a try, then.
Maybe it also helps to only redraw the window content if an appropriate event comes out of the queue/filter

EDIT: After another round of searching in the internet and seeing that it never sleeps I've come to the conclusion that it's not acceptable. Meh, pretty much every other library can wait for callbacks.

EDIT2: Except for SFML as it seems: https://github.com/SFML/SFML/blob/80214 ... #L125-L134