We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 583

Summary: SDL_flip doesn't wait for vertical retrace
Product: SDL Reporter: Johan Walles <johan.walles>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED DUPLICATE QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: patmandin
Version: 1.2.13Keywords: target-1.2.14
Hardware: x86   
OS: Linux   

Description Johan Walles 2008-05-04 03:07:21 UTC
I have set up a screen with SDL_DOUBLEBUF.  Since double buffering isn't supported on my hardware for some reason (X11?), my SDL_DOUBLEBUF was ignored.  So far, so good.

However, when I do SDL_flip(), what happens is:
* SDL_UpdateRect(screen, 0, 0, 0, 0)

What I expected was:
* Wait for vertical retrace
* SDL_UpdateRect(screen, 0, 0, 0, 0)

Would it be possible for SDL_flip() to wait for vertical retrace before updating the actual on-screen display, even if the hardware doesn't support double buffering?
Comment 1 Johan Walles 2008-05-06 04:25:42 UTC
I asked about this on the Xorg mailing list.

Doug Larrick suggests using DRM's drm_wait_vblank ioctl, or OpenGL's GLX_SGI_video_sync extension:
http://lists.freedesktop.org/archives/xorg/2008-May/035103.html

Michel Dänzer mentions a DOUBLE-BUFFER extension:
http://lists.freedesktop.org/archives/xorg/2008-May/035118.html

The DOUBLE-BUFFER extension is described here:
http://www.xfree86.org/current/dbe.pdf
Comment 2 Johan Walles 2008-05-06 04:31:46 UTC
... and I also got to know that "the standard technique for double buffering is to use a pixmap as the 'back buffer'":
http://lists.freedesktop.org/archives/xorg/2008-May/035126.html
Comment 3 Ryan C. Gordon 2009-09-13 16:33:38 UTC
Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.
Comment 4 Patrice Mandin 2009-09-14 10:40:44 UTC
Isn't this bug a duplicate for bug #406 ?
Comment 5 Patrice Mandin 2009-09-14 10:44:49 UTC

*** This bug has been marked as a duplicate of bug 406 ***