Updating the screen WITHOUT waiting for the vertical retrace?

Is it possible in SDL to update the screen without causing a wait for the
retrace? I know that when using double buffering and hardware flipping,
SDL_Flip() will set up the flip and return immediately. However, it’s not
good enough since it will still block on the next blit or lock.

I realize that not waiting for the retrace can cause shearing. However, it’s
far more important that I be able to update the screen as rapidly as
possible. What happens is that generally only small parts of the screen are
updated at each update (so shearing would likely not be noticeable), but
these updates occur frequently. There are no “frames” per se in this
application, just a stream of small updates. The frequency of updates also
varies widely depending on user input… so I can’t just collect every N
updates into a single screen update.

I’m using SDL_UpdateRects to update the screen with the changed areas, but
in fullscreen mode, it’s very slow. I’m assuming that’s because it waits for
a retrace on each screen update, limiting me to 60 or so changes per second.

I’m sure people will say that I should collect changes into larger batches
of updates, but I can’t find any way in SDL to retrieve the refresh rate,
and combined with the unpredictability of the updates (since they’re totally
driven by user input), that’s nearly impossible to do.

Any ideas?

Thanks,
Adam M.

try using single instead of double buffering.
i think turning vsync of in 2d apps is a bit difficult and very os
dependent.

i also think this was discussed here some weeks ago :slight_smile:

Adam M. wrote:>Is it possible in SDL to update the screen without causing a wait for the

retrace? I know that when using double buffering and hardware flipping,
SDL_Flip() will set up the flip and return immediately. However, it’s not
good enough since it will still block on the next blit or lock.

I realize that not waiting for the retrace can cause shearing. However, it’s
far more important that I be able to update the screen as rapidly as
possible. What happens is that generally only small parts of the screen are
updated at each update (so shearing would likely not be noticeable), but
these updates occur frequently. There are no “frames” per se in this
application, just a stream of small updates. The frequency of updates also
varies widely depending on user input… so I can’t just collect every N
updates into a single screen update.

I’m using SDL_UpdateRects to update the screen with the changed areas, but
in fullscreen mode, it’s very slow. I’m assuming that’s because it waits for
a retrace on each screen update, limiting me to 60 or so changes per second.

I’m sure people will say that I should collect changes into larger batches
of updates, but I can’t find any way in SDL to retrieve the refresh rate,
and combined with the unpredictability of the updates (since they’re totally
driven by user input), that’s nearly impossible to do.

Any ideas?

Thanks,
Adam M.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I’m using SDL_UpdateRects to update the screen with the changed areas, but
in fullscreen mode, it’s very slow.

This is the right way to do it. Make sure you’re not passing SDL_HWSURFACE
or SDL_DOUBLEBUF to SDL_SetVideoMode()

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment