Finishing Composite to handle transformed windows

[Keith Packard]

Deron Johnson and I have been having a private email exchange (which, I
belatedly realize now was a mistake) about how to complete the X server
changes necessary to support a truely transforming X environment. In his
case, the Looking Glass environment and in mine, a simple magnification
environment for accessibility. 

I've chosen the nominally simpler magnifier case as it represents all of
the X architectural difficulties without also including sophisticated
non-X rendering mechanisms.

Deron has a system which is working, but it hasn't solved all of the
problems and includes some dodgey changes to the X server which we'd
like to avoid in a finished implementation.

Ok, let's start with a relatively simple problem. LookingGlass wants to
create a window within which it can draw all of the screen content. That
includes Composite-redirected X windows and non-X 3D application
content. Even the sprite that follows the mouse is drawn here; the
hardware sprite isn't used as Looking Glass provides a true 3D cursor,
including a nice shadow that must be rendered each time so that it looks
correct over an arbitrary object.

The existing compositing managers simply draw the screen contents on the
root window in IncludeInferiors mode. This works nicely enough, but
doesn't easily extend to GL rendering as GLX cannot draw on the root
window, and GLX has no notion of IncludeInferiors even if it could.

LG's current solution is to change the Composite extension so that
windows which are Redirected have no effect on their sibling's clip
lists. This doesn't make sense for many uses of Composite, including
using it for backing storage as these siblings would then end up drawing
all over the redirect window location, wreaking havoc on the screen.

Deron and I discussed two alternatives. The first was to have a setting
for each window which changed the clip generating function so that the
window would not be clipped by siblings. As Composite already redirects
the clip computation code at this point, it's wouldn't be hard to
implement and would nicely solve the problem.

The second alternative is to adopt a page from Window's playbook and
create a new special class of windows -- the 'topmost' windows which
appear above all 'normal' windows and above which normal windows cannot
appear. It turns out that this particular option is already supported in
the DIX code - the screen saver window requires precisely these
semantics. A small bit of generalization and *poof*, we should have
windows which will be stuck above the remaining application windows.

Deron and I both like the appeal of topmost windows; there isn't any
semantic change in clipping, and the code which implements this option
already exists and is rather well tested. Semantics for operations like
QueryTree, ConfigureWindow, CirculateWindows and the like are well
defined.

The semantic of non-OverrideRedirect windows which are Topmost seems
vague to me; window managers are going to be horribly confused by them.
However, I'm not sure I'm willing to force them to be OverrideRedirect
or make it an error for them not to be; this question will need to be
answered before we can settle the final semantics. At present, the
screen saver windows are always OverrideRedirect.

Ok, now we've got a window which isn't clipped by the redirected
windows. Now, how do we avoid having it get redirected when the
compositing manager enables RedirectSubwindows on the root? Right now,
LG cannot use RedirectSubwindows and must carefully redirect each new
window as it discovers them. 

Our first plan to avoid redirecting the output window was to create a
special flag for each window which specified whether to ignore the
RedirectSubwindows flag. This seems straightforward enough. However, I
am now wondering if it makes sense to just make topmost windows not be
affected by the RedirectSubwindows flag. While I can't really think of a
reason not to make this linkage, it does seem artificial and may be a
bad idea in the future. I dunno.

With our non-redirected topmost windows, we can draw LG content without
interference from other X applications, and without a nasty compositing
recursion problem.

Deron and I have also been discussing input redirection; I'll save that
for a future message.

Deron -- please reply to our current issues here on the mailing list so
that others may listen and participate.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060104/83a421ca/attachment.pgp>