Michael Gold wrote:
> I think our disagreement stems from the fact that we are coming from
> different places - you are an old-time Linux/OpenGL developer with a code
> base to protect, whereas I am looking at this as a new beginning and am
> trying to make what I consider the best decision for the future. The good
> news/bad news is that OpenGL is not in widespread use on Linux at this time,
> at least not compared with what we hope/expect it to be. As such, the early
> pioneers may have to endure a minor transition so that it will be a better
> world for our children. ;-)
With all due respect, I think OpenGL (Mesa) is bigger on Linux than you'd
expect.
By my estimate, I've received email from 2000-3000 Linux/Mesa users over
the years. I bet that's a small fraction of the entire user base.
Mesa's been included with several Linux distros for some years. I know
of several large installation bases of Linux/Mesa in universities and
research labs. Basically every 3D app/game/utility on Linux uses Mesa.
If we don't have some reasonable amount of backward compatibility with
that installed base you can bet I'll be the one to hear about it.
There's three things I'd like to point out which have some bearing
on this discussion about gl.h vs glext.h. In particular, the gl.h
and glext.h files in Mesa 3.3 and XFree86 4.0:
1) glext.h still has the normal extern function declarations that have
been in gl.h. For example:
extern void glPointParameterfvEXT(GLenum, const GLfloat *);
glext.h also has the Microsoft-style function pointers.
2) In gl.h I left in most of the extension declarations that have
always been there. i.e. I didn't move ALL the extensions to glext.h
(yes, there are duplications).
3) libGL.so still contains many extension entrypoints. You won't get
a link/load-time error if you directly call glPointParameterfvEXT
in your code because that function exists in libGL.so.
All future Linux/OpenGL/Mesa development should use glXGetProcAddressARB.
But in the mean time, these three items will help ensure backward
compatibility with the existing applications, both at compile and runtime.
Not doing this would result in a support nightmare of which the very
thought sends a shiver down my spine.
-Brian
