Finishing Composite to handle transformed windows

[Deron Johnson]

The reason why I decided to use a different window for LG 3D rendering
instead of the root window is because my scene graph library (Java3D)
doesn't allow you to render to existing windows, and also I have
encountered some versions of OpenGL direct rendering in the past
which don't work on the root window (Sun's implementation of
OpenGL did this, for example). It's just cleaner and safer to use
a separate window.

Andy Ritger wrote On 01/06/06 11:28,:
> Thanks for the writeup, Keith.
> 
> I've not processed at all of this, yet, but I would like to clarify
> one point:
> 
> 
>>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.
> 
> 
> GLX can indeed render to the root window.  glXMakeCurrent() can
> be used to make current to any X window, assuming you can create
> a compatible GLXContext.  I believe xscreensaver, for example,
> does this.
> 
> Thanks,
> - Andy
> 
> 
> On Wed, 4 Jan 2006, 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.
>>
>>-keith
>>
>>
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg