Making Composite better for interactive apps

[Keith Packard]

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

> Wouldn't this break Compton? AFAIK it only operates as compositor,
> which is why it's a popular choice among users of tiling WMs such as
> i3 and awesome.

(To be clear, what I'm proposing won't break anything that already
works -- the Auto List is entirely driven by the compositor, so if you
don't use it, you don't get this functionality.)

But, yes, Compton wouldn't be able to use this if we relied on tying the
window manager and compositor together.

I thought of another option, which really makes sense in this context I
think. We can include the window geometry with each entry in the Auto
List -- the Compositing Manager would specify the geometry that it wants the
window to occupy, and the X server would paint the window at that
location, not in its current position. That would ensure that the
display always reflected the Compositing Manager layout, and wouldn't be
affected by asynchronous window geometry changes.

Of course, if the window has been resized, then the contents may not fit
the space accurately, but that's no different than window resizing
today.

So, to recap, I see three options

  1) If the geometry change comes from a client other than the
     Compositing Manager, block that geometry change and send an event
     to the Compositing Manager to deal with it.

  2) If the Window Manager and Compositing Manager are the same client,
     have the Compositing Manager only add non override-redirect windows
     to the Auto List, as it will naturally receive geometry change
     requests by the client. If the Compositing Manager is separate,
     then using the Auto List might result in mis-rendered frames.

  3) Have the Compositing Manager specify the geometry with the root for
     each element in the Auto List. Presentation of the auto list member
     would use the specified geometry and not the actual window
     geometry.

Mode 3) leaves input running asynchronously with output, which is a bit
disconcerting, but I think we're only talking about a single frame of
lag assuming that the compositing manager is keeping up with the frame
rate. Mode 1) actually looks more plausible in this light; in either of
these two cases, you'd have some lag when reconfiguring windows.

-- 
-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/20180203/c47f8b11/attachment.sig>