Wrapping It Up

So there you have it. Triple buffering gives you all the benefits of double buffering with no vsync enabled in addition to all the benefits of enabling vsync. We get smooth full frames with no tearing. These frames are swapped to the front buffer only on refresh, but they have just as little input lag as double buffering with no vsync at the start of output to the monitor. Even though "performance" doesn't always get reported right with triple buffering, the graphics hardware is working just as hard as it does with double buffering and no vsync and the end user gets all the benefit with out the potential downside. Triple buffering does take up a handful of extra memory on the graphics hardware, but on modern hardware this is not a significant issue.

Just to recap, from our previous example, here are what the three frames we looked at rendering stack up side by side.


Triple Buffering



Double Buffering



Double Buffering with vsync


We've presented the qualitative argument and the quantitative argument in support of triple buffering. So, now the question is: does this data change things? Are people going to start looking for that triple buffering option more now than without this information? Let's find out.

{poll 135:300}

Regardless of the results, we do hope that this article has been helpful both in explaining an often overlooked option. While it might not be something we test with because of the issues with measuring performance, triple buffering is the setting we prefer to play with. We hope we've helped show our readers why they should give triple buffering a shot as well. 

We also hope more developers will start making triple buffering the default option in their games, as it will deliver the best experience to gamers interested in both quality and performance. There are only a handful of games that include triple buffering as a built in option, and NVIDIA and AMD drivers currently only allow forcing triple buffering in OpenGL games. This really needs to change, as there is no reason we shouldn't see pervasive triple buffering today.

UPDATE: There has been a lot of discussion in the comments of the differences between the page flipping method we are discussing in this article and implementations of a render ahead queue. In render ahead, frames cannot be dropped. This means that when the queue is full, what is displayed can have a lot more lag. Microsoft doesn't implement triple buffering in DirectX, they implement render ahead (from 0 to 8 frames with 3 being the default).

The major difference in the technique we've described here is the ability to drop frames when they are outdated. Render ahead forces older frames to be displayed. Queues can help smoothness and stuttering as a few really quick frames followed by a slow frame end up being evened out and spread over more frames. But the price you pay is in lag (the more frames in the queue, the longer it takes to empty the queue and the older the frames are that are displayed).

In order to maintain smoothness and reduce lag, it is possible to hold on to a limited number of frames in case they are needed but to drop them if they are not (if they get too old). This requires a little more intelligent management of already rendered frames and goes a bit beyond the scope of this article.

Some game developers implement a short render ahead queue and call it triple buffering (because it uses three total buffers). They certainly cannot be faulted for this, as there has been a lot of confusion on the subject and under certain circumstances this setup will perform the same as triple buffering as we have described it (but definitely not when framerate is higher than refresh rate).

Both techniques allow the graphics card to continue doing work while waiting for a vertical refresh when one frame is already completed. When using double buffering (and no render queue), while vertical sync is enabled, after one frame is completed nothing else can be rendered out which can cause stalling and degrade actual performance.

When vsync is not enabled, nothing more than double buffering is needed for performance, but a render queue can still be used to smooth framerate if it requires a few old frames to be kept around. This can keep instantaneous framerate from dipping in some cases, but will (even with double buffering and vsync disabled) add lag and input latency. Even without vsync, render ahead is required for multiGPU systems to work efficiently.

So, this article is as much for gamers as it is for developers. If you are implementing render ahead (aka a flip queue), please don't call it "triple buffering," as that should be reserved for the technique we've described here in order to cut down on the confusion. There are games out there that list triple buffering as an option when the technique used is actually a short render queue. We do realize that this can cause confusion, and we very much hope that this article and discussion help to alleviate this problem.

Digging Deeper: Galloping Horses Example


