Making Composite better for interactive apps

[Giuseppe Bilotta]

On Mon, Feb 5, 2018 at 9:24 PM, Keith Packard <keithp at keithp.com> wrote:
> What we want is for the compositing manager to get a clean snapshot of
> the system and to then be able to present that on the screen each
> frame. That means disallowing *all* changes for the duration of the
> construction of the presented image. This is independent of whether some
> windows are composited within the X server or composited by the
> Compositing Manager.

While I find this conceptually acceptable, I have an uneasy feeling
about its practicality.

I'm coming at this from the assumption that a Compositing Manager
would try to pump out frames as frequently as possible, in order to
minimize latency, which would lead to changes being disabled more
often than not. This is particularly damning if you consider the case
of multiple monitors with different refresh rates (think 144Hz
“gaming” monitor and 60Hz “secondary” monitor), which is something I
would recommend be considered in the design of this proposal, because
this is already a current reality that even Windows 10 has (or at
least has had) issues with (interestingly, apparently not WIndows 7).

> Here's a proposal for this issue:
>
>  1) Create a synchronization point within the X server which defines the
>     start of presentation (for a single screen? globally?).

If we want to take the separate refresh rates into account, I think
this should be per-window/virtual root. The rationale for this is that
a Compositing Manager which supports mixed refresh rates would create
one overlay per monitor, and update each at a separate frequency.

>  2) Between this point and the receipt of the PresentPixmap for this
>     frame, freeze all window drawing and geometry changes. A client
>     which sends a PresentPixmap or any window configuration request
>     which would affect the ongoing presentation will be blocked.
>
>  3) Once the presentation is complete, unblock all clients and process
>     their queued requests.

Ideally, the blockade should only involve the windows within the
affected area, but I'm not entirely sure this would be enforceable.

> One trivial way of implementing this is to have the Compositing Manager
> grab the X server at the start of the synchronization point, perform a
> round-trip operation to ensure that all pending updates are local and
> then run the presentation operation. After sending the PresentPixmap
> request, it would ungrab the server.

The question of the century is then: how much time will the server
spend in grabbed state? How much does this affect the server behavior?
Would it be more lightweight to have a specific message instead? This
could be used to carry extra information. For example, the AutoList
for this present may be sent with this message.


> This works for the current Manual compositing mechanism where the
> Compositing Manager is the one doing the drawing. So, I think the trick
> is simply to figure out how to make sure that the Compositing Manager is
> doing the drawing whenever a geometry change occurs.
>
> To fix windows in the Auto List, is it not sufficient to simply remove
> those windows from the Auto List and tell the Compositing manager? The
> Compositing Manager would then be responsible for constructing that
> region of the screen again

Maybe we don't even need to change the AutoList. What we want is to
ensure that the Compositing Manager has _processed_ the notification
of the geometry change for the windows in the AutoList. This could be
achieved for exampe by having the CM send also the geometry of the
AutoList windows when asking for the lock, and the server refusing the
lock if the geometry is not up to date, or something like that.


-- 
Giuseppe "Oblomov" Bilotta