GLX_EXT_texture_from_pixmap spec just about done.

[James Jones]

On 5/1/06 3:19 PM, "Adam Jackson" <ajax at nwnk.net> wrote:

> On Saturday 29 April 2006 20:55, James Jones wrote:
>> Hello again,
>> 
>> After incorporating all the feedback from this list, we've come up
>> with what should be a finished specification.  Changes include:
>> 
>> -A few of the issues were cleaned up a bit.
>> 
>> -Official GLX enums and opcodes have been allocated.
> 
> Sweet.  I'll go ahead and bump the protocol module.
> 
>> -The function return values have been changed to void.
> 
> Reflected in Mesa.

Cool.

>> -Unfortunately, we need to require GLX 1.3 rather than GLX 1.2 +
>> SGIX_fbconfig.  the CreateGlxPixmap function in SGIX_fbconfig
>> doesn't take attributes, which are important for the creation of
>> TFP drawables.  Implementations that don't support GLX 1.3 will
>> either have to be updated, or at least fudge it by implementing
>> glXCreatePixmap.
> 
> Not a huge deal, I think this works in the Xorg GLX code.
> 
> Could the spec reflect this?  Something along the lines of:
> 
> "GLX 1.3 is required.  Alternatively, implementations may advertise support
> for this extension simultaneously with GLX 1.2 if and only if they support
> the glXCreatePixmap interface from GLX 1.3."
> 
> Sort of awkward language, but it works.

I had really hoped we wouldn't need to require GLX 1.3, but I don't think
it's worth weakening the spec language to allow pre-1.3 implementations to
be 100% compliant.  Few end users read these specifications, and application
developers can just check for the EXT_tfp extension string to determine if
the extension is supported.  This should imply support for at least
glXCreatePixmap and the SGIX_fbconfig extension.  While this leaves the
implementer in not-100%-compliance limbo, I again just don't think it's
worth weakening the spec to solve what is hopefully a short-term issue.
With any luck, this requirement will spur on GLX 1.3 development just as
texturing from pixmaps sparked interest in accelerated indirect GLX ;-)

>> Could all interested parties give it one final review?  In
>> particular, could someone from AIGLX let us know if everything
>> looks good from the point of view of another implementor?
> 
> I don't see anything immediately wrong with it; I'll give it a closer review
> tonight.

Excellent.  Let me know if you run into anything.

Thanks,
-James Jones

> - ajax


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------