Making Composite better for interactive apps

[Keith Packard]

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.

> Actually I'm not sure 2) would work reliably even in the WM == CM
> case, if _any_ descendant can be put in the Auto list, since the WM
> wouldn't be aware of geometry changes in nested windows, right?

It would "work", in that the window contents wouldn't escape the bounds
of the managed area, but it wouldn't be perfect. But, it wouldn't be any
worse than we have today -- reconfiguring subwindows happens
non-atomically, and so partial rendering adventures happen all of the
time. Presumably the CM would track the geometry of windows in the Auto
List and be aware of the change, repairing the screen in a subsequent
frame.

I'm starting to wonder if nested descendants in the Auto List is a good
idea. Keeping the boundary between Compositing Manager and application
at the top-level client window has proven pretty workable so far. Let
clients be responsible for ensuring that their top-level window contents
represent their desired presentation at all times.

> However, if I understand the proposal correctly, the server knows
> about the Auto list only at Present time, which would be too late.

The Compositing Manager can monitor window geometry for any window it
chooses, whether or not that window is in the Auto List.

> Since the Auto list isn't likely to change frequently, would it be
> possible to build it _separately_ from the Present call?

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.

> Or maybe just require that the CM manually elect to get notified of
> geometry changes for the windows they plan on putting in the Auto
> list?

That's far easier as it requires no additional X server code, and only a
small amount of code in the Compositing Manager.

> 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.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180204/a764124e/attachment.sig>