Finishing Composite to handle transformed windows

[Russell Shaw]

Keith Packard wrote:
> 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.

What is the point of a 3D gui?

Who would use menus that are tilted from the screen normal-axis?

None of this 3D stuff will fit into small embedded hardware.

http://www.freedesktop.org/~pma/doc/J1-TS1586-final.pdf

If you want to make a magnifier window, why not just have an X server extension
such that the contents of a specified mouse-cursor window are automatically
rendered with the magnified contents of a smaller area in the center of the
window and happens whenever the mouse is moved.

The magnifier just reads the pixels currently in the video memory, so no
extra X round-trips are added.