Finishing Composite to handle transformed windows

[Carsten Haitzler (The Rasterman)]

On Wed, 04 Jan 2006 21:08:57 -0800 Keith Packard <keithp at keithp.com> babbled:

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

good to drag it onto here. in enlightenment land we are looking (long term) to
do similar things to LG - but all in 2d with a canvas abstraction hiding it
all. we don't want "toplevel" app windows to exist visually or structurally (in
terms of modifying input events). we want to do what LG does - simply get
pixmap surfaces hooked to window id's - we will redirect them to our own
internal rendering system and as events come in for redraws we will merge, punt
to the canvas system and let it handle life from there (which are an amazingly
small number of hooks away as the raw canavs works fine). we want the entire
windows to be draws - ignoring any normal clipping, as you mentioned, as if
they were the only thing in existance and were never clipped by the root window
(screen)'s clip (so if they are partly off screen we still have their entire
pixel contents). the current tricky problems are really:

1. input event transforms/translations (ie all input events go via the WM and
then get somehow translated to account for 2d scaling - much like your usage
keith). 2. mouse cursors - the big pain. what will we do with mouse cursors for
sub-windows if the windows now are basically not visible and only the
compositing system's output window is visible and it may have twisted, bent,
curved, scaled and translated windows anywhere. do we really want to walk
window trees and watch all levels of the trees for sub windows looking for ones
with special cursors and watching when they change? or should there be a way to
feed a new mouse co-ord to a window and we then may get a mouse cursor change
event if the cursor moves toa  new-coord within that window in pre-transform
co-ord space?

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)