Screen Tearing in Linux and How Compositors Fix It
Screen tearing is a common visual artifact that occurs when a monitor displays information from multiple frames simultaneously, resulting in a fractured, horizontal split across moving images. In the Linux operating system, this issue historically stems from legacy display architectures that lack native frame synchronization. Compositors solve this problem by intercepting graphical output, buffering complete frames in memory, and delivering them to the display only during the monitor's vertical refresh cycle.
What Causes Screen Tearing?
A computer monitor updates its display line by line, from top to bottom, at a set frequency measured in Hertz (Hz)—commonly 60Hz, 144Hz, or higher. Meanwhile, the Graphics Processing Unit (GPU) renders frames dynamically at varying rates depending on the complexity of the scene.
Screen tearing happens when the GPU alters the frame buffer while the monitor is actively drawing a frame. Because the monitor reads the buffer mid-draw, the top portion of the screen displays the previous frame while the bottom displays the newly updated frame. This misalignment produces a visible horizontal "tear," especially noticeable during fast-motion video playback and gaming.
Why Tearing Frequently Occurred in Linux
The traditional display server for Linux, the X Window System (X11), was designed decades ago before hardware-accelerated 3D graphics and modern refresh standards existed. Under standard X11:
- Applications draw directly to the video memory buffer.
- No strict mechanism forces applications to coordinate frame updates with the monitor's refresh timing.
- The system relies on drivers and individual software to handle synchronization, which often defaults to unsynchronized rendering to maximize performance.
How Compositors Eliminate Tearing
A compositor is a system component that manages how window buffers are assembled into a single final image sent to the display. Instead of letting programs write directly to the screen buffer, the compositor acts as a mediator using several core techniques:
1. Off-Screen Buffering
The compositor directs each open application to render into its own dedicated, off-screen buffer. The operating system never exposes the active screen buffer to individual programs. The compositor then composites (blends) these separate layers together into one unified scene.
2. Double and Triple Buffering
To prevent drawing incomplete data, compositors employ multi-buffering:
- Front Buffer: Holds the frame currently being read and displayed by the monitor.
- Back Buffer: Holds the next frame being rendered by the compositor. Once the back buffer is fully rendered, the buffers swap. Triple buffering adds a third buffer, allowing the GPU to keep rendering new frames without waiting for the monitor to finish drawing, reducing input latency while maintaining stability.
3. Vertical Synchronization (VSync)
Compositors synchronize buffer swaps with the monitor's Vertical Blanking Interval (VBLANK)—the brief pause between when the monitor finishes drawing the bottom line of the screen and begins drawing the top line. Because the buffer swap occurs strictly during VBLANK, the monitor only ever reads a complete, uniform frame.
Modern Implementations: X11 vs. Wayland
The implementation of compositing varies depending on the Linux display stack in use:
- Standalone X11 Compositors: Window managers that
lack built-in compositors (such as i3, bspwm, or Openbox) rely on
standalone compositors like
picom. Configuringpicomwith an OpenGL backend and enabling VSync eliminates tearing across the desktop. - Integrated Desktop Compositors: Environments like GNOME (using Mutter) and KDE Plasma (using KWin) include integrated compositors with built-in VSync and buffer management.
- Wayland: The modern replacement for X11, Wayland, was engineered specifically to prevent tearing. In Wayland, the display server and the compositor are the same entity. Wayland enforces a strict rule often summarized as "every frame is perfect." Clients can only update buffers off-screen, and the compositor presents them strictly in sync with the display refresh cycle, making screen tearing fundamentally impossible under standard desktop operations.