On Thu, 9 Sep 1999, Brian Paul wrote:
> > > * Is this extension properly named?
> >
> > I'm semi-convinced this should actually sit in its own namespace,
> > and then initially we put it in GLX by analogy to the WGL equivalent.
>
> As I was implementing it I found that it would be cleaner if it
> were a GLX function. I had to add a device driver hook in Mesa
> so that core Mesa could query function pointers from device
> drivers (such as the X/Mesa driver inside Mesa's GLX interface).
>
> However, if we call it glXGetProcAddressEXT, consider the problem
> for GLUT-based programs. Clearly, a GLUT-based program shouldn't
> be making GLX calls. I guess the solution to that is for GLUT to
> offer a glutGetProcAddress() function which wraps either glXGetProc-
> AddressEXT or wglGetProcAddress. I think this would be the first
> GLUT function to return a pointer.
That's one of the reasons behind my suggestion to have multiple
gl*GetFuncAddress functions - one for each namespace:
glGetFuncAddress -- Gets gl, gl*EXT and gl*ARB only,
...which is good for programs that
use only GLUT.
glXGetFuncAddress -- Gets only glX* and glX*EXT functions.
glXGetFuncAddress -- Gets only glu* and glu*EXT functions.
wglGetFuncAddress -- Logically, this would only get wgl*
addresses - but the existing implementation
doesn't break the scheme above too badly.
...similarly for agl (Apple GL) and pgl (OS/2 GL).
> I was thinking that _any_ extension function should be queried in
> this manner. The Mesa libGL.so might export extensions not offered
> by Xi's or Metrolinks' OpenGL.
> It would be confusing to app developers if some extensions had to
> be queried by GetProcAddressEXT() but not others.
Yes - but at least developers could be confident that if they use
GetProcAddressEXT for ALL extensions, and all functions that are
not part of OpenGL 1.1, they will be safe forever.
> Any extension functions I add to Mesa will be accessible both by
> traditional means and by GetProcAddressEXT(). I think it's fair to
> require all OpenGL vendors to do this.
It should certainly be ALLOWED - I don't think it's necessary to
mandate it though. Think about an OpenGL with a standard front
end and dynamically loaded back ends (as Mesa may become with
DRI). The back ends may all offer different extensions - and
may even offer extensions that were not thought of when the
front end code was written. Making it a REQUIREMENT that all
extensions can be obtained by traditional means would make
this arrangement impossible to implement.
However, there is a (lesser IMHO) problem with failing to
make the extension functions accessible traditionally -
and that is programs that don't need binary portability can
no longer simply say:
#ifdef GL_EXT_whatever
glWhateverEXT ( ... )
#endif
...because glWhateverEXT should be accessible traditionally
if the corresponding GL_EXT_ token is defined.
However, I'd prefer to see a front-end/back-end Mesa than
supporting programs that don't port well.
> > Also, an emerging use of wglGetProcAddress() is to return pointers
> > to OpenGL 1.2 core functions. While this exact scenario is unlikely to
> > arise on Linux, we should still be very clear up front about whether
> > non-EXT functions can be queried.
>
> I vote that only true extension (non core) functions be returned.
> This includes the ARB multitexture functions in 1.2.1.
Why? You must have a good reason - I just don't understand
what it is.
It seems a strange viewpoint in the light of practical usage
of wglGetFuncAddress under Windoze and the likelyhood of some
future OpenGL 1.3 spec appearing while 1.2 libraries are still
commonplace on long-lived Linux distribution CD's.
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
