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
Scalarscience - Saturday, June 27, 2009 - link
...I'm posting this as a reply but please use the reply button on the previous post unless you're really wanting to reply to this particular post...The next thing that I see COMPLETELY neglected in this article and most of the comments--outside of 1 or 2 mentions of higher framerates increasing your movement rate--is that many games will use the engine's currently processing frame for collision & 'hitscan' decisions. My experience/understanding is that this is in addition to the input latency issues covered above, and in fact is MORE important to me than just worrying about visual tearing.
Hitscan is a term I learned more from the original UT game, I know there was a term CS players used back in the 1.x days too but it slips my mind (and probably more terms now). Basically it applies to projectiles who have 'infinite' velocity, ie, hit their targets immediately when calculated. Hitscan isn't the only type of calculation used for in-game weapons by any means, but the it's the one who (imo) is most affect by latency & discontinuities in the gameplay (caused by bad prediction or perhaps a stalling render thread) so it's the one that is most discussed. My impression is that the hitscan issues apply to other collisions & weapon hits as well, modified by how their weapons work.
As FPS players are not only concerned with 'what they see' but also what their 'shots' and 'movements' are translating into (especially in competitive online fps games) this is one of the main reasons that players used to force vsync off even if they could get their CRT to do 100hz or higher. Older games do have things directly tied to the render thread (physics, movement speed etc) but as time has gone on that's been reduced and methods of 'prediction' have been added, which means that the discussions get complicated over time. Also some games will use client side detection for certain things (instead of correlating things from the server's perspective to make the final 'decision') which can reduce apparent latency for hitscan style shots
Konstantineb - Saturday, June 27, 2009 - link
Would like to know if anandtech is considering an Arma 2 review with some GPUs performance data.The game is realy good looking, and it deserves a review from anandtech....StarRide - Friday, June 26, 2009 - link
Since WoW's triple buffering actually says it might cause input lag, I'm beginning to wonder if WoW's triple buffering implementation is actually just 3 frame render ahead...profoundWHALE - Monday, January 19, 2015 - link
"I'm beginning to wonder if WoW's triple buffering implementation is actually just 3 frame render ahead... "Congradulations, you just accurately described a triple-buffer as a "3 frame render ahead", which it is. It's really not that difficult a concept.
We apply the same concept to a youtube video. We buffer ahead so we get a smooth, steady frame-rate, although in the case of video streaming, we are buffering many, many frames.
This means that if you have terribly low fps, you'll see a bigger hit to latency with triple-buffering than someone with 100 fps.
30 fps = 33.3 ms per frame, meaning that you can end up with latency of about 100 ms with triple buffering
120 fps = 8.33 ms per frame, meaning that you can end up with latency of about 25 ms with triple buffering
Vsync will continue rendering as usual, but will simple make sure that only an exact multiple is displayed, so if your average fps is about 45 fps and you have a 60 Hz refresh rate, you'll get a steady output of 30 fps. The downside is you'll probably get an effect similar to the 3:2 pulldown where some frames will last as short of a time as 25 ms, and as long as 33 ms.
This is why things like Gsync and Freesync are awesome, because we can just throw vsync and buffering out the window and instead of trying to sync the input the the output, we sync the output to the input.
profoundWHALE - Monday, January 19, 2015 - link
I should clarify that the real world lag from triple buffer isn't as bad as the numbers I put out there, but because you have vsync, you will have greater input lag so it still gives a good idea of what latencies you could be looking at.MamiyaOtaru - Friday, June 26, 2009 - link
Triple buffering is obv. better than double, but I'd still not use it.In the final set of comparison shots, two thirds of the screen on the double buff without vsync example is newer than the corresponding screen in the triple buffering example. This means tears, yes, but that's newer info you aren't getting until later with triple buffering.
With double, a mouse movement that starts halfway between screen refreshes can (if the framerate is high enough) show up as soon as a new frame is rendered and swapped to the front to be read by the monitor. Granted, it will only show up on some bottom portion of the screen, with older info above, but in triple buffering that movement will not show up at all until the monitor finishes the current refresh and starts another.
In the horse example posted, the max time between input and reaction on screen is 3 times greater with triple buffering than with double w/o vsync, even if with the latter that reaction is only shown on the bottom 2/3rds or 1/3rd of the screen. It's *there* and it isn't until later with triple buffering.
But it's sure as hell better than double buff with vsync :) And visually better than double buff w/o vsync. A nice compromise. But let's not pretend there are precisely 0 drawbacks. If you'd prefer faster reaction time and can accept tearing to get it, you'll not want triple buffering, as that shuts out any new info until the monitor has drawn a completed, now out of date frame.
It's similar to interlaced vs progressive. Progressive looks nicer, no artifacts. But given the same bits per second, interlaced will have a higher framerate as it isn't drawing the whole frame each time. With double buffering you get bits of several frames rendered onto the screen at once. Artifacts, but you're getting more up to date info *even if that more up to date info isn't on the whole screen*.
justniz - Friday, June 26, 2009 - link
This article makes it sound like triple-buffering is always best, which is just not true.If you play games that require fast reactions and you have powerful enough hardware that you dont get tearing on double-buffering then DONT USE TRIPLE BUFFERING.
Why?
Because triple buffering adds an extra frame's worth of delay before you see the picture. Its only maybe 1/30 to 1/60th of a second extra, but in twitch/frag games removing that delay may be enough to give you the edge.
DerekWilson - Friday, June 26, 2009 - link
triple buffering does not add an extra frame of delay.triple buffering is always the best option, even for twitch shooters where a bad tear can look like something that's actually there and distract the gamer.
having powerful hardware does not reduce tearing. in fact, at higher framerates there is always a higher chance of tearing than at lower frame rates (at 300 FPS tears will happen every frame, whereas at 40 FPS, tears cannot possibly happen every frame -- the lower the frame rate, the less likely or often tearing occurs).
you still get the reduce lag "edge" that is apparent in double buffering without vsync, but you get the most recently fully completed frame of animation rather than a composite of multiple frames starting with the one that triple buffering would have given you in full.
MamiyaOtaru - Friday, June 26, 2009 - link
ou get the most recently fully completed frame of animation rather than a composite of multiple frames starting with the one that triple buffering would have given you in full.starting with, but ending with newer stuff, which is exactly the point. Triple buffering is offering the most up to date feedback on your input only up until the point a tear would happen in double buffering.
DerekWilson - Friday, June 26, 2009 - link
i did note that this is the only potential advantage of double buffering without vsync, but that in order to actually benefit from it, it needs to be a visible artifact (the frames need to be different enough to cause a visible tear) and you only get the benefit in the percentage of the frame that comes after the tear.part of the double buffered frame is the same as the triple buffered frame ... if you need information from this part of the screen (if you're looking there) you still won't get the benefit and the peripheral distraction of tearing can ... well ... distract.
some people may see this as a real advantage, but i certainly think the downside certainly outweighs any potential upside.