XCOMPOSITE(3)

๐Ÿ“ฆ
version 0.4.6 ยท 3 versions
, in alpine 3.22, alpine 3.23, centos-stream 10, debian trixie, fedora 43, fedora 44, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

๐Ÿ’– XCOMPOSITE โ€” okay bestie, let's talk about the X Composite Extension library โœจ

So this is XCOMPOSITE(3), part of libXcomposite, and it's literally the library that makes your fancy compositor things happen on screen. Sit down, hydrate, we're doing this. ๐Ÿซถ


๐ŸŒธ NAME ๐ŸŒธ

Xcomposite โ€” the X Composite Extension library. That's it, that's the name, it's giving main character energy and it knows it. ๐Ÿ‘‘


โœจ SYNOPSIS โœจ

First things first, you gotta pull in the header, no cap:

#include <X11/extensions/Xcomposite.h>

And here's every single function, exactly as it lives, no edits, no vibes-based renaming:

Bool XCompositeQueryExtension(Display *dpy, int *event_base_return,
                              int *error_base_return);

Status XCompositeQueryVersion(Display *dpy, int *major_version_return,
                              int *minor_version_return);

int XCompositeVersion(void);

void XCompositeRedirectWindow(Display *dpy, Window window, int update);

void XCompositeRedirectSubwindows(Display *dpy, Window window,
                                  int update);

void XCompositeUnredirectWindow(Display *dpy, Window window,
                                int update);

void XCompositeUnredirectSubwindows(Display *dpy, Window window,
                                    int update);

XserverRegion XCompositeCreateRegionFromBorderClip(Display *dpy,
                                                   Window window);

Pixmap XCompositeNameWindowPixmap(Display *dpy, Window window);

Window XCompositeGetOverlayWindow(Display *dpy, Window window);

void XCompositeReleaseOverlayWindow(Display *dpy, Window window);

Slay. That's the whole roster. ๐Ÿ’…


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

Okay so the composite extension isn't just one thing, it's a whole little ecosystem of related mechanisms, and the way that it does all of this is honestly iconic. Let's break it down:

Per-hierarchy storage ๐Ÿ’พ

