"Jasper St. Pierre" <jstpie...@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
Description: PGP signature
_______________________________________________ email@example.com: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel