Compositing: Difference between revisions

* '''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.

 

== Design Decisions ==

* '''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.