Finishing Composite to handle transformed windows

Keith Packard keithp at keithp.com
Sat Jan 7 10:47:00 PST 2006


On Sat, 2006-01-07 at 02:35 -0800, Andy Ritger wrote:
> 

> Ah, thanks; I forgot about override redirect windows.

yeah, we don't yet have an override for Composite redirect, so it's hard
to remember that override redirect for geometry can have an effect
here...

>     - Java3D doesn't allow you to render to preexisting windows;
>       I'm sure this is solvable

If we can allow Java3D to use a new window, it would clearly be easier
on them, but we don't want to torque our design to satisfy this
arbitrary restriction.

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

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

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

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060107/8d05384a/attachment.pgp>


More information about the xorg mailing list