Making Composite better for interactive apps

[Keith Packard]

Giuseppe Bilotta <giuseppe.bilotta at gmail.com> writes:

> So the only difference between the two approaches is that in the
> current async way the server can cover the latency that would come
> from waiting for the WM to complete the mapping (or in general other
> such requests) by processing other events, but this comes at the cost
> of the complexity inevitably deriving from the asynchronicity itself,
> both in terms of protocol and in things like trying to guarantee
> consistency between disparate events affecting the same windows (such
> as the geometry changes' interaction with the presentation that we
> discussed so far).

Yeah, so the core protocol was designed for this asynchronous operation,
and all clients are currently required to handle it. However, we can't
exactly change things so that this new Composite behavior could run
asynchronously as clients would probably not respond well.

> I do agree however that having some better ways to enforce sequencing
> in some circumstances would be preferrable.

And for things which happen no more often than once per frame, a bit of
synchronization seems fine.

Ok, I've been mulling this over since I woke up this morning. Let's
go back a few steps and think about how we actually want Compositing to
work in general.

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.

If a window gets resized between the time the compositing manager
decides to start drawing and actually gets around to fetching the bits,
then the resulting image will be inconsistent. Which is exactly the same
if we have the X server doing that compositing, assuming that the
Compositing Manager has control over the geometry in the Auto
List. Which means this problem is at least partially separable from my
original issue and we can think about it in some isolation.

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?). This would
    generally be a time far enough before vblank that all rendering can
    be performed and still get the buffer queued before vblank so that
    the swap will work.

 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.

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.

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.

> Well, obviously, these would be more along general thoughts about how
> things could be different for X12 ;-) Or at least design principles
> that may be kept in mind for future extensions.

Yup. Always good to know what doesn't work like we want in case we can
avoid that in related operations, or even fix things in the future.

-- 
-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/20180205/bcab0f6c/attachment.sig>