Making Composite better for interactive apps

Giuseppe Bilotta giuseppe.bilotta at
Sun Feb 4 23:01:29 UTC 2018

On Sun, Feb 4, 2018 at 11:19 PM, Keith Packard <keithp at> wrote:
> Giuseppe Bilotta <giuseppe.bilotta at> writes:
>> Ah, good point. So Compton wouldn't break anyway, at worst it couldn't
>> use the feature reliably.
> Having any reasonable Compositing Manager not work is a sign that the
> design isn't quite right.

Well, apparently Compton already has some issues with DRI3/Present already, e.g. but maybe that's
Compton not being reasonable (using the root window instead of the
typical overlay).

> A key part of the design is that the Auto List be tied to a specific
> presentation on the screen; geometry for the Auto List windows is
> reserved in that image. So, we need to synchronously update the Auto
> List and the presented image, hence tying them together. Given that the
> Auto List is a (probably small) subset of the top-level windows, sending
> it each time is probably simpler than creating a new resource to hold
> it. Even sending a few hundred window IDs per frame wouldn't be
> terrible.


>> Then if I understand correctly Mode 1 could be implemented by delaying
>> the geometry change requests that happen after a Present request to
>> after the actual page flip (or whichever other time is deemed “safe”),
> You raise a good point here -- we want the client geometry change to be
> presented without any intermediate partial frames. I think the easiest
> way to manage that is to have the Compositing Manager take control of
> the display before the resize happens. It could be something as simple
> as blocking any resize request for a window in the Auto List and sending
> an event to the Compositing Manager to deal with the situation.
> How about this -- any configuration change (by a client other than the
> Compositing Manager) affecting a member of the Auto List would be
> blocked until a PresentPixmap request removes that element of the
> AutoList. Adding a member to the AutoList is sufficient to register an
> interest in the event. That would let us continue to allow arbitrary
> windows in the AutoList and ensure that no configuration changes occur
> while windows are on the Auto List.

Wait, I'm confused: if the Auto List is associated with a specific
presentation on the screen, and are thus in some sense ephemeral, how
can windows be added/removed from it? Is this to be read in the sense
that the configuration change is blocked until the CM does a Present
whose Auto List does not contain the window?

So if I read it correctly, it would work this way:

1. CM does a Present with an AutoList;
2. the server keeps the AutoList until the CM does a Present with a
different AutoList (or the CM connection is closed);
3. if anything other than the CM requests a config change for a Window
w in the AutoList, the request is stalled, but the CM is notified;
4. the CM gets notified of the pending config request, and on the next
Present it removes w from the AutoList;
5. the pending config change gets processed using the normal mechanism;
6. the CM is notified of the actual change, so it can put the window
back on the AutoList of the next Present;

Is this the general idea?

The biggest downside I see of this approach is that a CM can stall
config changes by keeping a window in the AutoList potentially forever
(either because of bugs or maliciously). This is particularly
important if any client can do Present requests with an AutoList.

Giuseppe "Oblomov" Bilotta

More information about the xorg-devel mailing list