Compositing

This page or section is a work in progress and may thus be incomplete. Its content may be changed in the near future.

Compositing is a method for providing a windowed GUI in which each application window has its own dedicated buffer - sometimes called a surface or canvas - in which it may draw as it pleases. These buffers are then blitted together by the compositor to produce a final image to display on the screen. The first major system to use a compositing window manager was the Amiga, which used a hardware blitter to composite windows. Notably, OS X was the first of the three mainstream OSes to ship with a compositing window manager, a feature it had since its first release. Other early mainstream compositors include Compiz (the first widely used dedicated X11 compositor) and DWM (the Windows compositor).

Overview

Compositors are so called because they composite windows together to form the image shown on screen. In order to do this, each window needs a dedicated buffer in which to draw. As such, compositors require more memory (either system memory or graphics memory) for each new window that will be displayed. The primary benefit to compositing over traditional window management is comparmentalization. Since each window has its own buffer to draw into, and since the compositor has complete control over the final image, artifacts typical of traditional window rendering such as the "IE 6 effect" are not typically seen in compositing window managers as the window manager does not need to wait for or request that windows repaint areas previously clipped or covered when they are moved. An additional benefit of compositing is that it allows the window manager to perform various transformations or rendering effects when compositing, such as alpha blending, rotation, scaling, duplication, and so on.

Prerequisites

If you want to build a compositor, you will need a few things:

• Video memory access - The compositor itself needs to be able to access video memory or have some interface to draw to the screen.
• Shared memory - An interface to graphics memory is technically superior to system memory, but is significantly more difficult to implement and requires a thorough understanding of graphics hardware. Regardless, you will need an interface by which two processes can read and write the same region of memory (or at least, one side needs to be able to write at least one region, and other side needs to be able to read from many such regions). You will need to be able to support many regions up to, and even beyond, the size of your display in pixels. The format for these shared memory regions will be discussed later.
• Message passing, streams, or sockets - Some form of synchronous and speedy IPC is required to send messages between the server and the various clients. A system which is engineered to work with a single server and multiple (possibly malicious or ambivalent) clients is preferred. This interface will be used by the client to send commands like "give me a window" and by the server to send events like "Alt+F4 pressed" or "mouse moved to x=259 y=530".

Design Decisions

There are two key design decisions to consider in a compositing window manager (though they can apply to other kinds of window managers as well):

• Canvas format - There are very many different pixel formats in use by graphics libraries, from RGBA32 (8 bits per pixel with an alpha channel) to YUV12. You can choose to support many of these or just one, but note that anything other than the native format you use to composite will require conversion somewhere.
• Window decorations - Most traditional window managers (both stacking and compositing) render decorations in the server, but a relatively new approach is to have clients render their own borders. The former moves complexity into the server, possibly requiring windows to have subparts and for the compositor to know about different "window types" (see various X11 compositors). Client-side decorations require clients to render on their own, which requires clients to somehow cooperate in determining how decorations should be themed (see Wayland, Quartz). Of course, an alternative approach is to not have decorations at all, a popular thematic decision amongst some technical Unix crowds.