Xlib: Compositing a window

[Adam Jackson]

On Fri, 2016-04-29 at 16:09 +0200, Erlend Langseth wrote:

> The first problem is that nothing appears in the window when I
> comment out line 41. I'm unsure how it normally works, but I suppose
> that when I do compositing, then I want the windows to be entierly
> off screen, so I don't want to `XMapWindow` them. Please correct me
> if I'm wrong.

I must correct you, you are wrong. Unmapped windows have no pixel
storage even with compositing enabled. A manually redirected window
effectively does have "entirely off-screen" storage though.

> Another problem is that once I try to listen for Damage events, it
> only happens once, in the start. Generally I only want to know when
> damage happens, not which parts are damaged etc. What did I miss
> here?

Yep, that's how it works. Registering for damage on a drawable triggers
an initial damage event for the whole drawable [1]. It's then your
responsibility to tell the X server that you've processed that event by
using XDamageSubtract.

In your particular case, you're asking for ReportNonEmpty, so you want
to say XDamageSubtract(dpy, damage, None, None) to report that you've
handled all the damage for the drawable. Once you've done that the
server will generate new events when new damage happens, and you'll
need to subtract it back off again each time.

> And a final question: Looking at xcompmgr source code, it uses
> 'Regions' from the Xfixes extension, such as XFixesCreateRegion etc.
> Will I need that in my quest to do simple compositing without
> consideration to exactly which area is damaged?

No. Using XDamageSubtract as above is sufficient to clear drawable
damage away without building regions.

> So my quest is to assemble the bare essentials of compositing several
> ARGB windows onto one window. I have probably skipped something
> essential, but I do find it quite hard to find out exactly what I
> need to do (have any general tips on how to get around the poor
> documentation of some parts of Xlib?).

For many of the "modern" extensions like Damage or Present, the best
documentation is simply the protocol specification, as the library
interface is a straightforward mapping onto the protocol, and often the
spec describes the rationale and expected usage. For Damage, for
example:

https://cgit.freedesktop.org/xorg/proto/damageproto/tree/damageproto.txt

The missing man pages are pretty lame; we'd happily take patches.

[1] - Practically speaking, this is to provide a natural way for
compositors to start processing damage events, rather than needing an
artificial "pretend the whole surface is damaged" step on the first
iteration.

- ajax