FBConfigs and visuals (was Re: compiz on aiglx)

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Høgsberg wrote:
> James Jones wrote:
>> On Thursday 09 March 2006 05:13 pm, Kristian Høgsberg wrote:
>>
>>>> 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.

There are rules about what sorts of drawables can be bound to what sorts
of contexts.  I'll refer you to either the SGIX_fbconfig spec or the GLX
1.3 spec.  The key thing is that they have to be "compatible", but since
the drawable has the bits, it wins.  Here are a couple examples:

* A context created from a 32-bit RGBA fbconfig can have a drawable that
was created with an otherwise identical 32-bit RGB fbconfig.  The
rendering that happens will be RGB, not RGBA.

* A context created with a double-buffered fbconfig can have a drawable
that was created with an otherwise identical single-buffered fbconfig.
Only GL_FRONT (or GL_FRONT_LEFT) will be valid parameters to glDrawBuffer.

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

(I'm pulling this from the SGIX_fbconfig and SGI_make_current_read specs
because it's easier to cut-and-paste from there.)

- From the spec, "Note that a GLXFBConfigSGIX has an associated X Visual
iff the GLX_DRAWABLE_TYPE_SGIX value has the GLX_WINDOW_BIT_SGIX bit
set."  From that I infer that if the GLX_DRAWABLE_TYPE has
GLX_PIXMAP_BIT or GLX_PBUFFER_BIT set but not GLX_WINDOW_BIT, there
cannot be a visual associted with the fbconfig.

In addition, looking at the sections on how "compatible" is defined, I
see no mention of the visual ID taking part in the comparison.  It only
mentions the buffers available.

Hmm...there doesn't seem to be a lot of guidance in the specs about the
visual.

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

That is completely true.   The purpose of the visual is so that after
calling glXChooseFBConfig you can call glXGetVisualFromFBConfig and pass
the result to XCreateWindow.  I believe that the rules allow the visual
listed in the fbconfig to just be compatible.I don't think it needs to
be an exact match.  None of the specs seem to say for sure either way.

I can bring this up at the ARB meeting week.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEEf7zX1gOwKyEAw8RArhrAJ9T3A/YWU+Ns9Ox9CNz0GGVN8ZJ9wCglz97
7nRkxdwQKzSGQkl9V649/tQ=
=WBdV
-----END PGP SIGNATURE-----