FBConfigs and visuals (was Re: compiz on aiglx)

[Kristian Høgsberg]

James Jones wrote:
> 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.

If I understand what you're saying correctly, doesn't that imply that we 
still need to have a visual for each combination of all the GL visual 
properties?  I thought one of the benefits of FBConfigs was that we 
could cut down on this combinatorial explosion and only expose a couple 
of 'typical' visuals for backwards compatibility (e.g. one with no aux 
buffers, one with back buffer, and one with all aux buffers).  If 
visuals and FBConfigs have to match up in the way that you describe, 
there is no way we can use an FBConfig that doesn't agree with some 
visual on the overlapping attributes.

(I'm adding Ian to the cc list, I believe he mentioned the idea of 
reducing the number of visuals)

Kristian