The rendering of an entire hierarchy of windows gets redirected to off-screen storage. The pixels of that hierarchy are available whenever it is viewable. Storage is automatically reallocated when the top level window changes size. Contents beyond the geometry of the top window are not preserved. (Noted, bestie โ€” don't come for me when your overflow pixels ghost you.)

Automatic shadow update ๐ŸŒ’

When a hierarchy is rendered off-screen, the X server provides an automatic mechanism for presenting those contents within the parent window. The implementation is free to make this update lag behind actual rendering operations by an unspecified amount of time. This automatic update mechanism may be disabled so that the parent window contents can be completely determined by an external application. So yeah, it can be a little late to the party, but you can also just take the wheel yourself. ๐Ÿš—

Composite Overlay Window ๐ŸชŸ

Version 0.3 of the protocol adds the Composite Overlay Window, which provides compositing managers with a surface on which to draw without interference. This window is always above normal windows and is always below the screen saver window. It is an InputOutput window whose width and height are the screen dimensions. Its visual is the root visual and its border width is zero. Attempts to redirect it using the composite extension are ignored. This window does not appear in the reply of the QueryTree request. It is also an override redirect window. These last two features make it invisible to window managers and other X11 clients. The only way to access the XID of this window is via the CompositeGetOverlayWindow request. Initially, the Composite Overlay Window is unmapped.

She's mysterious. She's above you but below the screensaver. She does not show up in QueryTree. We love a lowkey legend. ๐Ÿ™ˆ

Parent window clipping โœ‚๏ธ

Version 0.4 of the protocol modifies the semantics of parent window clipping in the presence of manual redirected children. With this version, the area in the parent covered by manual redirected children is left in the parent clip list instead of being removed as in older versions.

The big picture ๐Ÿ–ผ๏ธ

Per-hierarchy storage may be created for individual windows or for all children of a window. Manual shadow update may be selected by only a single application for each window; manual update may also be selected on a per-window basis or for each child of a window. Detecting when to update may be done with the Damage extension.

The off-screen storage includes the window contents, its borders and the contents of all descendants. Everything. The whole family. ๐ŸŒˆ


๐ŸŽ€ ARGUMENTS ๐ŸŽ€

  • display โ€” Pointer to the Display structure returned from XOpenDisplay for the connection to the X server. Your whole connection to the X server lives here, so like, don't lose it. ๐Ÿ˜ญ
  • event_base_return โ€” Pointer to integer where the base value for Composite Extension events will be stored.
  • error_base_return โ€” Pointer to integer where the base value for Composite Extension errors will be stored.
  • major_version_return โ€” Pointer to integer where the major version of the Composite Extension supported by the X server will be stored.
  • minor_version_return โ€” Pointer to integer where the minor version of the Composite Extension supported by the X server will be stored.
  • window โ€” Specifies the window ID to operate on. The specific girl. The one we're doing this for. ๐Ÿ’œ
  • update โ€” Specifies the mode for updating the window contents. Must be either CompositeRedirectAutomatic or CompositeRedirectManual. That's it, those are the only two, don't try to freestyle it.

๐Ÿ”ฅ FUNCTIONS ๐Ÿ”ฅ

XCompositeQueryExtension

XCompositeQueryExtension determines if the Composite Extension is available on the given display. It returns True if the extension is supported, otherwise False. If the extension is present, the base values for events and errors are returned, and can be used to decode incoming event and error values. Basically a vibe check for the extension itself. โœ…

XCompositeQueryVersion

XCompositeQueryVersion determines if the X Server supports a version of the X Composite Extension which is compatible with the client library. A non-zero Status is returned if a compatible version of the extension is supported, otherwise a zero Status is returned. If the extension is supported, the major and minor version numbers are returned to indicate the level of Composite Extension support.

โš ๏ธ No other XComposite functions (except XCompositeQueryExtension) may be called before this function. If a client violates this rule, the effects of all subsequent XComposite calls that it makes are undefined. Like, do not skip this step. This is the line. Don't cross it. ๐Ÿ’€

XCompositeVersion

XCompositeVersion returns the version of the X Composite library. The version number is encoded as:

(major * 10000) + (minor * 100) + revision

For example, version 1.4.6 would be encoded as the integer 10406.

Math girlies rise up, the encoding is literally just vibes in base 100. ๐Ÿงฎโœจ

XCompositeRedirectWindow

XCompositeRedirectWindow requests the X server to direct the hierarchy starting at window to off-screen storage. The update argument specifies whether the contents are mirrored to the parent window automatically or not. Only one client at a time may specify an update type of CompositeRedirectManual, another attempt will result in a BadAccess error. When all clients enabling redirection terminate, the redirection will automatically be disabled.

The root window may not be redirected. Doing so results in a BadMatch error. Specifying an invalid window id will result in a BadWindow error.

๐Ÿšซ Root window? Off limits. Don't even try it, bestie.

XCompositeRedirectSubwindows

XCompositeRedirectSubwindows requests the X server to redirect hierarchies starting at all current and future children of window as in XCompositeRedirectWindow. If update is CompositeRedirectManual, then painting of the window background during window manipulation and ClearArea requests is inhibited. Future children included โ€” she's thinking ahead, that's called foresight. ๐Ÿ”ฎ

XCompositeUnredirectWindow

XCompositeUnredirectWindow requests the X server to terminate redirection of window. If the specified window was not selected for redirection by the current client, a BadValue error results. Not yours? Not your business. Simple as that. ๐Ÿ’…

XCompositeUnredirectSubwindows

XCompositeUnredirectWindow requests the X server to terminate redirection of all children of window. If the specified window was not selected for sub-redirection by the current client, a BadValue error results.

(Yes, the page really does say XCompositeUnredirectWindow in that paragraph โ€” I'm not fixing it, I'm just reporting it, that's the manpage's business, not mine. ๐Ÿ™ˆ)

XCompositeCreateRegionFromBorderClip

XCompositeCreateRegionFromBorderClip creates a region containing the "usual" border clip value; that is the area of the window clipped against siblings and the parent. This region can be used to restrict rendering to suitable areas while updating only a single window. The region is copied at the moment the request is executed; future changes to the window hierarchy will not be reflected in this region. It's a snapshot, not a livestream, bestie. ๐Ÿ“ธ

XCompositeNameWindowPixmap

XCompositeNameWindowPixmap creates and returns a pixmap id that serves as a reference to the off-screen storage for window. This pixmap will remain allocated until freed, even if the window is unmapped, reconfigured or destroyed. However, the window will get a new pixmap allocated each time it is mapped or resized, so this function will need to be reinvoked for the client to continue to refer to the storage holding the current window contents. Generates a BadMatch error if window is not redirected or is not visible.

The X server must support at least version 0.2 of the Composite Extension for XCompositeNameWindowPixmap.

๐Ÿซ  This one keeps you on your toes: map it or resize it and boom, new pixmap, you gotta call again. It's not toxic, it's just... high maintenance.

XCompositeGetOverlayWindow

XCompositeGetOverlayWindow returns the window ID of the Composite Overlay Window for the screen specified by the argument window. This function notifies the X server that the client wishes to use the Composite Overlay Window of this screen. If this Composite Overlay Window has not yet been mapped, it is mapped by this request.

The Composite Overlay Window for a particular screen will be unmapped when all clients who have called this function have either called XCompositeReleaseOverlayWindow for that screen, or terminated their connection to the X server.

The X server must support at least version 0.3 of the Composite Extension for XCompositeGetOverlayWindow.

XCompositeReleaseOverlayWindow

This request specifies that the client is no longer using the Composite Overlay Window on the screen specified by the argument window. A screen's Composite Overlay Window is unmapped when there are no longer any clients using it.

The X server must support at least version 0.3 of the Composite Extension for XCompositeReleaseOverlayWindow.

๐Ÿค Be a good citizen: you called Get, you call Release. Clean up after yourself, that's the rule.

๐Ÿ‘‘ AUTHORS ๐Ÿ‘‘

  • Keith Packard <keithp@keithp.com> โ€” Extension specification and implementation
  • Deron Johnson <deron.johnson@sun.com> โ€” Overlay Window specification and implementation

Legends, both of them. Thank you for your service. ๐Ÿซถ


๐ŸŒŸ Sign-off ๐ŸŒŸ

And that's the whole page, bestie! This little gem is dated 23 April 2007 and comes to you as part of libXcomposite โ€” and yes, the manual section is 3, because it's a library function page, iykyk. Go redirect something (not the root window, I'm watching you). Byeee! ๐Ÿ’–โœจ๐ŸŽ€๐Ÿฆ‹๐ŸŒธ