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.
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
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.