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
SirLamer - Friday, June 26, 2009 - link
It's just because nVidia hasn't designed their control panel to be super invasive. The only way to make it work is to have a program sitting there that intercepts calls from DirectX and changes them.Rather than blaming AMD and nVidia, it's probably better to ask why DirectX doesn't include a mechanism to control this performance parameter like it does for most other driver-configurable settings.
Download Riva Tuner, and from the zip file install D3D Overider. It will sit on your taskbar and do the job. I have used this program in the past, but I forgot to put it back since my last reformat and will now do it tonight. Thanks for the reminder article!
GourdFreeMan - Friday, June 26, 2009 - link
Hmm... it seems you are correct.How bizarre! I can understand the usefulness in keeping previous frames for post-processing effects, but you would only be reading from the frames and writing to the new frame, never writing to old ones. Why doesn't this "just work" under the control panel for DirectX like it does for OpenGL?
smn198 - Saturday, June 27, 2009 - link
I suppose we have monitor refresh rates as a legacy from CRT technology. Is there any reason (other than comparability) why we can't have a LCD that refreshes ad-hoc, when both it and the next frame are ready? No more just missing a refresh.Alternatively could LCD lie about its refresh rate and have some sort of buffer internally to achieve the same thing - reducing lag?
GourdFreeMan - Sunday, June 28, 2009 - link
All LCDs (both passive and active matrix) still refresh the screen periodically to prevent individual pixel elements from fading, so there is still a notion of refresh rate for LCDs. You do raise a good question of whether it would be possible to refresh the screen whenever frames are completed (which would have to be in addition to this base refresh rate, or you would get a flickering in brightness).Having an input buffer to reduce perceived display lag would result in torn frames if you tried to swap in the new frame mid-refresh. You still have to wait until the refresh is completed.
erple2 - Tuesday, June 30, 2009 - link
That doesn't make sense from the perspective of how an LCD works. The charge that twists the polarizing LCD element doesn't fade over time (well, not over the few milliseconds between updates - though the charge probably fades over the years as they wear out).The pixel elements don't generate any light themselves. How do they fade then?
I think that you're confusing 2 things here. The refresh rate of the LCD is tied to the output signal - they're both set to run at 60 Hz, so the video card outputs a "new frame" (even if the frame hasn't changed, it's a new frame) ever 1/60th of a second. The LCD then reads that signal every 1/60th of a second and displays it. Part of the reason they chose 60 Hz is due to the bandwidth limitation of the set standard. To update more frequently than that, you'll clearly need the capability of transmitting more data down the interface. Right now, the DVI interface can transmit up to 3.96 Gigabits of info per second. at 24 bits per pixel, and a 1920x1200 resolution, that's 55,296,000 bits per image. Given the hard cap of 3.96 Gbps, that's 3.96/55296000 * 1billion which is about 71 Hz. That's the fastest a single link DVI interface can refresh at that resolution. I believe it was therefore decided to cap the refresh rate at 60 Hz for any WUXGA resolutions. But, that's out of convenience, not for any reason related to fading pixels (unlike a CRT).
LCD's don't flicker per se, as there's no light that's turning on and off. The backlight is more or less constantly on.
overzealot - Wednesday, July 1, 2009 - link
As the pixels untwist (no power applied, or power applied in reverse) they transition back to blocking light. You could, theoretically, call the process fading, as that's what it would appear to do.The backlights in most LCD's run off AC, you can't say they're always on. Best you can say is that because the frequency is much higher than 50/60hz you can't see the flickering. It's still there.
There are faster than 60hz panels, it's just that the electronics are more costly - and the majority of people don't care.
I do care, but not enough to pay the extra cost of a 120hz panel.
I'd rather have a larger panel.
DerekWilson - Wednesday, July 1, 2009 - link
it is my understanding that pixel state on an LCD panel is driven by a steady voltage applied across the liquid crystal cell (aside from possible overdrive on the upswing to increase transition time). because they are digital, until the controller changes the state of that pixel, it can remain at a constant percentage of twist because there is a constant voltage applied. no refresh is "required" and the bandwidth issue is what drives "refresh rate" on LCD panels.many LCDs do use CCFL for backlight which can have a slight flicker for a very very short time period every time current alternates polarity, but it isn't really ever "off" as they are driven both ways (there are no dedicated anodes and cathodes - they switch with current).
But as we move toward LED backlighting (or away from CCFL and toward other technologies which are DC) then we won't have any flicker at all there either.
GourdFreeMan - Monday, August 31, 2009 - link
This "steady" voltage (only true of active-matrix LCDs) isn't maintained directly by the LCD's power supply. For TFTs there are one or more capacitors gated by a transistor for controlling their voltage per pixel element (R,G,B) that maintains the state. These capacitors slowly discharge and must be refreshed periodically. In this sense all LCDs have a "base refresh rate".If you do a Google search for LCD controllers integrated into consumer products you will find there is an issue with perceived flickering in brightness as the pixel elements fade if you do not refresh them often enough.
I was asked if it was possible to refresh the screen only when frames are completed, and this was the first issue I discovered when researching the question. Other than increased power usage and added controller complexity I do not know if there would be other issues if you tried to do a second "just in time" refresh and left my reply to the original question at that.
RSmith - Thursday, April 8, 2010 - link
Hey GourdFree Man,I got here thinking exactly the same thing as you: why do we need a fixed refresh rate on LCD's?
Did you get any answers to that?
I hope that future display technologies will allow this to happen, it would certainly be of huge benefit to gaming if frames were drawn as they were rendered.
homerdog - Sunday, June 28, 2009 - link
I can set my LCD to 75Hz, which AFAIK is a lie.