ARGB visual

The X11 core protocol knows nothing about transparency. A visual describes how pixel values turn into colour, and at 24 bits every bit is taken by red, green and blue. What XRender added was a picture format, ARGB32, in which the top eight bits of a 32-bit value are read as coverage, and the server has since advertised a TrueColor visual of depth 32 next to the ordinary one. A window created with that visual carries an alpha channel that nobody used until Composite moved drawing into a separate pixmap in 2004: from then on the compositor can read the alpha and blend the window against whatever lies behind it. Shadows, fades and translucent terminals on Linux all take that route.

The traps are well known. A 32-bit window must be created with its own colormap for the visual and an explicit border_pixel, or the server answers BadMatch, an error generations of programmers have learned the hard way. With no compositor running the alpha is ignored entirely and the window shows whatever happens to be in the buffer, usually black. GTK gained gdk_screen_get_rgba_colormap in 2005 and Qt the WA_TranslucentBackground attribute in 2009 to pick the right visual automatically. Anyone who merely wants to fade a whole window skips all of this with the _NET_WM_WINDOW_OPACITY property, an informal convention from xcompmgr and Compiz that every compositor since has honoured without it ever being written into EWMH.