Making Composite better for interactive apps

[Giuseppe Bilotta]

On Tue, Feb 6, 2018 at 11:03 PM, Keith Packard <keithp at keithp.com> wrote:
>> 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.

[snip]

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

Still it would make more sense to have the CM tell the server “I'm
going to prepare the next frame, so stop the world” than having the
server tel the CM “I stopped the world to give you some time to
prepare the next frame”. Maybe it can be achieved with both? As in the
CM sending a PreparingNextFrameNotify to the server, the server
replying with an OKIStoppedTheWorldNotify, and then the CM can fetch
all pending updates and actually prepare the frame?

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

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

Looking forward to that.

-- 
Giuseppe "Oblomov" Bilotta