Part 1
A screen is painted, not flashed
On an old CRT monitor this was literal: an electron beam swept across the glass one line at a time, left to right, top to bottom, then flew back to the top and started again. A modern LCD or OLED has no beam, but the cable (HDMI, DisplayPort) still delivers pixels in that same order, and the panel still updates in that order. Everyone still says beam and scan-out, so this guide does too.
Between one pass and the next there is a short pause called the vertical blanking interval, or vblank. It is a leftover from the time the beam needed to fly back. It matters today because it is the one moment when the whole screen is "between frames", and it is the safe moment to change what the display is reading.
Part 2 · Experiment
Swap buffers mid-sweep
The sweep below is slowed down so you can watch it. The bright line is the beam. Everything above it has already been drawn this pass. Everything below it still shows the previous pass. The world is panning sideways the whole time, so any two frames are slightly different pictures.
Press "Swap buffers now" while the beam is somewhere in the middle of the screen. Pink marks the tear.
- the beam (rows above it are freshly drawn)
- a tear (two frames meet here)
- Labels like
#3say which frame each part of the screen came from.
Whole screen shows frame #0. No tear.
Left is slower. At "real time" the beam crosses the screen in 1/60th of a second and you will not be able to follow it. That is why tearing is so hard to describe and so easy to see.
Paused, or prefer to go step by step? "Nudge beam" moves it down a small step at a time, so you can place the swap exactly where you want it.
Try: swap twice in quick succession (small offset, because the world barely moved between the frames), then swap once after waiting a long time (large offset). Notice the fixed circle in the middle never tears. Tearing only shows up on things that moved.
What a "swap" really is
The GPU never draws into the picture the display is reading. It draws into a hidden back buffer while the display reads the front buffer. When the frame is finished, the two buffers trade roles. That trade is the swap (or flip), and it is nearly instant.
Nobody told the display to wait for the end of its pass. So if the swap lands while the display is part-way down the front buffer, it simply carries on reading from what is now the new front buffer. Rows it already sent stay old, and the rest come from the new frame.
Part 3 · The lab
Now let the GPU do the swapping
In the lab, a simulated GPU renders frames continuously and decides when to swap them in. Pick a sync mode and move the sliders. The chart under the screen shows exactly what is happening: the beam's position over time, and when each swap lands.
- GPU makes
- 0 fps
- Screen shows
- 0 new images/s
- Tears
- 0 per second
- Frames dropped
- 0 per second
- Image age at mid-screen
- – ms
Measured inside the simulation, per second of simulated time (not real time), so the numbers stay correct in slow motion. "Image age" is how long ago the game world was sampled when the middle of the screen lights up. It is a stand-in for input lag.
- the diagonals are the beam scanning down the screen (colour = which frame it is reading)
- dashed verticals are buffer swaps
- a swap that crosses a diagonal is a tear, at exactly that height
Read it left to right. The shaded gaps are vblank, the beam returning to the top. The strip to the right of the bright "now" line is the future: swaps the GPU has already scheduled.
Try these
Part 4
What decides where a tear lands, and how bad it looks
With VSync off, every tear is a vertical dashed line on the chart hitting a diagonal. Four things follow from that picture.
- Where. The height of a tear is how far through its refresh the display was when the swap happened. A swap 40% of the way through a refresh makes a seam 40% of the way down.
- How many. Roughly
fps ÷ Hztears per refresh. A GPU running at twice the refresh rate puts about two seams on every screen. (A swap that lands in vblank makes no seam, which is why the measured number is a little lower.) - How big. The sideways jump across a seam is the pan speed multiplied by the time between the two frames. Faster camera movement or a lower frame rate gives a bigger jump. This is why a low frame rate has fewer, nastier tears and a high frame rate has more, subtler ones. Drag the pan speed slider to 0.1 and the tears nearly vanish. Nothing moved, so there is nothing to mismatch.
- Whether it moves. If
fpsequalsHzexactly, each swap lands at the same point in every refresh, so the seam stays still. If they differ slightly, the seam drifts by|Hz − fps|screen heights per second. That is the slow rolling tear you see when a game sits just under the refresh rate. Frame-time jitter scrambles all of this and makes the seams jump around.
Why it looks worse in some games than others. A tear is the difference between two frames, drawn as a hard edge. Slow, mostly static scenes barely change between frames, so there is almost no edge to see. Fast camera pans across high-contrast vertical edges (fences, doorframes, skyscrapers) are the worst case, which is exactly what the bars in this simulation are.
Part 5
The fixes, and what each one costs
Every fix works by removing one half of the mismatch: either the swap waits for the display, or the display waits for the swap. Use the lab's mode buttons to see each one on the chart.
- VSync on: swaps are only allowed during vblank. The seam cannot form because the swap never lands mid-scan. The price is that a finished frame must wait, and the GPU, with no free buffer, waits too. If a frame takes even slightly longer than one refresh, it misses its slot and the display repeats the old image for another full refresh. With a 60 Hz screen the effective rate steps down through 60, 30, 20, 15 … Try the "VSync stutter" preset.
- Triple buffering: add a third buffer so the GPU always has somewhere to draw. It keeps rendering flat out, and at each vblank the display picks the newest finished frame. Older ones are dropped. No tearing and no step-down, but the GPU runs at full tilt (more heat and power) and you pay for an extra buffer. NVIDIA's "Fast Sync" and AMD's "Enhanced Sync" work in a similar spirit.
- Adaptive sync (G-Sync, FreeSync, "VRR"): flip the problem around. The display starts a new scan-out when the GPU has a finished frame, within the panel's supported range. There is no fixed vblank to miss. The chart shows diagonals starting wherever frames land. It needs a compatible panel, cable and GPU, and works best if you cap your frame rate just under the panel's maximum so the GPU does not hit the ceiling and block.
| Mode | Tearing | Lag | Smoothness | What you give up |
|---|---|---|---|---|
| VSync off | Yes | Lowest | Fast but uneven | Image integrity |
| VSync on | None | Higher (waits for vblank, may queue) | Stutters when below refresh rate | Lag and frame-rate steps |
| Triple buffering | None | Low to medium | Smoother than VSync on, some judder from dropped frames | Power, heat, a spare buffer |
| Adaptive sync | None (inside its range) | Low | Smooth even at uneven frame rates | A compatible display and GPU |
You can see the lag column in the lab's "image age" readout. VSync on adds the wait for the next vblank on top of the render time, while VSync off shows the freshest frame the moment it is done, even if only part of the screen can take it.
Why doesn't your desktop tear? Most modern desktop compositors (Windows' DWM, macOS, Wayland compositors) assemble the final screen themselves and hand it to the display at vblank, so ordinary windows don't tear. Tearing is mostly a fullscreen-game problem, or shows up on setups where compositing is switched off.
Glossary
- Scan-out
- Sending the finished picture to the display, row by row, top to bottom.
- Refresh rate (Hz)
- How many scan-outs the display does per second. 60 Hz means one every 16.7 ms.
- Vblank
- The short gap between the last row of one scan-out and the first row of the next.
- Front / back buffer
- The picture the display is reading, and the picture the GPU is drawing.
- Swap / flip
- Trading the roles of the front and back buffer.
- Frame rate (fps)
- How many frames the GPU finishes per second. Unrelated to refresh rate unless something ties them together.
- Judder / stutter
- Uneven gaps between the moments the screen shows new images.
Part 6
Recap
- Cause: the display reads the picture row by row over many milliseconds, and an unsynchronised buffer swap can land halfway through.
- Look: a hard sideways seam between two moments in time, at a height set by when the swap landed.
- Count and size: about fps ÷ Hz seams per screen, each as wide as the world moved between the two frames.
- Fixes: make the swap wait for vblank (VSync), always show the newest finished frame at vblank (triple buffering), or make the display wait for the GPU (adaptive sync).
- Trade-off: every fix that removes tearing without adaptive sync costs lag, stutter or power.
Next experiments
- Set VSync off, 60 Hz, 60 fps and then tap the frame-rate slider one step. Watch the frozen seam start to crawl.
- Set VSync on at 60 Hz and sweep the frame-rate slider from 70 down to 25. Watch "Screen shows" fall in steps, not smoothly.
- Compare "Image age" between VSync off and VSync on at the same settings.
- Turn on adaptive sync and push jitter up to 60%. The picture stays whole while the diagonals stagger.
Further reading: Screen tearing, Multiple buffering, Variable refresh rate, Raster scan (Wikipedia).