Making Composite better for interactive apps

[Keith Packard]

"Jasper St. Pierre" <jstpierre at mecheye.net> writes:

> How is this different from unredirection? mutter / gnome-shell currently
> doesn't unredirect windowed windows, but there's no reason it couldn't --
> it just needs to be able to handle the case where it's unredirecting the
> client window rather than the parent frame window.

Thanks for the question; it's a good one, as this is something we've
tried to enable over the past few years at least for full-screen
applications.

Let's look at what it would mean to un-redirect a single non-full-screen
application window.

Redirection works by creating a pixmap containing the contents of an
entire window sub-tree, generally starting at the window manager frame,
which includes the decorations and the client window. You can't
unredirect the client window separately from the window manager frame in
this design. What I proposed effectively 'un-redirects' a window from
any place under the Compositor window.

You could have the client window a direct child of the root window and
manage it separately, however the current Composite extension doesn't
allow you to individually un-redirect some windows while maintaining a
global redirect for the remaining windows. And you need that in case a
new window appears to ensure that the Compositing Manager can capture
that new window and draw it correctly.

We could change the Composite extension to allow this by adding a new
redirection mode or request that would override the global setting for a
specific window, or to clip out a window from the redirection of an
ancestor. However we would run into the synchronization issues that the
proposed per-PresentPixmap 'Auto List' is designed to solve. That is the
desire for the Compositing Manager to continue to precisely control the
contents of each frame on the screen.

By having the Auto List specify the set of windows to be un-redirected
for the next PresentPixmap operation, the server can now construct a
correct frame at each step of the process.

So, yes, you're correct that this is effectively un-redirection for the
client window from inside the redirected window hierarchy and
synchronized to the frame update done by the compositor. It just can't
be done with the current protocol.

Hrm. This makes me wonder what to do if the auto-listed window is a
direct child of the root and its geometry changes. In that case, the
Compositing Manager wouldn't have enough control over the display as the
window might well fall under some other decorations painted by the
Compositing Manager. I can think of two options:

 1) Block the geometry change and send an event to the compositing
    manager to deal with it.

 2) Only add non override-redirect windows to the Auto List, and then
    assert that the Compositing Manager and Window Manager are the same
    X client so that it would naturally receive geometry change requests
    by the client.

2) seems sufficient to me; it covers the cases we care about most with
no complicated klugery in the X server for now.

-- 
-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/20180202/f92de03b/attachment-0001.sig>