----- Original Message -----
From: Stephen J Baker <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 15, 1999 5:52 AM
Subject: Re: [oglbase-discuss] Updated GL_EXT_get_proc_address spec
> > > b) context-independent glXGetProcAddress
> >
> > Given that (d) is politically no viable right now this makes the most
sense.
> > What's odd is that noone has talked about a basic implication of this
> > choice. Effectively getProc must **always** return a non-null wrapper
(i.e.
> > the dispatch table function)... because we do not know if some FUTURE
> > context we create will support the ext. Right?
>
> No - surely
Don't call me Shirley. ;-)
> the driver will know what set of extension symbols
> exists within it. It's not like the user can plug in a new graphics
> card on-the-fly in the middle of a program run.
what about remote displays? We certainly DON'T want to query the network
for the totallity of possible contexts. How about meta-devices (printer
drivers, software renderers and the like), again it doesn't seem like we
want to search the possibility space before returning a pointer. This isn't
to argue FOR context dependent pointer, just to point out that independent
must mean exactly that. A context independant pointer returned from a get
proc must behave exactly as if one were invoking an extension function call
defined in the .lib or .so at link time.
>
> If you ask for glBlarfEXT and neither of the drivers that are currently
> running are for a card with a functional Blarfatron, then you can expect
> a NULL.
That's not what the function is for. Whether or not an extension is extant
is context specific and determined by glGetString. My understanding is that
the entire motivation for the getProc is to provide "forward-compatibility"
for drivers implementing features or extension not yet defined by a given
release of OpenGL32.dll or libgl.so for example. As soon a we begin to
overload this meaning with the "is this supported" questions then we have
pointers which are context-dependent* (at least to some extent). Once we do
that, we might as well have context-dependant pointers.
* "Once you have begun down the dark path, forever will it dominate your
destiny" -- Yoda
> I'm presuming that the libGL knows what the full set of possible
> drivers are up-front without the need to actually open rendering
> contexts and such...maybe that's not the case?
I think I've argued that it isn't.
