Finishing Composite to handle transformed windows

[Amir Bukhari]

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

That may solve the cliping issue, but what about event processing. Normal
window (bellow topmost window) will never receive input events.
For reason (as I think) we reparent all windows (also redirected like menus
...) to one Pseudo root window (PRW), this approach solve us event
propagation, but has clipping issue mention before, which Deron has solved
it, but in hacky way.
I recommend the first approach, which doen't need add new window class it
just need to extend the Xcomposite extension, also current WM use layer
stack and thus "topmost" windows can be create and manage by WM.
Also the second approach may make event proccessing complexer for those who
want to have a fullscreen window (Pseudo root window) and also want
manipulate normal X applications and display them on PRW as they like. LG
and enligtenment are a good example, (I don't know engligtenment alot but I
think they will use such in the near feature, with their rendering engine.


-Amir