Finishing Composite to handle transformed windows

[Andy Ritger]

On Sat, 7 Jan 2006, Keith Packard wrote:

> >     - supposedly not all GLX implementations support rendering to
> >       the root window; I'd be curious what other GLX implementors
> >       think about it, but I would consider that a bug that should
> >       be fixed
> 
> My understanding is that GLX uses different visuals that look identical
> to X to indicate different 3D rendering capabilities. We can't change
> the root visual. Would this mean that we would have to select the
> 'right' root visual at X server startup for a particular compositing
> manager? This seems bad.

GLX extends X visuals, adding additional properties to each X visual.
You raise a good point: I can imagine a composite manager wanting
to select different visuals (for things like MultiSample).  I guess
that means that the server-side GLX implementation would need to
add the 'right' additional GLX properties to the root visual.  Ick.

> > I'm not real excited about a GLX extension to give a GLXContext a
> > subwindow_mode attribute, but it seems feasible.  I'd be curious
> > what other GLX implementors think about that.
> 
> We have to get the clip list of the GLX context set somehow; either we
> make it possible to have the child windows affect clipping, or we add an
> IncludeInferiors mode to GLX. The latter brings GLX into parity with the
> core and Render drawing systems which support this mode, and seems like
> it would be a whole lot easier than other nasty hacks to fix the root
> clip for everyone.

Yeah, I see your point.

> > It does sound heavy handed to require that the composite manager's
> > output window must be the root window.  However, it makes things
> > easier if that's enforced, and it makes sense in that the root
> > window is the only window that cannot itself be redirected.
> 
> Right, it doesn't require any widgey semantics or strange extensions for
> things to 'just work', and that's certainly appealing. The key question
> is whether GLX and/or X can be fixed to make this possible.
>    
> > It took me a few reads to actually understand the above.  Now I
> > see what you mean, and ewww.
> 
> Yeah, which is one reason I'd really like to just use IncludeInferiors
> if possible. Of course, drawing a single ManualRedirect window into the
> root will still be hard. The best way to handle that case would be to
> create a wrapper window and reparent the ManualRedirect window inside
> it. Painting to the wrapper in IncludeInferiors mode will get the right
> clip list, otherwise you have to compute the clip list by hand, which is
> icky. With this in mind, it's hard for me to see the value of
> ManualRedirect one a one-by-one basis at the top level of the window
> tree, which does kinda encourage the manual-redirect-don't-clip view.
> Hmm. 
> 
> > Fair enough; I don't have any examples where this would be desirable,
> > either.
> 
> Yeah, let's try to define one set of useful semantics rather than a
> bunch of kludgy options.

Agreed.

I'll give this some more thought and solicit ideas from some other
NVIDIA engineers and try to get back to you.

Thanks,
- Andy

> -keith
> 
>