Making Composite better for interactive apps

[Giuseppe Bilotta]

On Sun, Feb 4, 2018 at 11:19 PM, Keith Packard <keithp at keithp.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta at gmail.com> 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.
https://bugs.freedesktop.org/show_bug.cgi?id=97916 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