Screen tearing

Screen tearing (also called tearing, image tearing or frame tearing) is a display artifact in which a single refresh of the screen shows parts of two or more rendered frames at once, separated by a horizontal break called a tear line. It happens when the graphics processor replaces the image being sent to the display partway through the display's scan-out instead of waiting for the next refresh cycle. The usual fix, vertical synchronization (V-Sync), delays the buffer swap until the display has finished the current refresh, which removes tearing but adds latency and causes stutter when the frame rate falls below the refresh rate. Variable refresh rate technologies such as NVIDIA G-SYNC, VESA Adaptive-Sync and AMD FreeSync instead adjust the display's refresh timing to the GPU, so frames can be shown as soon as they are finished without tearing.

In virtual reality and augmented reality, tearing is a particular concern. Michael Abrash, writing at Valve in 2013, called it "a highly visible artifact" and said that display artifacts of this kind are "far more visible for AR/VR in an HMD" than on a monitor. Current VR runtimes pace applications to the headset display and present frames through a compositor, and low-latency techniques that write into the image while it is being scanned out, such as front render buffering and "racing the beam", have to be timed carefully to avoid tearing.

Reviewed 6 October 2026. Checked every cited claim, quotation, date and author against the Poth et al. 2018 paper, NVIDIA G-SYNC article and press release, VESA, bit-tech, HDMI Forum, Vulkan, Microsoft, OpenXR, Meta, Unity and Imagination documentation, the Abrash and Carmack 2013 essays, and the Bishop 1994, Mine and Bishop, Riahi and Watson, Klein et al. and Floter et al. papers, with DOIs confirmed via Crossref. About review dates.

How it works

Scan-out and double buffering

A display does not receive a whole frame at one instant. The display reads out the GPU's frame buffer row by row, typically from the top-left corner to the bottom-right, at a fixed refresh rate on a standard monitor. Abrash gives the timing for a 60 Hz display: the bottom row is updated roughly 15 ms after the top row, a little less than the 16.7 ms frame period because of the vertical blanking time. The scan pattern began with the electron beam of a cathode-ray tube; on modern displays it reflects the order in which pixel data is streamed out of the graphics adapter, since links such as HDMI transmit pixels as a stream. Vertical sync is the moment when the "beam" returns from the bottom of the screen to the top.

Most graphics applications use double buffering. The new image is rendered into an invisible back buffer while the display reads the front buffer, and the two buffers are then swapped. Poth and colleagues describe the failure case: without synchronization between GPU and monitor, the buffers can be swapped after the monitor has already read the upper part of the old image, so the lower part is read from the new one. They define tearing as this effect "in which the old and new frame are mixed on the screen". NVIDIA's 2013 explanation of the same mechanism describes ignoring the monitor's refresh and updating the image "being scanned to the display in mid cycle"; when one refresh cycle shows two images, "a very obvious 'tear line' is evident at the break". Imagination Technologies gives a short working definition for VR developers: "One part of the screen still shows the old content and the other part already shows the new content", identifiable by cut-lines.

Appearance

Tearing is most obvious on vertical edges that move horizontally. Abrash suggested a test on a monitor with V-Sync off: dragging a screen-height window with a high-contrast border rapidly left and right makes the vertical edge break into segments, separated by the scan lines at which the copy to the screen overtook the raster.

John Carmack listed the factors that decide how bad a tear looks in his 2013 essay "Latency Mitigation Strategies". The impact depends on the disparity between the two frames on either side of the tear and on how long the tear line stays visible. Carmack wrote that tear lines look worse on a continuously illuminated LCD than on a CRT or laser projector, and worse on a 60 fps display than on a 120 fps display, while slow-switching LCD panels partly blur the tear compared with faster displays. When the GPU renders far faster than the display refreshes, a single refresh contains several bands. Carmack estimated that rendering 1000 frames per second gives "approximately 15 bands on screen separated by tear lines", which he still described as "quite objectionable on fast switching displays". Only if every scan line had its own image would the result look like a continuous "rolling shutter" instead of visible tears.

Synchronization methods

V-Sync and its costs

With V-Sync, the buffer swap is delayed until the monitor has finished reading out the current frame buffer, so the swap takes place during the vertical retrace and the monitor in effect triggers it. This prevents tearing; Poth and colleagues add that, with or without V-Sync, the displayed content cannot change at a temporal resolution higher than the refresh rate. NVIDIA's 2013 description of the trade-off is that forcing the GPU to wait for a new refresh cycle "causes stutter whenever the GPU frame rate is below the display refresh rate" and "increases latency, which introduces input lag". Riahi and Watson describe how the trade-off grew as GPUs improved: once frame rates overtook refresh rates, GPUs more often had to wait for the display to avoid tearing, which increased latency. Running without V-Sync gives lower latency, but in Carmack's words "only over a fraction of the screen, and with visible tear lines".

