Talk:Swap Interval

vsync with glFinish

I'm concerned about the accuracy of this statement:

On Windows, apart from rendering the picture at least twice as fast as the monitor's refresh rate (per the rules of the Sampling Theorem), SwapBuffers() combined with glFinish() is the only method supported on modern hardware to perfectly achieve vertical synchronization (vsync).

I have never seen this stated anywhere. I am not aware of any reason for a SwapBuffers operation to have to be followed by glFinish in order to vsync. The point of swap interval is to not have to do anything special (other than specifying the swap interval) to get vsync support. Do you have some source for this information? Alfonse 02:09, 11 September 2011 (PDT)

• Yeah, check the previous revision! (Although that in itself may not be reliable.) X-Fi6 02:46, 11 September 2011 (PDT)

The only reference made to glFinish previously was simply describing its behavior. The point of vsync-ing is not to force the CPU to wait for the GPU to finish rendering. It is to force the GPU to not swap the framebuffers unless a vblank is going on. Whether that makes SwapBuffers operations asynchronous to the CPU or not is irrelevant; what matters is that it eliminates tearing (seeing half of one frame and half of another). Nothing on this page said that using glFinish was necessary to "perfectly achieve vertical synchronization". Alfonse 04:35, 11 September 2011 (PDT)

Alright, it's sort of a double whammy. A modern compositor like Aero or Compiz should already take care of not drawing to the screen until the window's client area is completely drawn. But I suppose that was SwapBuffers's original intent. CPU<->V-blank synchronization is a nice optional benefit. (Although again, to qualify for "perfect vertical synchronization", this synchronization does help.) X-Fi6 12:47, 11 September 2011 (PDT)

Nice in what way? Syncing the CPU to the vertical retrace is overall detrimental to performance. It means that the CPU has to idle. Now yes, there are times when that's a good idea, such as when drawing things that are very small (like the GUI). But otherwise, for high-performance applications, this is unnecessary. If you want maximum performance, then you want as much asynchronicity as possible between the CPU and GPU. Alfonse 16:03, 11 September 2011 (PDT)

It really depends on what is meant by "maximum performance." If taking it to mean "overall throughput," then yes, syncing CPU to vblank is detrimental. If taking it to mean "minimal latency / transport delay," then syncing is almost always necessary. In my application, a high-fidelity flight simulator, we killed several frames' worth of latency by just glFinishing after swapping buffers, which is critical in controlling "simulator sickness" and other undesirable side effects. (pilot-induced oscillations, etc) The CPU can go ahead and crank out frames at 200 Hz, but if the GPU is vsyncing at 60 Hz, you wind up with a pile of queued frames that each take 1/60th second to appear sequentially. User clicks a mouse and doesn't see any visible effect for 100+ msec? That's pretty severe for an application that's supposed to have maximum performance.

Now if vsync is disabled, and visible tearing is considered acceptable performance, then I agree with you. --The Resident 14:05, 10 December 2011 (PST)

X-fi6, I believe you've read more meaning into the previous revision than I actually wrote. Combining glFinish and SwapBuffers is useful for controlling latency when vsync is enabled, and the actual syncing of buffer swaps to vblank can happen "perfectly" regardless of whether or not glFinish is used. "Perfect" vsync in my opinion is a totally different matter and seems to depend on a lot of variables (fullscreen, not fullscreen + number of GL windows visible per display, compositing) that are rooted in OS requirements and driver implementation. Also, why bring up the sampling theorem, and just for the brief Windows discussion? If you have another method of eliminating frame tearing, please explain it succinctly.

I'm editing the pertinent parts, and submitting to Alfonse that the disputed tag be removed. --The Resident 14:05, 10 December 2011 (PST)

• Before I hit submit, I'm wondering how these changes to the article would fare. http://pastebin.com/0TgkCgrs X-Fi6 18:20, 7 March 2012 (PST)

It'd be easier to see what you changed if you just posted them. That way, I can just look at the diff. They'll be reviewed, one way or another. Alfonse 20:35, 7 March 2012 (PST)

Done. X-Fi6 21:23, 7 March 2012 (PST)

WGL-related External Links are 404

They are dead. But the GLX-related ones are working and, AFAICT, provide valid information for WGL contexts too...

I'm not sure what to do. Does someone know if this is permanent ?

I think we could just let the GLX links, but phrasing should be adapted to point out they contain WGL relevant information too... Pando (talk) 14:58, 3 June 2017 (UTC)