A compositor is the graphics component that combines the separately rendered contents of every window into one final screen image, frame by frame, before it is sent to the display. In desktop environments, it is the layer that makes transparency, shadows, smooth animations, tear-free scrolling and mixed-DPI scaling possible, and it is often called a compositing window manager when it also positions and decorates windows.
The idea solves a basic problem of older graphics stacks. Without compositing, every application drew directly into a shared screen buffer, so overlapping windows had to repaint each other constantly. With compositing, each window renders into its own off-screen buffer, and the compositor assembles those buffers on the GPU, which makes the desktop predictable, smooth and easier to secure.
How a compositor builds each frame
A compositor works as a frame loop synchronized to the display refresh. Applications render their content into client buffers, usually in GPU memory, and notify the compositor that a new buffer is ready. The compositor then decides which surfaces are visible, applies transformations and effects, and draws the whole scene into a back buffer that is presented at the next vertical blank.
The process is closer to a small scene-graph renderer than to a traditional window manager. Each surface has a position, a stacking order, an opacity, a scale and sometimes a transform such as rotation. Because the compositor knows the complete picture, it can repaint only the damaged regions that changed since the last frame, which saves power on laptops and phones.
The following table shows the main stages of a typical composition cycle and what each stage contributes.
| Stage | What happens | Why it matters |
|---|---|---|
| Buffer submission | Applications attach a finished buffer to their surface | Prevents half-drawn windows on screen |
| Damage tracking | The compositor records which regions changed | Limits GPU work and power draw |
| Scene assembly | Visible surfaces are ordered, clipped and transformed | Handles overlap, scaling and effects |
| Rendering | The GPU draws surfaces into a back buffer | Enables blending, blur and shadows |
| Presentation | The frame is flipped to the display at vblank | Avoids tearing and keeps timing steady |
| Feedback | Clients learn when their frame was shown | Lets games and video pace their output |
Compositor, window manager and display server
The roles of compositor, window manager and display server overlap, and the overlap depends on the platform. On the classic X Window System, the X server owned the screen, a separate window manager placed windows, and a compositor was an optional extra client that redirected windows off-screen through the Composite extension. On Wayland, the three roles are merged into one process: the compositor is the display server.
This comparison clarifies which component is responsible for what on the major desktop platforms.
| Platform | Who composites | Who places windows | Who talks to hardware |
|---|---|---|---|
| X11 desktop | Optional compositor client | Window manager | X server |
| Wayland desktop | The compositor | The compositor | The compositor via kernel modesetting |
| Windows | Desktop Window Manager | Desktop Window Manager and shell | Graphics kernel and drivers |
| macOS | WindowServer | WindowServer and Dock | WindowServer and drivers |
The practical consequence is that on Wayland the compositor cannot be swapped independently of the desktop session. GNOME uses Mutter, KDE Plasma uses KWin, and tiling setups often use wlroots-based compositors such as Sway. On X11, by contrast, a user could run a lightweight window manager together with a standalone compositor such as picom.
Effects and features enabled by compositing
Compositing turns windows into textures that the GPU can freely manipulate, which is the foundation of most modern desktop effects. Some effects are purely visual, but several have real usability and quality value, especially tear-free presentation and fractional scaling across monitors with different pixel densities.
The table lists common capabilities and their practical cost.
| Capability | Benefit | Typical cost |
|---|---|---|
| Alpha transparency | Translucent panels and menus | Low GPU load |
| Drop shadows | Clearer window depth and focus | Low to moderate |
| Background blur | Readable translucent surfaces | Moderate, several sampling passes |
| Animations | Spatial cues for open, close and minimize | Moderate, latency if overdone |
| Fractional scaling | Correct size on high-DPI screens | Extra resampling, possible softness |
| Live previews | Thumbnails in task switchers and overviews | Memory for off-screen buffers |
| Variable refresh rate | Smoother games and video | Requires driver and display support |
Compositing also improves isolation between applications. Because each client only sees its own buffer, a program cannot simply read the pixels of another window, which is one reason Wayland requires explicit portals for screen capture and screen sharing.
Latency, performance and configuration choices
Every compositor adds a frame of buffering between the application and the screen, so the main trade-off is smoothness against input latency. At 60 Hz one frame lasts about 16.7 ms, and at 144 Hz about 6.9 ms, so the added delay shrinks on high-refresh displays. Well-designed compositors schedule their repaint as late as possible before vblank to keep this cost small.
Full-screen games and video players benefit from direct scanout, also called unredirection, in which the compositor hands the client buffer straight to the display hardware and skips its own rendering. Many compositors also support tearing control for games, deliberately allowing tearing in exchange for the lowest latency.
The decision table below summarizes common situations and sensible settings.
| Situation | Recommended setting | Reason |
|---|---|---|
| Competitive gaming | Direct scanout or tearing allowed | Lowest input latency |
| Office work on a laptop | Default effects, damage tracking | Smooth output with low power |
| Older integrated GPU | Reduced animations, no blur | Frees GPU time for applications |
| Mixed-DPI monitors | Per-monitor fractional scaling | Correct physical size on each screen |
| Remote or virtual machine | Minimal effects | Less data to encode and transmit |
Common problems and misconceptions
Many complaints attributed to a compositor are actually caused by driver behavior or application buffering. A clear diagnosis usually starts by checking whether the problem appears with effects reduced and with a different session type.
- Compositing is not just decoration. Disabling it on a modern desktop usually removes tear-free output and correct scaling, not only visual effects.
- Stutter often comes from missed frame deadlines, for example when a heavy blur pushes rendering past the refresh interval.
- Blurry applications on scaled screens usually indicate legacy X11 programs being upscaled through a compatibility layer such as Xwayland.
- Screen recording failures on Wayland typically mean the application does not use the desktop portal, not that the compositor is broken.
- A crashed Wayland compositor ends the session in most desktops, because it is also the display server; some compositors now support session recovery.
The simple explanation
Think of every open window as a separate sheet of transparent film. Each program paints only its own sheet. The compositor is the person who stacks all the sheets in the right order, adds shadows or a little transparency, and photographs the result for the screen many times per second.
Because the sheets are painted separately, nothing flickers when one window moves over another, and a slow program cannot leave a messy trail on the rest of the desktop. The key point is that the compositor builds the final picture you see; the programs only supply their own pieces.
How it is used in practice
A software developer works on a laptop with a built-in 14-inch panel at 200% scaling and an external 27-inch monitor at 100%. On an older X11 session, dragging a terminal from one screen to the other leaves it either too large or too small, and scrolling a long web page shows a visible horizontal tear.
After switching to a Wayland session, the compositor renders each window at the correct scale for the monitor it occupies, presents every frame at vblank and tracks damage so that an idle desktop barely uses the GPU. When the developer launches a full-screen game in the evening, the compositor switches to direct scanout, so the game reaches the display without an extra copy. The result is sharp text on both screens, no tearing and longer battery life.