We often neglect to get too involved in the discussion of what options people should always enable when they play games. Rather, we tend to focus on what we test with. Honestly, our recommended settings for playing the games we test would be very similar to the settings we use to benchmark with one very important exception: we would enable triple buffering (which implies vsync) whenever possible. While it's not an available option in all games, it really needs to be, and we are here to make the case for why gamers should use triple buffering and why developers need to support it.
Most often gamers, when it comes to anything regarding vsync, swear by forcing vsync off in the driver or disabling it in the game. In fact, this is what we do when benchmarking because it allows us to see more clearly what is going on under the hood. Those who do enable vsync typically do so to avoid the visual "tearing" that can occur in some cases despite the negative side effects.
We would like to try something a little different with this article. We'll include two polls, one here and one at the end of the article. This first poll is designed to report what our readers already do with respect to vsync and double versus triple buffering.
{poll 134:300}
After reading the rest of this article, our readers are invited to answer a related poll which is designed to determine if arming gamers with the information this article provides will have any impact on what settings are used from here on out.
First up will be a conceptual review of what double buffering and vsync are, then we'll talk about what triple buffering brings to the table. For those who really want the nitty gritty (or who need more convincing) we will provide follow that up with a deeper dive into each approach complete with some nifty diagrams.
Facebook
Twitter
RSS
184 Comments
View All Comments
profoundWHALE - Monday, January 19, 2015 - link
You'll need backlight strobing to get CRT-like performance on LCDs. Take a look at http://www.blurbusters.com/texkill - Friday, June 26, 2009 - link
First, let me sum up the actual advantage of triple buffering: smoothing out variable draw times when game framerate < monitor refresh. That's it.This article severely overstates the case for triple buffering when it says "there is an option that combines the best of both worlds with no sacrifice in quality or actual performance." Okay so you want "the best of both worlds" which would be no tearing and minimum input lag? And the example used to prove this is 300 fps on 60hz. Well guess what, I can give you the best of both worlds with something called "waiting a while." See those horse figures at the beginning of each frame in the double-buffer figure? Move them from the beginning of the frame to near the end and viola, input lag is looking good again.
But actually it gets even better when you add multithreading to a double-buffered solution. Now you not only don't have to draw frames that will *never be seen by any living creature on Earth* (not the default behavior in DirectX btw), you can actually make use of the CPU time that would otherwise be spent in the graphics api to do something useful like physics or AI. You also then don't need to have frames that are drawing when the v-sync happens and causing the input lag and smoothness to vary every single frame (again, not the default DX behavior).
Triple buffering has its place when drawing times vary and smooth animation is desired. But it should definitely not be blindly demanded of all game developers when most of them already know the tradeoffs and have already made very good judgments on this decision.
DerekWilson - Friday, June 26, 2009 - link
this is more of an additional advantage. without vsync, double buffering still starts drawing the same frame that triple buffering would start drawing but changes frames in between. throw in vsync and you still get a doubling of worst case added input lag (and an increase in average case input lag too).and it's not about drawing the frames that will never be seen -- it's about not seeing frames that are outdated when newer frames can be finished before the next refresh (reducing input lag).
multithreading still helps triple buffering ... i don't see why that even enters into the situation.
the game can't know for sure how long a frame will take to render when it starts rendering (otherwise it would know how long it could wait to start the process so that the frame is as new as possible before the next refresh). there is no way to avoid having frames that are being worked on during a vertical refresh.
JarredWalton - Friday, June 26, 2009 - link
VSYNC is really the absolutely worst solution to this problem in my opinion. Let's say you have a game that runs at ~75FPS on average on your system, with VSYNC off. Great. Enable triple buffering and you still get 75FPS average, though some frames will never be seen. Use double buffering with VSYNC and you'll render 60FPS... ideally, at least.The problem with VSYNC is that you get lower minimum frame rates, and those become very noticeable. If you're running at 60FPS most of the time, then drop to 30FPS or 20FPS or 15FPS (notice how all of those are an even divisor of 60), those lows become even more distracting. Far more common, unfortunately, is that maintaining 60FPS with many games is very difficult, even with high-end hardware. Rather than getting a smooth 60FPS, what you usually end up with is 30FPS.
Finally, in cases where the frame rate is much higher than the refresh rate, triple buffering does give you reduced image latency relative to double buffering with VSYNC - though as Derek points out it still has a worst case of 16.7ms (lower than double with VSYNC).
zulezule - Friday, June 26, 2009 - link
Your comment made me realize that I'd prefer my GPU to render the 60 vsync-ed frames and stay cool, instead of rendering 300 fps (out of which 4/5 are useless), overheat, become noisy and maybe even crash. The only case when I'd want more frames rendered would be when they are used to insert something in the one visible frame, as for example if the 4 invisible frames are averaged with the visible one to create motion blur. However, I'm pretty sure beautiful motion blur can be obtained much more easily.DerekWilson - Friday, June 26, 2009 - link
The advantages still exist at a sub 60 FPS level. I just chose 300 FPS to illustrate the idea more easily.At less than 60 FPS, the triple buffered case still shows the same performance as double buffering -- they both start rendering the same frame after a refresh. double buffering with vsync still adds more input lag on average than the other cases.
Mills - Friday, June 26, 2009 - link
You made a good case of something currently impossible (if I understand you correctly) being better than triple buffering but I don't see where you made the case that triple buffering isn't better than double buffering in the case of FPS being much greater than refresh rate.The point is, when we are given a choice between double and triple, is there a reason not to choose triple?
texkill - Friday, June 26, 2009 - link
What's impossible about it?Yes, there are drawback to triple buffering. Implement it the way directX does by default and you get input lag. Implement it the way the article suggests and you get wasted cpu and jerky animation. And either way you are sacrificing video memory that could have been used for something else.
DerekWilson - Friday, June 26, 2009 - link
1) DirectX does not implement triple buffering (render-ahead is not the same and should not be referred to as "triple buffering" when set to 3 frames). The way to think of the DX mess is that they set up a queue to for the back buffer, but there is only one real back buffer and one front buffer (even with 3 frame render ahead, it is essentailly double buffered if we're talking about page flipping).2) The triple buffering approach described in this article is the only thing that should actually be called "triple buffering" if we are contrasting it with "double buffering" and referring to page flipping. Additionally, it does not create jerky animation -- the animation will be much smoother than either double buffering with or without vsync (either because frames have less lag or because they don't tear).
toyota - Friday, June 26, 2009 - link
yeah it makes me wonder why both card companies dont even allow it straight from the cp for DX games if there are no drawbacks. also it seems like all game developers would incorporate it in their games if again there were no drawbacks.