Present modes in graphics APIs

Modern graphics APIs expose the choice between waiting for vertical blanking and presenting immediately. The Vulkan specification defines its presentation modes in terms of whether tearing can be observed:

Vulkan present mode	Waits for vertical blanking	Tearing, per the specification
VK_PRESENT_MODE_IMMEDIATE_KHR	No	May result in visible tearing
VK_PRESENT_MODE_FIFO_KHR	Yes	Cannot be observed; the only mode that is required to be supported
VK_PRESENT_MODE_FIFO_RELAXED_KHR	Yes, unless a vertical blanking period has already passed since the last update	May tear in that late case
VK_PRESENT_MODE_MAILBOX_KHR	Yes	Cannot be observed
VK_PRESENT_MODE_FIFO_LATEST_READY_KHR	Yes	Cannot be observed
VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR	Not guaranteed; application and presentation engine share a single image, which may be updated at any point	May result in visible tearing
VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR	Image updated on the regular refresh cycle	May tear if rendering to the image is not timed correctly

On Microsoft Windows, DXGI ties tearing to variable refresh rate support. Microsoft's documentation states that "Variable refresh rate displays require tearing to be enabled", which it also calls "vsync-off" support. The feature requires Windows 10 with update KB3156421 or the Anniversary Update, works with Direct3D 11 and 12 flip-model swap chains, and the DXGI_PRESENT_ALLOW_TEARING flag can only be used with a sync interval of 0.

Variable refresh rate

NVIDIA announced G-SYNC on 18 October 2013 in Montreal. Its press release stated that turning on V-SYNC "eliminates tearing but causes increased lag and stutter", and that G-SYNC "synchronizes the monitor's refresh rate to the GPU's render rate, so images display the moment they are rendered", using an NVIDIA-designed module built into monitors together with support in certain Kepler-based GPUs. Poth and colleagues summarize the reversal: instead of the monitor triggering the GPU's buffer swap, the GPU's buffer swap triggers the screen refresh.

The Video Electronics Standards Association added Adaptive-Sync to DisplayPort 1.2a on 12 May 2014, stating that it "provides smoother, tear-free images for gaming" and lets the display "dynamically match a GPU's rendering rate, on a frame-by-frame basis". VESA noted that the technology had been part of its embedded DisplayPort (eDP) specification since 2009. AMD launched FreeSync, which uses DisplayPort Adaptive-Sync, with its first supporting driver on 19 March 2015. The HDMI Forum released HDMI 2.1 on 28 November 2017; its announcement said that Variable Refresh Rate (VRR) "reduces or eliminates lag, stutter and frame tearing". In their 2023 study, Klein and colleagues at NVIDIA summarize the benefit as avoiding the large stutter caused by small frame-time variations under V-Sync "while still avoiding tearing".

In VR and AR

Head-mounted displays

Abrash's 2013 analysis showed why neither option is clean in a head-mounted display with a rolling (scanned) display. If the frame waits for V-Sync and is then scanned out over about 15 ms, an object that the eye tracks across the display, or that stays fixed in the world while the head turns, appears slanted by about one degree at 60 degrees per second, because the bottom rows are lit later than the top rows. If V-Sync is not waited for, the slant disappears, since each strip is drawn from more recent position data, but tearing appears instead. He wrote that in either case the artifacts are "far more visible for AR/VR in an HMD", because "objects that dynamically warp and deform destroy the illusion of reality"; in AR they become apparent as misregistration against the real world. He added that because the eyes can counter-rotate to hold fixation while the head turns, relative speeds between eye and display in an HMD can be many times higher than when tracking a moving object with the head still, which produces proportionally greater slanting.

Carmack's essay of the following month addressed tearing as a latency question. His example latency for a fast system running with V-Sync was 16 to 32 ms, against 5 to 8 ms for the same system rendering unsynchronized at about 200 frames per second, but with the tear lines described above. He described the same scan-out shear for HMDs (the world appearing to "waggle" as the head rotates), noted that it is usually masked by the switching times of LCD HMDs but "obvious with fast OLED HMDs", and discussed warping the image scan line by scan line during scan-out as a way to correct it. He credited NVIDIA for an experimental driver with access to the current scan line number.

Compositors and frame pacing

