In your message of 11 November 1999 you write:
> Are you speaking of driver writers here? If so, what I've proposed won't
> affect them in any way. If you're not talking about driver writers, I
> don't understand your point. Aren't we trying to create a standard here
> so that there _won't_ be various flavors of libGL floating around?
No, we are trying to create a standard here so that it is possible to
have multiple flavors of libGL.so floating around. Multiple flavor means
either different versions, different implementations, whatever. The
goal from day one was not to define one specific implementation, but
to have a application side interface (API entry points,
file-locations, link-rules, etc.) that would allow consitency and
portability.
> > >From ausers prespective, I would guess that it's way more important to
> > make porting easier (yes, this also means from and to windows). Having
> > a glXGetProcAddress() that is essentially compatible with a
> > wglGetProcAddress() is a very important thing to have.
>
> I can understand this perspective, but I thought early on we decided that
> it was more important to do the job right, rather than be hobbled by a
> goofy Microsoft design.
>
> Besides, what I'm proposing isn't going to present any great hardship in
> porting anyway. If one wants to write Windows OpenGL code, one has to
> use wgl. And if one wants to write OpenGL code for X, one has to use glX.
> If you want to write code that compiles under both platforms, you've got
> to have some sort of porting layer that deals with all the other differences
> between the two interfaces (most of which are far more difficult to deal
> with than the simple change I'm proposing).
Well, after going throu all the points, I'm not so sure whether the
Microsoft interface is so goofy after all. If I was an application
writer I could live with the context-dependency. I'm already used to
the fact the extensions are essentially context dependent, so the step
would rather small. Technically it's feasable to do either. It's also
easy to have a string-lookup vs. a enum-based lookup.
The real question the we seem to forget is: "What about the guy doing
the application". Writing and debugging an application, I would have
really two priorities:
1. I would really love to have something like:
#define wglGetProcAddress glXGetProcAddress
All the arguments about porting layers are correct, but the
fewer lines of code I have to change, the better it is.
2. I would really like to have a error-mechanism, that would
punish me for doing stupid things. Returning a Noop for
a non-exsiting API entry point is a nice thing to have, but
a NULL-pointer that forces a core-dump is way nicer to debug
things and make them work.
Pickung up on the argument of "only one flavour" (which I have to
restate again, is not the original goal here), then there would be
better and faster mechanisms to deal with things. Actually why not the
define an explicite function dispatch table record for every
extension, and have something like a:
table = glXGetExtensionProcs(ctxt, "GL_ARB_multitexture");
Please, I'm not suggesting doing this. What I'm trying to say is that
there might be more efficient ways of doing things, but what really
counts is what the application developer needs. And what they
certainly don't need is two completely different interfaces that do
the same thing, and just make porting a bigger hazzle.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
