Digging Deeper: Galloping Horses Example
Rather than pull out a bunch of math and traditional timing diagrams, we've decided to put together a more straight forward presentation. The diagrams we will use show the frames of an actual animation that would be generated over time as well as what would be seen on the monitor for each method. Hopefully this will help illustrate the quantitative and qualitative differences between the approaches.
Our example consists of a fabricated example (based on an animation example courtesy of Wikipedia) of a "game" rendering a horse galloping across the screen. The basics of this timeline are that our game is capable of rendering at 5 times our refresh rate (it can render 5 different frames before a new one gets swapped to the front buffer). The consistency of the frame rate is not realistic either, as some frames will take longer than others. We cut down on these and other variables for simplicity sake. We'll talk about timing and lag in more detail based on a 60Hz refresh rate and 300 FPS performance, but we didn't want to clutter the diagram too much with times and labels. Obviously this is a theoretical example, but it does a good job of showing the idea of what is happening.
First up, we'll look at double buffering without vsync. In this case, the buffers are swapped as soon as the game is done drawing a frame. This immediately preempts what is being sent to the display at the time. Here's what it looks like in this case:
Good performance but with quality issues.
The timeline is labeled 0 to 15, and for those keeping count, each step is 3 and 1/3 milliseconds. The timeline for each buffer has a picture on it in the 3.3 ms interval during which the a frame is completed corresponding to the position of the horse and rider at that time in realtime. The large pictures at the bottom of the image represent the image displayed at each vertical refresh on the monitor. The only images we actually see are the frames that get sent to the display. The benefit of all the other frames are to minimize input lag in this case.
We can certainly see, in this extreme case, what bad tearing could look like. For this quick and dirty example, I chose only to composite three frames of animation, but it could be more or fewer tears in reality. The number of different frames drawn to the screen correspond to the length of time it takes for the graphics hardware to send the frame to the monitor. This will happen in less time than the entire interval between refreshes, but I'm not well versed enough in monitor technology to know how long that is. I sort of threw my dart at about half the interval being spent sending the frame for the purposes of this illustration (and thus parts of three completed frames are displayed). If I had to guess, I think I overestimated the time it takes to send a frame to the display.
For the above, FRAPS reported framerate would be 300 FPS, but the actual number of full images that get flashed up on the screen is always only a maximum of the refresh rate (in this example, 60 frames every second). The latency between when a frame is finished rendering and when it starts to appear on screen (this is input latency) is less than 3.3ms.
When we turn on vsync, the tearing goes away, but our real performance goes down and input latency goes up. Here's what we see.
Good quality, but bad performance and input lag.
If we consider each of these diagrams to be systems rendering the exact same thing starting at the exact same time, we can can see how far "behind" this rendering is. There is none of the tearing that was evident in our first example, but we pay for that with outdated information. In addition, the actual framerate in addition to the reported framerate is 60 FPS. The computer ends up doing a lot less work, of course, but it is at the expense of realized performance despite the fact that we cannot actually see more than the 60 images the monitor displays every second.
Here, the price we pay for eliminating tearing is an increase in latency from a maximum of 3.3ms to a maximum of 13.3ms. With vsync on a 60Hz monitor, the maximum latency that happens between when a rendering if finished and when it is displayed is a full 1/60 of a second (16.67ms), but the effective latency that can be incurred will be higher. Since no more drawing can happen after the next frame to be displayed is finished until it is swapped to the front buffer, the real effect of latency when using vsync will be more than a full vertical refresh when rendering takes longer than one refresh to complete.
Moving on to triple buffering, we can see how it combines the best advantages of the two double buffering approaches.
The best of both worlds.
And here we are. We are back down to a maximum of 3.3ms of input latency, but with no tearing. Our actual performance is back up to 300 FPS, but this may not be reported correctly by a frame counter that only monitors front buffer flips. Again, only 60 frames actually get pasted up to the monitor every second, but in this case, those 60 frames are the most recent frames fully rendered before the next refresh.
While there may be parts of the frames in double buffering without vsync that are "newer" than corresponding parts of the triple buffered frame, the price that is paid for that is potential visual corruption. The real kicker is that, if you don't actually see tearing in the double buffered case, then those partial updates are not different enough than the previous frame(s) to have really mattered visually anyway. In other words, only when you see the tear are you really getting any useful new information. But how useful is that new information if it only comes with tearing?
Facebook
Twitter
RSS
184 Comments
View All Comments
DerekWilson - Friday, June 26, 2009 - link
I do make the claim that it's always better, but just wanted to use one example for simplicity sake (the 300 fps example).at lower refresh rates, the general case for performance is still the same as double buffering without vsync (which starts rendering the same frame that triple buffering would start rendering) ... and it still has the smoothness and lack of tearing of double buffering with vsync.
james jwb - Friday, June 26, 2009 - link
what about when 120 hz LCD's come out and if a game can provide 120 fps as a minimum. surely double buffering is the best case here, or will triple buffering perform exactly the same in this case?JimmiG - Friday, June 26, 2009 - link
The reason double buffering still prevails is probably because when current 3D standards were set during the late 90's, video memory was at a premium.For example, at 1024x768 (standard resolution at the time), each buffer would take up 1.5 MB at 16bpp and 3MB at 32bpp. Not a lot today, but back then 8-16MB cards were the norm. If a game was designed so that VRAM usage would peak at 16MB, adding a couple MB's usage for another buffer would kill performance. So the general idea was that "Yeah, sure triple buffering is nice, but it uses too much memory", and that idea hs kind of stuck.
fiveday - Friday, June 26, 2009 - link
There are major advantages to using Triple Buffering, but a few points that explain why its not automatically adopted.One big one is lag. Now, if things are pretty well lag free under double-buffering, no sweat. However, there's no getting around the fact that by adding an extra frame, you're adding 1/3 extra processing time between the frame being drawn and appearing on your display. If the game's pretty lag-free already, you'll never know the difference. If the game is already prone to some sort of input lag, it's about to get worse. How much worse, depends on the game itself... and in some cases it can drastically soften up your controls. It can be tricky to predict how much impact it will have, if any... a point I'll return to in the conclusion.
Another issue is memory usage. In a perfect world, every system will always have adequate texture memory accommodate triple buffering. Is it a perfect world? Nope. And if your graphics card is getting thin on ram, get ready for a performance hit. How much? Maybe none, maybe a lot. Which brings me to my last point.
Whether or not you'll see these adverse affects from using Triple Buffering depends partly on the game itself, how it was written, and partly on your own system configuration. Now, the developers are responsible for their own software, but there's no telling what kind of system a end user is going to try to run the game on. These days, a 4670 graphics card and a phenom X2, while seemingly meager, are enough to get most games out there plenty playable... but there's still folks out there trying to run a game like Bioshock on a Radeon 9700 pro (what's SM2.0, they cry!?!). Lord forbid someone try to use their laptop to play a game.
By the way... SLI and X-Fire setups tend to HATE triple buffering.
So you see... the developers have a tough enough time as it is getting their games playable on an extremely unpredictable variety of systems. Triple Buffering, while it has its advantages, simply introduces further risk of poor performance on a lot of systems out there. Should it be automatically enabled? Nope.
But should it be available as an option? These days, I see no reason why not. The original Unreal and UT engines offered it as an option, and that was ten years ago. Bring it back for those of us who want to take a crack at it.
DerekWilson - Friday, June 26, 2009 - link
you are correct that SLI and CrossFire don't like playing well with triple buffering... but then there have been plenty of oddities no matter what page flipping method we want to use.but enabling triple buffering does NOT add an additional latency penalty over double buffering unless double buffering visibly tears and you are talking about the rest of the frame ... double buffering and triple buffering start rendering the same frame every time.
there is no inserted frame into the pipeline, as it's not a pipeline -- what you are describing is more like DirectX's default 3 frame render ahead which has much higher potential to add latency than triple buffering (when we are talking about the page flipping method and not just "having three buffers").
sbuckler - Friday, June 26, 2009 - link
If tearing is not a problem then you are better off double buffering with vsync off. Turn on triple buffering and you introduce another 16.6ms of display lag which matters in a fast fps.DerekWilson - Friday, June 26, 2009 - link
you do NOT automatically incur a one frame lag -- you have at most an additional one frame lag.as i explained, especially in fast shooters, triple buffering and double buffering with no vsync begin rendering the exact same frame even if double buffering without vsync switches to a newer frame at some point.
and when tearing doesn't "happen" (read isn't noticable) then that means the updated frames were not different enough to really matter anyway (otherwise you would see the difference).
the possible advantage of double buffering could be argued when a tear happens near the top of the screen, but whether this is a real advantage is debatable.
BJ Eagle - Friday, June 26, 2009 - link
with double buffer vsync and framrate just below 30 FPS ?I would go for double buffer vsync if there is not an equal penalty going below 30 FPS as there is when going below 60 FPS. Simply because I don't want to waste power rendering frames I wont miss...
Movie industry teaches us that 25-30 FPS is actually enough to fool our brains to perceive motion. But if the lag skyrockets with vsync af below 30 FPS I guess I would go with triplebuffer...
nafhan - Friday, June 26, 2009 - link
With a 60hz refresh rate, I think dropping below 30 will cause the same issues as dropping below 60. Vsync is going to update frames at intervals that divide evenly into the refresh rate. So, if 30 is not an option, then it will update every 20 frames.I think most people can tell the difference between 30FPS in a game and 60FPS. However, more than that really doesn't provide much benefit.
toyota - Friday, June 26, 2009 - link
a game is not a movie...