Consumer VR software stacks keep the application synchronized with the headset display. The OpenXR function xrWaitFrame "throttles the application frame loop in order to synchronize application frame submissions with the display" and returns the predicted display time of the next composited frame. Meta's PC SDK documentation states that "The runtime handles distortion rendering, GPU synchronization, frame timing, and frame presentation to the HMD." In Unity, the QualitySettings.vSyncCount setting and the target frame rate are both ignored on VR platforms, where "the VR SDK controls the frame rate"; Unity's manual says that frame timing in VR mode works like V-Sync-enabled non-VR mode, but follows the VR SDK's timing rather than the underlying 3D API's V-Sync.

Under this model a late frame is not torn. According to Unity, the VR SDK may show the previously submitted frame, which "looks like judder", or apply rotational or positional reprojection. Oculus's 2016 description of Asynchronous Timewarp on the Rift makes the same point: an application that misses the V-Sync deadline would produce judder without ATW, which re-warps the latest available frame before each display scan-out at 90 Hz. The desktop mirror window is handled separately: Meta's documentation tells Vulkan developers to use VK_PRESENT_MODE_IMMEDIATE_KHR on AMD and VK_PRESENT_MODE_MAILBOX_KHR on NVIDIA, so that the render loop does not wait for V-Sync on the main monitor, which "introduces latency and degrades performance".

Front buffer and strip rendering

Rendering directly into the buffer that is on screen removes a frame of latency but also removes the protection against tearing. Imagination Technologies explains that with double buffering "the content rendered right now will be visible to the user one frame later", and that single buffering means rendering "always to the buffer which is on screen". Its strip-rendering approach for mobile VR divides the screen into strips and updates only the part that is not currently being scanned out; racing the beam updates ahead of the scan-out position, while chasing the beam updates behind it and is easier to implement. The Vulkan shared presentable image modes used for this kind of rendering are specified as possibly producing visible tearing. Abrash likewise described tearing as an artifact "that needs to be carefully smoothed over for any HMD racing-the-beam approach". The history of front-buffer access on the Samsung Gear VR, Android and PC VR is covered in the front render buffering article.

Research

Academic work on avoiding tearing without paying the latency of full double buffering predates consumer VR. In 1994, Gary Bishop, Henry Fuchs, Leonard McMillan and Ellen J. Scher Zagier of the University of North Carolina at Chapel Hill presented "frameless rendering" at SIGGRAPH. Their method computes each pixel from the most recent input and updates it on the display immediately, and they "avoid the image tearing normally associated with single-buffered displays by randomizing the order in which pixels are updated". The resulting images look blurry but move continuously, rather than jumping between discrete positions as in their double-buffered comparison. They noted that in a double-buffered system each new image is one update interval old when first displayed and is then held for another interval, and that in head-mounted displays such delays make the virtual world "appear unstable and to swim around as the user moves". A related UNC technical report by Mark Mine and Gary Bishop, "Just-In-Time Pixels", analyzed the errors caused by ignoring raster scan-out timing, described beam racing (which it says was first used in some early flight simulators), and reported work at UNC on a just-in-time pixel renderer for a see-through HMD to reduce registration errors between virtual and real objects.

Variable refresh rate has since become a research tool and a research subject. Poth and colleagues (2018) used G-Sync, with a 144 Hz monitor, to present visual stimuli for durations controllable in sub-millisecond steps above a 7 ms minimum, and confirmed the timing with photodiode measurements; they explain V-Sync as the standard way to guarantee "tearing-free stimulus presentation" in vision experiments. Riahi and Watson (2021) studied G-SYNC in 60 Hz gameplay and found smaller effects than an earlier 30 Hz study, although G-SYNC could still improve the performance of veteran players in challenging games; they listed a comparison of adaptive sync, V-Sync and "no VSync (with tearing)" as future work. Klein and colleagues (2023) examined variable frame timing, the uneven frame durations that VRR displays expose to users, and found that it affected perceived smoothness in first-person shooter gameplay.

Inside headsets, tearing-like artifacts can also come from rendering techniques rather than from scan-out. In a 2025 study presented at the ACM Symposium on Eye Tracking Research and Applications (ETRA), Flöter and colleagues rendered the periphery of an HMD image at a lower frame rate than the gaze-centered region, a temporal form of foveated rendering. They reported that moving objects crossing region boundaries "may appear to be cut off" and that head movement produces image tearing of the scene environment across regions; with 15 participants, they found that rendering cost could be reduced substantially before participants consistently reported temporal artifacts.

See also

• Variable refresh rate
• Refresh rate
• Frame rate
• Judder
• Front render buffering
• Motion-to-photon latency
• Timewarp
• Low persistence