On Thu, 4 Nov 1999, Brett Johnson wrote:
> Jon Leech wrote:
> >
> > I've revised the extension specification (attached) following our
> > straw poll to make it a GLX function returning context-independent
> > pointers. As a logical consequence the function should return any of GL,
> > GLX, or GLU functions.
> >
> > Hopefully, the nitpicky details of moving it from GL to GLX have
> > been taken care of. If there are any actual bugs in the proposal, please
> > identify them ASAP. This extension *will* be presented to the ARB on
> > Monday, November 8th.
>
> Other than the following comments, I think the spec looks great.
>
> 1) It doesn't make sense for glXGetProcAddress to return GLU entrypoints.
> glX doesn't even know or care that GLU exists, so it certainly shouldn't
> be returning pointers into GLU. If there's an actual need to get
> pointers to GLU extensions, we should define a gluGetProcAddress. I
> propose that we don't.
I propose that we *do* have a gluGetProcAddress just so we can get it
out of the way - it's no big deal to add to GLU - and it'll be a pain
to have to go through all this again if we ever do need one.
> 2) I don't see any reason why 1.0 core functions shouldn't be queryable
> (next to the last issue).
Me either. People will eventually forget that there ever was an OpenGL 1.0
and it'll seem really strange that *some* core functions of OpenGL 123.456
are queryable and yet others are not.
> 3) A NULL return value should not indicate anything except that something
> is wrong (and glError should be checked in that case to find out what
> went wrong). NULL certainly shouldn't give any indication as to whether
> the queried extension exists or is valid.
Agreed.
> 4) I don't think it's necessary to specify that "glXGetProcAddress(foo) ==
> &foo". In fact, I think it's an implementation detail that may not be
> true in all implementations, so it's much better not to constrain the
> implementation by mentioning it.
It's worth it so we can write the (required) test for it in the conformance
suite. Failing that we'd have to get the addresses of a set of functions
and then call them and somehow verify that they really are the correct
functions based only on what the effect of calling them is.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
