| 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.
|
| 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.
|
| Hmmm, maybe just having glXGetProcAddressEXT (and gluGetProc-
| AddressEXT) isn't so bad.
|
| How do we make decisions on these things when there's no
| obvious, clear answer?
|
| -Brian
I think it violates the spirit of the OpenGL specification
to allow a function with a name like glGetProcAddress to
return anything about the window system layer or glu. If
you want to do a platform independent glGetProcAddress, that
is okay, but there should still be separate glu/glX query
functions. I don't see why Microsoft wouldn't add it to
windows if it was useful developer functionality.
Frankly, I don't see that big a win in trying to make it
platform independent. There will still be lots of ifdefs to
cover other Win32 (or VC++) specific differences (math library,
rand functions, etc, etc) so it really doesn't save much
(argument for rolling it into glXGetProcAddressEXT).
If you go the route of glXGetProcAddress, it think it
is much more tenuous to make the return values context
specific. It seems awfully inconvenient, developers won't
use it correctly, and the performance gain seems pretty arguable.
Its really not clear that there is a pressing need to have
context-specific extensions, so I don't think that it is
compelling argument.
My feeling is that it would be better to resolve any context
specific behavior inside the implementation (with the expectation
that most of the time there will be no specialized context
specific behavior). Also, if you have glXGetProcAddress.
there should still be a separate gluGetProcAddressEXT since
there is no formal relationship between glX and glu and
we shouldn't gratuitously create one.
-db
