Screen tearing
|
|
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2009) |
Screen tearing is a visual artifact in video where information from two or more different frames is shown in a display device in a single screen draw.[1]
The artifact occurs when the video feed sent to the device isn't in sync with the display's refresh, be it due to non-matching refresh rates – in which case the tear line moves as the phase difference changes (with speed proportional to difference of frame rates) – or simply lack of sync between two equal frame rates, in which case the tear line is at a fixed location corresponding to the phase difference. During video motion, screen tearing creates a torn look as edges of objects (such as a wall or a tree) fail to line up.
Tearing can occur with most common display technologies and video cards, and is most noticeable on situations where horizontally-moving visuals are commonly found, such as in slow camera pans in a movie, or classic side-scrolling video games.
Contents |
[edit] Prevention
The ways to prevent video tearing are dependent on the technology of the display device and video card, the software in use, and the nature of the material being shown. The most common solution is to use multiple buffering.
Most systems will use this function along with one or both of these two methods:
[edit] V-sync
Vertical synchronization is an option found in most systems, wherein the video card is prevented from doing anything visible to the display memory until after the monitor has finished its current refresh cycle.
During the vertical blanking interval, the driver would order the video card to either rapidly copy the off-screen graphics area into the active display area (double buffering), or treat both memory areas as displayable, and simply switch back and forth between them (page flipping).
[edit] Complications
When vertical synchronization is in use, the frame rate of the rendering engine will exactly equal the monitor's refresh rate, if it was higher. Although this feature normally results in improved video quality, it is not without trade-offs in some cases.
- Judder
Vertical synchronization can also lead to artifacts in video and movie presentations, as they are generally recorded at frame rates significantly lower than the typical monitor frame rates (24–30 frame/s). When such a movie is played on a monitor set for a typical 60 Hz refresh rate, the video player will miss the monitor's deadline fairly frequently, in addition to the interceding frames being displayed at a slightly higher rate than they were intended for, resulting in an effect similar to judder – see Telecine: Frame rate differences.
- Input lag
Video games, which have a wide variety of rendering engines, tend to benefit well visually from vertical synchronization, as a rendering engine is normally expected to build each frame in real time, based on whatever the engine's variables specify at the moment a frame is requested. However, because vertical synchronization causes input lag, it interferes with the interactive nature of games,[2] and particularly interferes with games which require precise timing or fast reaction times.
- Benchmarking
Lastly, when one wishes to benchmark a video card or rendering engine, it is generally implied that the hardware and software render the display as fast as possible, without regard to monitor's capabilities or the resultant video tearing. Otherwise, the monitor and video card will throttle the benchmarking program, causing it to generate invalid results.
[edit] Beam tracing
Some graphics systems support a function wherein the software can perform its memory accesses so that they stay at the same time point relative to the display hardware's refresh cycle. In this case, the software would write to the areas of the display that have just been updated, staying just behind the monitor's active refresh point. This allows for copy routines or rendering engines which have a somewhat unpredictable throughput as long as the rendering engine is capable of "catching up" with the monitor's active refresh point when it falls behind.
Alternatively, the software could instead stay just ahead of the active refresh point. Depending on how far ahead one chooses to stay, this method may demand code that copies or renders the display at a fixed, constant speed. Too much latency would cause the monitor to overtake the software on occasion, leading to rendering artifacts, tearing, etc.
Demo software on classic systems such as the Commodore 64 and ZX Spectrum frequently exploited these techniques, owing to the predictable nature of their respective video systems, to achieve effects that might otherwise be impossible.
[edit] References
- ^ How to fight tearing, virtualdub.org, http://www.virtualdub.org/blog/pivot/entry.php?id=74, retrieved 2012-01-15
- ^ Derek Wilson (2009-07-16), Exploring Input Lag Inside and Out, AnandTech, http://www.anandtech.com/show/2803/5, retrieved 2012-01-15