Screen tearing
Screen tearing is a visual artifact in video display where a display device shows information from multiple frames in a single screen draw.[1]
The artifact occurs when the video feed to the device is not in sync with the display's refresh rate. This can be 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). It can also occur simply from lack of sync between two equal frame rates, in which case the tear line is at a fixed location that corresponds 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 in horizontally-moving visuals, such as in slow camera pans in a movie, or classic side-scrolling video games.
Screen tearing is less noticeable when more than two frames finish rendering during the same refresh interval, since this means the screen has several narrower tears instead of a single wider one.
.mw-parser-output .toclimit-2 .toclevel-1 ul,.mw-parser-output .toclimit-3 .toclevel-2 ul,.mw-parser-output .toclimit-4 .toclevel-3 ul,.mw-parser-output .toclimit-5 .toclevel-4 ul,.mw-parser-output .toclimit-6 .toclevel-5 ul,.mw-parser-output .toclimit-7 .toclevel-6 ul{display:none}
Contents
1 Prevention
1.1 V-sync
1.1.1 Complications
1.1.1.1 Judder
1.1.1.2 Input lag
1.1.1.3 Benchmarking
1.2 Other techniques
2 References
Prevention
Ways to prevent video tearing depend on the display device and video card technology, software in use, and the nature of the video material. The most common solution is to use multiple buffering.
Most systems use multiple buffering and some means of synchronization of display and video memory refresh cycles.
V-sync
Vertical synchronization is an option in most systems, wherein the video card is prevented from doing anything visible to the display memory until after the monitor finishes its current refresh cycle.
During the vertical blanking interval, the driver orders 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).
Nvidia and AMD video adapters provide an 'Adaptive Vsync' option. This will only turn on vertical synchronization when the frame rate of the software exceeds the display's refresh rate, disabling it otherwise. This eliminates the stutter that occurs as the rendering engine frame rate drops below the display's refresh rate.[2]
Alternatively, technologies like FreeSync[3] and G-Sync[4] reverse the concept, adapting the display's refresh rate to the content coming from the computer. These technologies require specific support from both the video adapter and the display.
Complications
When vertical synchronization is used, the frame rate of the rendering engine gets limited to the video signal frame rate. Though this feature normally improves video quality, it involves trade-offs in some cases.
Judder
Vertical synchronization can also cause 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 misses the monitor's deadline fairly frequently, in addition to the interceding frames being displayed at a slightly higher rate than intended for, resulting in an effect similar to judder. (See Telecine: Frame rate differences.)
Input lag
Video games, which use a wide variety of rendering engines, tend to benefit 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,[5] and particularly interferes with games that require precise timing or fast reaction times.
Benchmarking
Lastly, benchmarking a video card or rendering engine generally implies that the hardware and software render the display as fast as possible, without regard to monitor capabilities or resultant video tearing. Otherwise, the monitor and video card throttle the benchmarking program, causing invalid results.
Other techniques
Some graphics systems let the software perform its memory accesses so that they stay at the same time point relative to the display hardware's refresh cycle, known as raster interrupt or racing the beam. In this case, the software writes 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 with less predictable throughput, as long as the rendering engine can "catch up" with the monitor's active refresh point when it falls behind.
Alternatively, software can 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 causes 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.
References
^ How to fight tearing, virtualdub.org, 2005-10-31, archived from the original on 2015-05-30, retrieved 2015-05-19.mw-parser-output cite.citation{font-style:inherit}.mw-parser-output .citation q{quotes:"""""""'""'"}.mw-parser-output .citation .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .citation .cs1-lock-limited a,.mw-parser-output .citation .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .citation .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration{color:#555}.mw-parser-output .cs1-subscription span,.mw-parser-output .cs1-registration span{border-bottom:1px dotted;cursor:help}.mw-parser-output .cs1-ws-icon a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output code.cs1-code{color:inherit;background:inherit;border:inherit;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;font-size:100%}.mw-parser-output .cs1-visible-error{font-size:100%}.mw-parser-output .cs1-maint{display:none;color:#33aa33;margin-left:0.3em}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration,.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left,.mw-parser-output .cs1-kern-wl-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right,.mw-parser-output .cs1-kern-wl-right{padding-right:0.2em}
^ Adaptive VSync, nvidia.com, retrieved 2014-01-28
^ https://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/freesync
^ https://www.cnet.com/news/nvidia-g-sync-is-a-smooth-move-for-pc-games/
^ Derek Wilson (2009-07-16), Exploring Input Lag Inside and Out, AnandTech, retrieved 2012-01-15
Comments
Post a Comment