Triple buffering is useful for renderering more frames per second than the monitor refresh rate can show although sync with vertical blank is enabled.

That means with two back buffers you don't have to wait for the swap to occur in the next vblank, but can start rendering of the next frame on the other backbuffer immediately after finishing the previous frame.
The swap is done from the already completed back buffer.

This is not an OpenGL API feature, but an implementation dependent driver feature.

I think Direct3D supports allocation of multiple backbuffers in the API.

Serge K

12-29-2000, 06:32 PM

Triple buffering is useful for renderering more frames per second than the monitor refresh rate can show although sync with vertical blank is enabled.

Why do you need "more frames per second than the monitor refresh rate can show "???

Hello, i'm not an expert, but some old style dos game programmers have taught me that now, with the actual power of the computers, double buffer is enough to make some good animation
But i have said...i'm not an expert..

Relic

01-03-2001, 04:23 AM

>>Why do you need "more frames per second than the monitor refresh rate can show "???<<

I put it differently. http://www.opengl.org/discussion_boards/ubb/smile.gif
Although wait on vertical blank is enabled, you can achieve frame rates which are decoupled from the monitor refresh.
This includes any fps and not only the whole quotients of the monitor refresh achievable with v-sync on and double buffering.

Yes, the shown frames are as many as the monitor refresh can display because v-sync is on. But underneath it's _possible_ to calculate more images. That looks better than the tearing effects you get with swaps w/o v-sync and fps > monitor refresh.
To get the fps == monitor refresh again you can delimit the swap interval with the so called extension.

[This message has been edited by Relic (edited 01-03-2001).]

john

01-11-2001, 03:50 PM

It is entirely useless to render more frames than your monitor can display. If you are pumping out 120 frames per second on a 60 hz screen, then ever alternative frame is rendered and cleared *before the monitor gets to see it*.

triple buffering is a technique to churn as many frames as possible. To illustrate:

Think about how double buffering works. You have two buffers; one of them is displayed on the monitor while the other is being rendered to off-screen. The montitor, meanwhile, is busily tracing out the current displayed buffer... when it finishes one trace it *re-traces* back to the top of the monitor and begins the process again.

Now, suppose the engine has finished rendering to the drawable buffer. In order to prevent shearing effects when the display buffer is overwritten in the middle of a trace, the engine *blocks*, waiting for the monitor to finish re-tracing before copying the drawable buffer to the display buffer (or swapping pointers, or however it is implemented). Herein lies the problem: the system is busy-waiting for a resource to finish with a buffer before it can start on the NEXT frame. If the monitor had only JUST started drawing the frame from the obsolete buffer, then the system has to wait close to an entire trace (say, 1/60th of a second on a 60hz display) before it can start the next.

Triple buffering is designed to get around the busy wait period and start drawing the next frame as soon as the previous has finished, yet retain the benfits of double buffering and not have the shear effect.

If the triple buffers are A, B and C, and A is the current displayed buffer buffer and B is the current drawable buffer, then C becomes the spare buffer. When B is finished, then instead of waiting for the retrace on A to complete, the system begins drawing to C. When the retrace to A is complete then B is displayed and A becomes the spare buffer. The whole idea is the system does NOT wait for re-trace to complete before working on the next frame.