View All Comments

  • Schmide - Friday, June 26, 2009 - link

    My conceptions.

    Triple Buffering is 2 back buffers that alternate a copying (BLT) to a front buffer(primary/screen) while the other is rendering.

    Double Buffering is two surfaces that trade places between front and back buffer by switching states. Only works in full screen mode.

    Back Buffering where one surface is rendered to then copied to the front buffer(primary/screen). Often falsely called Double Buffering.

    Triple Buffering is designed to avoid the surface lock during a copy to the front buffer (BLT) in windowed mode so the next rendering cycle can start early. In full screen mode it just adds an extra step (BLT) in the rendering cycle, since a hardware is swap moves no memory just pointers.

    I would imagine the only reason a Triple Buffer would reduce tearing is, on average the back buffer copy is playing catchup to the primary surface update and the chances of half rendered frames is a bit less.

    So proper use would be

    Double Buffer - Full Screen Rendering.
    Back Buffer - Simple Full/Windowed Rendering
    Triple Buffer - Complex Windowed Rendering.
  • Schmide - Friday, June 26, 2009 - link

    PrinceGaz explained it so I understand below. Reply
  • Schmide - Friday, June 26, 2009 - link


    I want to add. Vsinc can be a problem because of the synchronous nature between game code and rendered frames. The more frames you get the better your character moves. If you lock down/cap your frames you may be loosing some response.

    Example. In cod4 crash, the wall by the dumpster near the 3 story building, you can only jump over it if your frames get above 125. I assume there is some round off error and Euler like calculations going on.

    The ideal rendering cycle, other than a fixed or capped game play engine, would be: vsinc, update, render a frame, do game code without rendering over and over, repeat.
  • DerekWilson - Friday, June 26, 2009 - link

    triple buffering does not use a blit to move a back buffer to a front buffer -- it is still done with buffer renaming.

    i.e. you'll have three pointers: one to the frame currently being rendered, one to the most recently completed frame (these are both back buffers), and one to the front buffer.

    after a vertical refresh completes, if there is not a more recently completed frame than the current front buffer, the current front buffer locks again and the same frame is drawn. If there is a more recently completed frame newer than the one that was just drawn, then this buffer becomes the front buffer and the old front buffer becomes the other back buffer.

    when the GPU finishes rendering into one back buffer, it marks that buffer as the most recently completed and swaps the pointers so that it's current buffer was the previous most recently completed buffer that is not the front buffer.


    i know, clear as much right?

    but really, there is no blit involved in a sane triple buffering implementation.
  • nvmarino - Friday, June 26, 2009 - link

    Hey Derek, thanks for the article. Any chance you could provide more detail about the issues with SLI and triple buffering? Such as why it's an issue, can the issues be overcome by game developers or is it an issue at the driver level, and also what are the typical problems an end-user would experience? Reply
  • Compddd - Friday, June 26, 2009 - link

    Or can I turn Vsync off and just leave triple buffering on? Like in L4D or TF2 for instance? Reply
  • DerekWilson - Friday, June 26, 2009 - link

    it is not possible to run triple buffering without vsync.

    the purpose of triple buffering is to provide a buffer that can remain locked during the vertical redraw (so that there is no corruption); this IS vsync.

    but the advantage is that there are still two buffers left over so that you can always save the most recently completed frame while working on the next one (and also not corrupting what is currently being displayed).

    think of it like this: there is one current work space, one most recently completed frame, and one vsync'd buffer.
  • Compddd - Friday, June 26, 2009 - link

    Why do these games like L4D and TF2 have the option to turn off Vync or Triple bufferng then? Or turn them both on, or turn one on and leave the other one off? Reply
  • JonP382 - Saturday, June 27, 2009 - link

    They don't. There's an option to turn on vsync with double buffering, or vsync with triple buffering. Or no vsync. Reply
  • Atechie - Friday, June 26, 2009 - link

    Thanks for showning me why still keeping my 2x21"CRT's are a good choice, so I don't get less IQ, fake black, tearing suckt 60Hz refresh and all the other crap that make LCD's less than steller for gaming. Reply

Log in

Don't have an account? Sign up now