Brian Paul writes:
> While we're focused on Linux/OpenGL, we have the opportunity
> to spec out something useful on non-X implementations. By
> putting glGetProcAddressEXT in the GL core, it would allow
> GLUT-based programs (for example) to avoid platform-specific
> code.
But then there has to be a good reason for
glGetString
plus
wglGetExtensionsStringEXT/glXQueryExtension/glXQueryExtensionsString
> Unfortunately, we then have to recognize the existing situation
> on Windows with wglGetProcAddress since it seems unlikely that
> Microsoft will implement GL_EXT_get_proc_address.
If there is a good reason for glGetProcAddressEXT, it could
become glGetProcAddress in, say, 1.4.
> How do we make decisions on these things when there's no
> obvious, clear answer?
OpenGL has already introduced the notion that GL extensions
are queried with a gl function, and GLX extensions are
queried using a glx function. If the ARB is inclined to
apply the same reasoning to wglGetProcAddress/glxProcAddress,
then glProcAddress seems the right thing to do, in my
uneducated opinion. I mean, we consider this a valid
mechanism, and not just a patch.
I'd want to avoid is the ambiguity where GL extensions can be
queried through GLX and GL at the same time. But maybe that
just comes down to elegance clashing against the real world.
b.
