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?

What are Double Buffering, vsync and Triple Buffering? Wrapping It Up
Comments Locked


View All Comments

  • CallsignVega - Thursday, November 12, 2009 - link

    Are you people sure that triple buffering is being enabled even with tools like DXTweaker and ATI Tray tools? In theory, shouldn't the card be working just as hard with triple buffering on as it does with VSync disabled?

    I've tested EvE online with my ATi HD5870. With Vsync off, my FPS are of course very high and I can see the high load on the GPU in regards to amperage used and heat produced. If I turn VSync on, it uses very little amperage and creates very little heat only running at 60fps.

    In triple buffer theory, shouldn't the graphics card be working just as hard but only displaying the 60 FPS with Vsync on? I've mad profiles for EvE under ATi Tray tools and forced triple buffering on, but I get the same results as with VSync on, very low amperage and heat increase. This leads me to believe that triple buffering is in fact, not being applied.

    Could all of these so called forcing of Direct3D triple buffering apps really not be doing anything? It could just be placebo effect and people think it's working just because they marked the check-box. Theres no way I could see triple buffering actually working with my HD5870 in Direct3D with such a very very low stress on the card compared to VSync off. Besides polling the stress level of the card, is there any other way to see if triple buffering is ACTUALLY turned on and working?
  • Skakruk - Wednesday, July 22, 2009 - link

    From the last page of the article:

    "...they have just as little input lag as double buffering with no vsync at the start of output to the monitor."

    I believe that is misinformation, as in my experience input lag results can vary significantly from game to game.

    For example, enabling V-Sync and Triple Buffer in UT2004 results in input lag so bad that the game is all but unplayable, but enabling V-Sync and Triple Buffer in CoD4 creates barely any input lag at all.

    Although CoD4 was very much playable, neither game exhibited "just as little input lag as double buffering with no vsync".

    NOTE: For both UT2004 and CoD4, I was forcing V-Sync and Triple Buffer via D3DOverrider, and all mouse filtering etc. was disabled in both games.

  • griffhamlin - Thursday, July 16, 2009 - link

    hang yourself morron. you didn't understand a single piece of this article LMAO !

    enabling tripple buffering without Vsync ??!!!. tripple buffering IS MEANT FOR VSYNC. for avoid the slowdown due to double buffer.
    And vsync is made for avoid TEARING. GOT IT ? u_o.

    Stop posting crap.
    you want vsync ? go for tripple buffer. dont think , do it...
    you don't want vsync ? whatever you enable tripple or double buffer. it doesn't matter.
  • davidri - Sunday, July 26, 2009 - link

    Wow, you're a rude
  • andy80517 - Wednesday, October 31, 2012 - link

    LOL good comment XD !
  • davidri - Tuesday, July 14, 2009 - link

    "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."

    This statement is not true. I enabled triple buffering without vsync on a GTX 280/27" LCD @ 60hz and ran Elder Scrolls Oblivion. The vertical tearing was awful.

    I have been running the 280 with vsync and double buffering enabled on because I'll take the performance overhead to alleviate vertical tearing.
  • jp777cmoe - Saturday, July 18, 2009 - link

    I read the article but im not sure about vsync and triple buffering..
    would it work well? i use a samsung 2233rz 120hz lcd monitor
  • griffhamlin - Wednesday, July 15, 2009 - link

  • davidri - Wednesday, July 15, 2009 - link

    Thank you for the duly and astute feedback.
  • MamiyaOtaru - Thursday, July 16, 2009 - link

    RTFA. DX game has to support triple buffering for you to get the benefit. If you toggled it on in the control panel, you were toggling it on for opengl games only.

    But *if* the game supports it, you'd be better off with triple buffering for avoiding tearing, though I still prefer double buffering with no vsync for responsiveness

Log in

Don't have an account? Sign up now