In your message of 10 September 1999 you write:
> > 2. Having a bound context, while retrieving the function pointers is
> > kind of difficult to handle for applications. There are
> > applications which create first all the contexts they need, before
> > actually making them current. Hence it would be easier to really
> > pass a GLXContext explicitely.
> >
> > The downside would be that then GetProcAddress really had to be
> > called glXGetProcAddress. The upside is, that glProcAddress could
> > be implemented trivially by:
> >
> > glXGetProcAddressEXT(glXGetCurrentContext(), name)
> >
> > Hence I would suggest to have 2 functions defined right away in
> > this extension:
> >
> >
> > glGetProcAddressEXT(name)
> > glXGetProcAddressEXT(ctxt, name)
> >
> > The first one would return only GL API functions along with
> > extension functions, while the glX variant would also return all
> > glX functions.
>
> OK - but you still have to call the gl version from the context in
> which you'll call the function that it returns. (That would certainly
> HAVE to be the case for EXT functions - so we might as well make
> it the rule for all functions - if only to simplify the manual!)
It's still an ugly problem. For an application programmers point of
view, I really don't like the idea of GetProcAddress() be dependant
upon the context it's called under. It's just a nightmare and a
predictable recipe for disaster. On the other hand, letting libGL do
the indirection for unknown extensions is very tricky.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
