SDL_Flip uses 100% CPU

Hi,

im writing a Tetris clone using SDL. My SDL_Flip takes about 10ms which
is due to my 100Hz vsync, thats all okay. My Problem: Waiting for the
vsync hooks up 100% CPU… as an example use:

while (running)
{
Handle_SDL_Events();
SDL_Flip();
}

on a windows machine which can do vsync. (SDL 1.2.7)

Is there a smart way around this? Because i dont like a simple Tetris
game eating my notebook battery…

Thanks,
Markus Dangl

Just add SDL_Delay(ms) to free some CPU resource

while (running) {
Handle_SDL_Events();
SDL_Flip();
SDL_Delay(20);
}

“Markus Dangl” ???> im writing a Tetris clone using SDL. My SDL_Flip takes about 10ms which is

due to my 100Hz vsync, thats all okay. My Problem: Waiting for the vsync
hooks up 100% CPU… as an example use:
while (running) {
Handle_SDL_Events();
SDL_Flip();
}

on a windows machine which can do vsync. (SDL 1.2.7)
Is there a smart way around this? Because i dont like a simple Tetris game
eating my notebook battery…

RocWood wrote:

Just add SDL_Delay(ms) to free some CPU resource

while (running) {
Handle_SDL_Events();
SDL_Flip();
SDL_Delay(20);
}

I’m doing that atm, but i don’t think it is the best solution…

I dont really know about the internal workings of SDL, but does SDL_Flip
really have to check for vertical retrace at each CPU cycle?
Perhaps DirectX is not really able to handle this correctly - or the PC
graphics cards cant do it right - but it would be optimal to let the
hardware wait for the vsync instead of having the CPU poll for it all
the time… it has better things to do, and if it is just sleeping to
lower battery usage and CPU heating :slight_smile:

Thanks anyway!

I’m doing that atm, but i don’t think it is the best solution…

You can make this a bit more optimal by “predicting” the next time you
will have a vertical refresh, and waiting just a bit less for the
predicted time before calling SDL_Flip().

You can use SDL_GetTicks() to save the current time before the start of
the game loop, and just before flipping, you can wait for the difference
from your expected refresh rate (minus a millisecond or so, so that you
don’t accidentally skip frames).

I dont really know about the internal workings of SDL, but does SDL_Flip
really have to check for vertical retrace at each CPU cycle?

The problem here is that SDL finds out when to flip by doing a busy
wait. (See SDL_dx5video.c line 2049 on version 1.2.7). The comment
mentions that it was a fix to prevent slowdown on fast computers.
Presumably some really fast computers tend to miss vertical sync signals.–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

IMHO, I think that’s nothing with SDL_Flip. Have you ever
used profile tools to measure the cost of SDL_Flip ?

In fact, SDL_Flip do return very fast, and your main loop
just continue to refresh the screen again and again…that
is time the process tooks.

If you do not need so fast refresh rate, add some SDL_Delay
to suspend the process so as to free some CPU to other process.

“Markus Dangl” > RocWood wrote:

while (running) {
Handle_SDL_Events();
SDL_Flip();
SDL_Delay(20);
}

I’m doing that atm, but i don’t think it is the best solution…

I dont really know about the internal workings of SDL, but does SDL_Flip
really have to check for vertical retrace at each CPU cycle?
Perhaps DirectX is not really able to handle this correctly - or the PC
graphics cards cant do it right - but it would be optimal to let the
hardware wait for the vsync instead of having the CPU poll for it all the
time… it has better things to do, and if it is just sleeping to lower
battery usage and CPU heating :slight_smile: