Making Composite better for interactive apps

[Keith Packard]

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

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

Yeah, we'd definitely have to experiment with both X server and
Compositing Manager changes together to see what actually works.

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

I think that's the wrong assumption. Given that you have monitors at a
fixed refresh rate, you want each frame on the monitor to contain the
most recent changes for all windows. That means painting the screen
after all applications have updated for the current frame. Because we
can't really tell when applications are done updating, as some may skip
a frame now and then, what we can do is to delay painting until there's
just barely enough time left before vblank to paint the frame. We've got
lots of information that can be used to help predict when that time
should be.

One option would be to bury heuristics like this into the X server and
have it send an event when it thinks the Compositing Manager should
start painting; probably not ideal, but workable. Or even have the
Compositing Manager tell the X server how much lead time it needs. In
either case, the X server could suspend the other clients and send an
event to the Compositing Manager at that time, unblocking when the
Compositing Manager was finished.


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

Sure, it would be great to suspend applications only when they try to
manipulate resources on the target CRTC. We can do that in X, it's just
more work to go through the window system code and stick in checks to
suspend clients in relevant requests. Completely enforceable, in terms
of geometry and rendering requests.

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

From the users' perspective, there is no effect at all -- you can't see
anything that clients do until the Compositing Manager draws the
screen. And, the server should spend very little time in the grabbed
state; only long enough for the Compositing Manager to draw the
frame. A Direct Rendered application would probably see no impact at
all; if triple buffered, it will have all of the necessary resources to
continue drawing without waiting for the PresentPixmap to finish.

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

For this to work without changing existing applications, I think the
only thing we can do is stop executing requests from them.

-- 
-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/5901d1d0/attachment.sig>