GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Patrick McFarland]

On Monday 13 March 2006 21:33, Ian Romanick wrote:
> Kristian Høgsberg wrote:
> > Ian Romanick wrote:
> >>> The motivation for the GLX_EXT_include_inferiors extension is that when
> >>> rendering to the root window, even if the child windows (i.e. the
> >>> top-level windows) have been redirected, they still clip output to the
> >>> root window.  For a compositing manager to be able to use the root
> >>> window to draw the desktop, we need a way to specify the equivalent of
> >>> IncludeInferiors for GL rendering.  GLX_EXT_include_inferiors provides
> >>> this mechanism.
> >>
> >> Let me propose an alternate idea.  What you really want is to force the
> >> pixel ownership test to always pass, right?  This would be analogous to
> >> disabling depth testing or alpha testing.  It sounds like we want a
> >> function like glXPixelOwnershipFunc that can take parameters like
> >> ALWAYS, NEVER, ALL_WINDOWS, NON_CHILDREN.  If that's what we want, then
> >> let's implement *that*. :)
> >>
> >> The beauty is that this would be really easy to implement for DRI
> >> drivers.
> >
> > Indeed, the implementation is trivial, viz this patch I posted as one of
> > the hacks to get compiz working on aiglx:
> >
> > http://freedesktop.org/~krh/compiz-on-aiglx/aiglx-gl-include-inferiors.pa
> >tch
> >
> > The issue is how to control this.  A GlxWindow GLX_INCLUDE_INFERIORS_EXT
> > attribute is a simple and non-intrusive way to set this, and if you're
> > familiar with the X GC property, you'll immediately know what it does. I
> > guess it as question of wether you're coming from the Xlib side of
> > things or the GL side of things :)
>
> Fair enough.  Although, I'm not convinced that making this a static
> property of an X GC was the right design decision in the first place.
> This really feels like a piece of drawing state that an app should be
> able to enable / disable at will.
>
> >> In fact, we could even add a query so that an app can determine whether
> >> or not a pixel ownership test happens (e.g., whether or not a drawable
> >> shares memory with other drawables).
> >>
> >> So, here's my other question.  In this configuration, what happens if
> >> you draw over top of some child window, and the application owning that
> >> window calls glReadPixels.  Does it get garbage?
> >
> > I would think it gets whatever is in the framebuffer for that window. Is
> > this a trick question? :)
>
> It wasn't a trick question, but I think that was a trick answer.  I'm
> just looking for clarification.
>
> I'm a little uncomfortable with rendering in context being able to
> modify the data in a drawable bound to another context, whether they're
> in the same process or not.  That's counter intuitive, there's no way to
> detect it, and is likely to cause problems for at least some apps in
> unexpected ways.
>
> If all the windows are redirected, this won't be an issue, right?  The
> window's buffers live "off-screen", over-writing the data in the
> composited buffer won't impact the results of glReadPixels in the child
> window.  However, if all the windows are redirected, I guess I don't
> understand why you even need this.  Isn't the composite operation just
> drawing a bunch of textures that happen to be other windows into the
> screen's "window"?

Why can't we give every window a FBO, and then composite that way? Or am I 
missing something?

-- 
Patrick "Diablo-D3" McFarland || diablod3 at gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989