Making Composite better for interactive apps

[Keith Packard]

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

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

As I said, I think the two problems are separable, so I don't think we
need to associate the grab/ungrab notion with the Auto List
management. Simply removing the window from the auto list when its
geometry changes and notifying the Compositing Manager means that in the
next frame constructed by the compositing manager, it will either paint
the window itself or it will have adapted to the geometry change.

This may still leave window contents out of sync with the results of
Compositing temporarily, but as long as things eventually correct
themselves, that's the same as the current Compositing Manager
environment.

-- 
-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/9d266f2f/attachment.sig>