compiz on aiglx

[James Jones]

On Thursday 09 March 2006 05:13 pm, Kristian Høgsberg wrote:

<snip>

> > A major benefit of the overlay window is the ability to create
> > the window being drawn into with whatever FBConfig you like,
> > rather than relying on the root window's visual to contain all
> > required functionality.  This may seem like a minor point, but
> > it could be a major if you preferred to render the desktop
> > using a stereo visual, or if the default visual did not provide
> > stencil bits, etc.  As you say, I think there is room for both
> > approaches, I just would hate to see the quick availability of
> > an FBConfig extension kill off all interest in the composite
> > overlay window.
>
> So I guess this is one point where I'm not sure how
> glXCreateNewContext should work.  My impression was that you can
> pass in any FBConfig you want when you create the context and
> when you later call glXMakeCurrent that FBConfig will override
> whatever GL attributes are associated with the root window
> visual.  In other words, the FBconfig attributes are independent
> of and override the attributes of the default visual.  So even if
> your root window visual doesn't have doublebuffering, you can
> override that by using an FBconfig that does.

FBConfigs and visuals are more intertwined than this.  FBConfigs 
have an associated visual if they support rendering to drawable 
types that have associated visuals.  The FBConfig's visual and the 
drawable's visual should match.  There can be many FBConfigs that 
are associated with the same visual, but only one visual per 
FBConfig.  From this, I believe that any FBConfig properties that 
have corresponding visual properties need to match as well.

Basically, these are two application visible datastructures that 
wrap the same piece of GLX internal state, so they need to match.

As far as CreateNewContext/MakeCurrent, this may be ill defined.  
The interaction between a context's FBConfig and a Drawable's 
FBConfig is defined in terms of CreateNewContext and 
glXCreateWindow/glXCreatePixmap/etc.  In this case, there are 
compatibility rules that must be satisfied.  I would think these 
same rules should apply to the visual of a GLX drawable implicitly 
created by MakeCurrent and the FBConfig of a context created using 
CreateNewContext.  For example, it wouldn't make sense to mix a 
drawable with an FBConfig specifying a 16 bit color buffer with a 
window that has a 24 bit color buffer.

> [...]
>
> > I think it is the most desireable behavior, but I disagree that
> > it is the most reasonable.  All sides of the equation (the
> > oblivious applications, the X server, the X and OpenGL drivers,
> > the composite manager, and ideally a bullet-proof
> > specification) must be taken into account when creating a
> > reasonable solution.
>
> I guess, after all, I'm happy with the undefined behaviour.  I
> can see how it will be difficult to word a usable description of
> what will happen in the receiving-rendering-while-bound
> situation.  Leaving it undefined leaves enough room for the tfp
> implementation to avoid blocking or copy-on-write, and the
> compositing manager can block updates to the pixmap either by
> grabbing the server or by using a higher level protocol, such as
> the pixmap-ownership idea I sketched above.

I agree there is room for improvement here in the form of some 
better external synchronization method.  I just feel the problem 
becomes too difficult when we try to tie it directly it into this 
specification.  This specification should provide a reasonable 
framework that all vendors can implement, and that can be built 
upon to provide a total robust solution.

I have spent some time thinking about ways to implement such 
synchronization, but I haven't come up with anything useable yet.  
Glad to see others are thinking about these issues as well ;-)

Thanks,
-James Jones

> thanks,
> Kristian