Precise behavior of SDL_flip() and hardware buffers

The documentation for SDL_Flip() (http://sdldoc.csn.ul.ie/sdlflip.php)
states:

On hardware that supports double-buffering, this function sets up a
flip and returns. The hardware will wait for vertical retrace, and
then swap video buffers before the next video surface blit or lock
will return.

To me that means that the call returns immediately but the next action
that locks the buffer will be forced to wait until after the next
vertical retrace before the lock can complete. But, when I test this
function on my machine I see that SDL_Flip() does not return
immediately. It appears to return after the next vertical retrace. My
guess is that the documentation is correct for some platforms and wrong
for others. My guess is that depending on the platform the actual
behavior of SDL_Flip() is all of the following:

  1. The display pointer changes immediately, you may get tearing,
    SDL_Flip() returns instantly.

  2. The flip takes place at the next video retrace, but SDL_Flip()
    returns immediately. Possibly returning before the flip has happened.

  3. The Flip takes place at the next video retrace, and SDL_Flip()
    returns after the flip has happened.

Can someone please confirm or deny my guesses? To write portable code it
is necessary to know all the different ways that SDL_Flip() behaves.

Thanks!

	Bob Pendleton-- 

±----------------------------------+

  • Bob Pendleton: independent writer +
  • and programmer. +
  • email: Bob at Pendleton.com +
    ±----------------------------------+

Hi I’am also interested by these questions. Here is the problem, which may
be included in one of these questions, I have encountered with SDL_Flip.

I have made my game’s logic independent of the video frame rate. My idea was
to move sprites according to the time elapsed since the last move, and to
display as much frames as possible. This worked fine under linux with X or
the frame buffer, and under windows in windowed mode. In fullscreen
(DoubleBuf) mode with Windows the game speed was well synchronized on the
game clock (objets’ speed was ok) but I lose a lot of frames. I found that
calling SDL_Flip only every 7-10 ms solved the problem, but I wasn’t
satisfied by this solution. My actual solution is to embed the SDL_Flip into
a loop to test the returned result: while (SDL_Flip(screen) < 0); . This
means that some calls to SDL_FLip can fail. What are the reason to SDL_Flip
fail ? Is it a directX related reason ? If the answer completly unrelated
to Bob’s questions please change the subject to something like “SDL_FLip
errors” to not polute this thread.

Thanks

Julien> ----- Original Message -----

From: bob@pendleton.com (Bob Pendleton)
To: “SDL Mailing List”
Sent: Tuesday, May 20, 2003 9:49 PM
Subject: [SDL] Precise behavior of SDL_flip() and hardware buffers.

The documentation for SDL_Flip() (http://sdldoc.csn.ul.ie/sdlflip.php)
states:

On hardware that supports double-buffering, this function sets up a
flip and returns. The hardware will wait for vertical retrace, and
then swap video buffers before the next video surface blit or lock
will return.

To me that means that the call returns immediately but the next action
that locks the buffer will be forced to wait until after the next
vertical retrace before the lock can complete. But, when I test this
function on my machine I see that SDL_Flip() does not return
immediately. It appears to return after the next vertical retrace. My
guess is that the documentation is correct for some platforms and wrong
for others. My guess is that depending on the platform the actual
behavior of SDL_Flip() is all of the following:

  1. The display pointer changes immediately, you may get tearing,
    SDL_Flip() returns instantly.

  2. The flip takes place at the next video retrace, but SDL_Flip()
    returns immediately. Possibly returning before the flip has happened.

  3. The Flip takes place at the next video retrace, and SDL_Flip()
    returns after the flip has happened.

Can someone please confirm or deny my guesses? To write portable code it
is necessary to know all the different ways that SDL_Flip() behaves.

Thanks!

Bob Pendleton


±----------------------------------+

  • Bob Pendleton: independent writer +
  • and programmer. +
  • email: Bob at Pendleton.com +
    ±----------------------------------+

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

The documentation for SDL_Flip() (http://sdldoc.csn.ul.ie/sdlflip.php)
states:

On hardware that supports double-buffering, this function sets up a
flip and returns. The hardware will wait for vertical retrace, and
then swap video buffers before the next video surface blit or lock
will return.

To me that means that the call returns immediately but the next action
that locks the buffer will be forced to wait until after the next
vertical retrace before the lock can complete. But, when I test this
function on my machine I see that SDL_Flip() does not return
immediately. It appears to return after the next vertical retrace. My
guess is that the documentation is correct for some platforms and wrong
for others. My guess is that depending on the platform the actual
behavior of SDL_Flip() is all of the following:

  1. The display pointer changes immediately, you may get tearing,
    SDL_Flip() returns instantly.
  1. The flip takes place at the next video retrace, but SDL_Flip()
    returns immediately. Possibly returning before the flip has happened.
  1. The Flip takes place at the next video retrace, and SDL_Flip()
    returns after the flip has happened.

Can someone please confirm or deny my guesses? To write portable code it
is necessary to know all the different ways that SDL_Flip() behaves.

I believe this is correct. Whenever possible I’ve tried to implement #2.
What is always true is that the next surface lock after a flip will return
after the current framebuffer has been displayed to the end user, and if
vertical retrace sync is available, after the vertical retrace.

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

The documentation for SDL_Flip() (http://sdldoc.csn.ul.ie/sdlflip.php)
states:

On hardware that supports double-buffering, this function sets up a
flip and returns. The hardware will wait for vertical retrace, and
then swap video buffers before the next video surface blit or lock
will return.

To me that means that the call returns immediately but the next action
that locks the buffer will be forced to wait until after the next
vertical retrace before the lock can complete. But, when I test this
function on my machine I see that SDL_Flip() does not return
immediately. It appears to return after the next vertical retrace. My
guess is that the documentation is correct for some platforms and wrong
for others. My guess is that depending on the platform the actual
behavior of SDL_Flip() is all of the following:

  1. The display pointer changes immediately, you may get tearing,
    SDL_Flip() returns instantly.
  1. The flip takes place at the next video retrace, but SDL_Flip()
    returns immediately. Possibly returning before the flip has happened.
  1. The Flip takes place at the next video retrace, and SDL_Flip()
    returns after the flip has happened.

Can someone please confirm or deny my guesses? To write portable code it
is necessary to know all the different ways that SDL_Flip() behaves.

I believe this is correct. Whenever possible I’ve tried to implement #2.
What is always true is that the next surface lock after a flip will return
after the current framebuffer has been displayed to the end user, and if
vertical retrace sync is available, after the vertical retrace.

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

Thanks Sam, that is the information I needed.

	Bob PendletonOn Thu, 2003-05-22 at 00:20, Sam Lantinga wrote:

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

±----------------------------------+

  • Bob Pendleton: independent writer +
  • and programmer. +
  • email: Bob at Pendleton.com +
    ±----------------------------------+