Making Composite better for interactive apps

[Giuseppe Bilotta]

On Sat, Feb 3, 2018 at 9:23 PM, Keith Packard <keithp at keithp.com> wrote:
> (To be clear, what I'm proposing won't break anything that already
> works -- the Auto List is entirely driven by the compositor, so if you
> don't use it, you don't get this functionality.)
>
> But, yes, Compton wouldn't be able to use this if we relied on tying the
> window manager and compositor together.

Ah, good point. So Compton wouldn't break anyway, at worst it couldn't
use the feature reliably.

> So, to recap, I see three options
>
>   1) If the geometry change comes from a client other than the
>      Compositing Manager, block that geometry change and send an event
>      to the Compositing Manager to deal with it.
>
>   2) If the Window Manager and Compositing Manager are the same client,
>      have the Compositing Manager only add non override-redirect windows
>      to the Auto List, as it will naturally receive geometry change
>      requests by the client. If the Compositing Manager is separate,
>      then using the Auto List might result in mis-rendered frames.
>
>   3) Have the Compositing Manager specify the geometry with the root for
>      each element in the Auto List. Presentation of the auto list member
>      would use the specified geometry and not the actual window
>      geometry.
>
> Mode 3) leaves input running asynchronously with output, which is a bit
> disconcerting, but I think we're only talking about a single frame of
> lag assuming that the compositing manager is keeping up with the frame
> rate. Mode 1) actually looks more plausible in this light; in either of
> these two cases, you'd have some lag when reconfiguring windows.

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? Say
that I have a client which is a video player, and it has multiple
possible configurations (e.g. togglable controls at the bottom,
togglable playlist on the right, etc). By some means, the video player
asks the compositor to put the subwindow displaying the video (and
nothing else) in the Auto list. Now, if the user toggles one of the
extra panes, this would cause the subwindow which was added to the
Auto list to be resized, and this can happen without knowledge of the
the WM/CM, IIRC, so there would be a misrender even when the CM is the
WM.

So I think we need the CM to be _at least_ notified about geometry
changes in the Auto windows regardless of whether CM=WM or not.
However, if I understand the proposal correctly, the server knows
about the Auto list only at Present time, which would be too late.
Since the Auto list isn't likely to change frequently, would it be
possible to build it _separately_ from the Present call? The list
would then be stored on the server, which could use it to notify the
CM about any geometry changes in the windows within (unless notified
already by other means, of course). For multi-buffering, the CM could
request the creation of multiple Auto lists, be notified about
geometry changes from the union thereof, and specify which Auto list
to use for each specific Present invocation. 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?

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”),
for all windows in the Auto list. Then the lag in the window
reconfiguration should be typically less than 1 frame (and probably
preferrable to the guaranteed fulle frame desync between input and
output that would come with Mode 3?).

-- 
Giuseppe "Oblomov" Bilotta