Thomas Roell wrote:
>
> In your message of 11 November 1999 you write:
>
> > I don't think that wgl/glX compatibility is an objective here. And I'm only
> > suggesting this modification if we step off the cliff of defining a static
> > order to the dispatch table. If we don't try to statically define the dispatch
> > table offsets, then it's not worth monkeying with changing the interface.
>
> Well,
>
> what about the point that there are different vendors out there
> supplying a libGL, that for some reason uses a totally different
> dispatch mechanism ?
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?
> >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).
Again, let me reiterate that I'm only proposing this change _IF_ we make
the table offsets static. Otherwise, I'm happy with it as-is.
Also let me reiterate the benefits:
- Much faster, simpler, and more efficient implementation (no more string searches).
- Much more robust interface from the app's point of view. I.e. with the
current interface, it's pretty easy to get a pointer to an extension
entrypoint that doesn't exist (simply by misspelling the extension name),
and there's no good way to determine that the pointer is bogus. With
the change I'm proposing, this scenario is _much_ less likely, as the
compiler will quickly catch a simple misspelling.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
