I first posted this on another forum then noticed about this one, more apropriate.
So here it is :
Suppose you are doing a very simple animation that can be drawn on 1 millisec, and that you end your drawing with a call to glutSwapBuffers, then loop.
glutSwapBuffers is supposed to tag the backbuffer to be swapped during the next vertical blanking, then return ; the successive calls to gl functions beeing not executed untill the buffer exchange is completed.
So what if the described loop needs only a ten’th of the vertical rate to perform ?
Will the second glutSwapBuffers block, so that the animation is done at the maximum frame rate, but not more ; or will it just invalidate the prior glutSwapBuffer so that some frames are drawn for nothing ?
I’m not 100% sure how the GLUT implementation of SwapBuffers works (e.g. if it is delayed until other GLUT events or something - wouldn’t think so though).
In any case, this is a platform/card/configuration specific issue. If you are running Windows, and have a decent OpenGL driver (e.g. from nVidia), you will probably have an option in the gfx card’s OpenGL settings to turn “VSync” on or off.
If VSync (=sync swap to vertical retrace) is on, then subsequent calls to SwapBuffers will block until the previous swap has completed (I’m not sure, but there may be a “swap queue” so that the call will not block until the N:th call or so).
If, however, VSync is off, then the swap will take place immediately when calling SwapBuffers (without syncing to the monitor vertical retrace), and subsequent calls to SwapBuffers can be performed and executed instantly after returning from the previous call. In other words, your animation can run with FPS figures well above the monitor vertical refresh frequency. On the other hand, you will get ugly swap-in-the-middle-of-the-screen artifacts.
On some systems you can not control this behaviour (e.g. if you have stereo glasses installed and activated).
I’m also not sure if a call (the “first” call) to SwapBuffers can block the caller until the swap has occured. I think most implementations return immediately though (anything else would be a waste of valuable CPU time).
[This message has been edited by marcus256 (edited 01-15-2003).]