Consider some time in between two vsyncs. Suppose the first display buffer is being used to display the current image, and suppose the game was really fast and computed and rendered the next image to the second display buffer and the next one after that to the third display buffer. That is the rendering to the second and third display buffer happens so fast that it occurs before the next vsync.

Suppose input from the user comes in now. What you would like is for the results of the input to show up on the next vsync or (probably more typical) the vsync after that. However, with the third display buffer already rendered the input can only effect the image after that. Meaning the input will only take effect at best 3 vsyncs later.

I wish i had an image to show the exact timings of what I mean.

  • \$\begingroup\$ What is your question? \$\endgroup\$ Jul 2, 2012 at 10:36
  • \$\begingroup\$ yes, more explain will be helpful. I don't see why a third buffer is helpful \$\endgroup\$
    – zinking
    Jul 2, 2012 at 10:37
  • \$\begingroup\$ Interesting article on the topic: anandtech.com/show/2794/2 \$\endgroup\$ Jul 2, 2012 at 11:24

1 Answer 1


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:

  1. Vsync, back-buffer is flipped with front-buffer
  2. Game accepts input and does logic
  3. Game is rendered (total time spent so far, 2ms)
  4. Game stalls waiting for vsync (for another 14ms)
  5. Vsync
  6. Game accepts input...

So it only looks at the player input every 16ms. With tripple buffering:

  1. Vsync
  2. Accepts input
  3. Rendered (total 2ms)
  4. Swap back-buffers
  5. Accepts input
  6. Rendered (total 4ms)
  7. Swap back-buffers
  8. ...
  9. Rendered (total 16ms)
  10. Swap back-buffers
  11. 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.

  • \$\begingroup\$ I don't think you answered the exact hypothetical situation I proposed. And I'm also wary of the idea of "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". That would mean that the user perceives an abrupt temporal jump since the next image has been skipped. \$\endgroup\$
    – user782220
    Jul 2, 2012 at 15:59
  • \$\begingroup\$ What about this tweet by John Carmack: "Triple buffering adds latency and jitter; it should be avoided. The Answer is non-isochronous display updates." twitter.com/ID_AA_Carmack/status/190111153509249025 \$\endgroup\$
    – user782220
    Jul 6, 2012 at 5:16
  • \$\begingroup\$ @user782220 I do believe that the timeline describes perfectly what would happen in your hypothetical situation. Between 2 vsyncs you render two backbuffers, and then you wondered what will happen with input now. This input will be used to render to a backbuffer immediately, if this finishes before the next vsync it will be displayed then, but if you cant render this frame fast enough before the next vsync, then the last fully rendered backbuffer will be displayed, and this input will be displayed one vsync later. \$\endgroup\$ Jul 6, 2012 at 14:17
  • \$\begingroup\$ As for your link, I believe what he means is that you should not lock to vsync at all, but tearing can become quite significant in this case, especially if your making a simple game that can render hundreds of frames per second. If you lock to vsync with double buffering you will create a bigger input lag as you will force your game to run as if on a slower machine. Tripple buffering would cause less latency between button press and action being handled on average \$\endgroup\$ Jul 6, 2012 at 14:19
  • \$\begingroup\$ So with Triple buffering where does the jitter come from then? \$\endgroup\$
    – user782220
    Jul 6, 2012 at 21:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .