On Thu, 14 Oct 1999, Brett Johnson wrote:
> > You can't query the address of a gl* function unless a context
> > is already bound
>
> Given the context-independent definition, this isn't true (or at least
> it doesn't have to be true).
>
> > because the meaning of glGetProcAddress is
> > **NOT**
> >
> > "Does this function exist? (And what is its address?)"
> >
> > It is:
> >
> > "If this function happens to exist, what is its address?"
>
> Actually, I think the meaning is more like:
>
> "Return the address of a function which, when called, will produce
> identical results to calling the extension function directly."
But that's not a meaningful statement because "producing identical
results" to directly calling a function that doesn't exist
directly...is..erm...meaningless. You still have to prefix your
sentence with "If this function exists then..."
We agreed early on that GetProcAddress was allowed to return non-NULL
results even if the extension being queried did not exist. There
were several good reasons for that (and I'd have to look back through
the archives to find them all).
> Since the return value of GetProcAddress is context-independent, there
> is no reason to require a currently bound context to call it. That is
> precisely why I favor glXGetProcAddress over glGetProcAddress.
Well, I suppose the context doesn't have to be *currently* bound -
but it does have to have been bound once in order to call glGetString.
(or so I contend!)
> [...]
>
> > We agreed that it would be OK for glGetProcAddress to
> > return a non-NULL result for a non-existant (or non-functioning)
> > GL call. We should not bypass the existing glGetString
> > mechanism.
>
> I didn't suggest bypassing glGetString. But glGetString should not be
> used to determine if it's valid to call GetProcAddress. It's always
> valid to call GetProcAddress. glGetString need only be used to determine
> if it's valid to call the *result* of GetProcAddress.
Hmmm - I suppose so - which means I have to concede that it
doesn't *have* to be a gl function. I don't concede that this
means it *can't* be a gl function though.
My main reason to want glGetProcAddress as well as glXGetProcAddress
is actually a matter of aesthetics - because we *do* have to have
a gluGetProcAddress *and* a glXGetProcAddress - and for symmetry
there should simply be a glGetProcAddress just so we can say that
the domain of each of those functions is the area of the API for
which it is named.
Also, as a matter of code portability, it would be nice if
we could keep the core 'gl' API clean of reliance on glX,
wgl, pgl, agl, etc. If it's a gl routine, it's more likely
to be implemented in a portable manner in future systems.
Anyway - it's not a big deal - I'm going to stop arguing
and let *something* get done so we can start using this.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
