Making Composite better for interactive apps

[Keith Packard]

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

> Ok, I'm convinced. Just as a curiosity though, are there any plans (or
> anything special that needs planning) to support things such as
> adaptive sync?

Adaptive sync has a bunch of additional work required:

 1) Model the display time to provide estimates for when redisplay could
    occur.

 2) Create a way to send the planned frame time to all applications so
    they can draw the correct image for each frame

 3) Adapt the kernel interface to use time rather than frame count for
    page flipping.

I don't have any particular plans for this; I suspect it will be easiest
to make this work for direct display Vulkan first, then figure out how
to plumb it through X.

> Why would there be a need for the server to send an event to the CM?

My thinking is that the X server would lock the window system from
changes and then deliver an event to the Compositing Manager. Otherwise,
the CM would have to wake up and do a round trip to grab the server and
flush any pending events.

> I was actually more worried about potential dangers of deadlocks,
> actually, or something like that. Like, a client sending multiple
> events, some affecting windows on a blocked CRTC, others affecting
> windows on a non-blocked CRTC, and there being some kind of implicit
> assumption somewhere that the events would be processed in order,
> whereas during lockdown the server might end up serving them in a
> different order.

Oh, if the client does something that is blocked, the whole client gets
blocked. Otherwise, as you say, we violate the requirement for
sequential execution of X requests. The server is permitted to suspend
clients for arbitrary amounts of time, but not to perform operations out
of order.

> Sorry, I meant for the Compositing Manager to send a specific message.
> As in, instead of doing an actual grab/ungrab, have something like a
> PreparePresentNotify that the Compositing Manager sends to the server,
> with the information about the AutoList for the (upcoming)
> PresentPixmap and the CRTC to lock down.

Yeah, the problem is that the Compositing Manager can't send the Auto
List until after it has locked the server down and fetched all of the
pending updates, in case one of those changes invalidates the
assumptions built into the Auto List.

It still looks like the problem of making Composite reliably generate
correct and complete frames is separate from the goal of automatically
compositing some portion of the frame inside the X server.

I think I'm pretty much ready to go prototype the Auto List bits and see
how that goes.

-- 
-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/20180206/f44c60ae/attachment.sig>