Double buffering was invented (if that's the right term to use) to avoid the user seeing a complex scene being drawn in front of them, instead you draw to an offscreen buffer, and then flip the one being displayed.
There's two ways you can do this, the first is to simply swap them whenever you're done with drawing the scene, but this has the drawback of causing tearing, if the game is drawn a lot faster than the screen update frequency (which is quite possible with even moderately complex looking games) you can even have multiple tears showing at the screen at any given moment in time.
The solution to avoid this is to synchronize the flipping to the vertical sync of the monitor. This means that you only swap the buffers when the screen is ready to draw a new screen update (in CRT monitors this was when it was physically re-targeting the top of the screen, hence vertical sync or vsync).
The downside with this, however, is that you spend a lot of time waiting for the vertical sync to happen. While this is going on you cannot draw at all since both buffers are needed for this.
To solve that problem you add a third buffer, thus allowing the graphics card to continue drawing immediately, as if you were flipping the buffers regardless of vsync. You now have three buffers, the first is being read by the graphics card and sent to the actual screen, the second is waiting for vsync to be swapped in, and the third one is being drawn on by your game.
Now to the real question, what happens if the game finishes rendering the scene to this third buffer before the vsync has been reached? Simple, the graphics card puts this one as the new one to be flipped in at vsync, and give you back the one that was waiting for vsync.
This means that if you have very simple graphics you can draw many more frames into a buffer than you ever actually see on the screen itself. But the upside is that the age of this drawn image that is being shown is less than it would have been for simple double buffering with vsync.
On a 60Hz (which is mostly standard on modern screens) monitor it takes 16.6667 ms between each vsync, lets call it 16ms for simplicity. If your game is simple enough so it only takes 2ms to render a scene then you would get the following results for double buffering:
- Vsync, back-buffer is flipped with front-buffer
- Game accepts input and does logic
- Game is rendered (total time spent so far, 2ms)
- Game stalls waiting for vsync (for another 14ms)
- Vsync
- Game accepts input...
So it only looks at the player input every 16ms. With tripple buffering:
- Vsync
- Accepts input
- Rendered (total 2ms)
- Swap back-buffers
- Accepts input
- Rendered (total 4ms)
- Swap back-buffers
- ...
- Rendered (total 16ms)
- Swap back-buffers
- Vsync, latest rendered back-buffer is flipped with front-buffer
As you can see, you spend a lot more time rendering the simple scene, but the upside is that you accept player input every 2ms and does the game logic, and the image you see is only 2ms old, instead of 14ms as with double buffering, thus giving you less input lag and the feeling of more snappy controls. Keep in mind that the thrown away back buffers would never have been seen by the player in either case, so this isn't as much of a loss as it seems.
