Stephen J Baker wrote:
>
> 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..."
I don't think it's meaningless. Calling an extension function that isn't
supported in the current context should be a noop (maybe it should set an
error as well, I haven't really thought of any reasons pro or con). The
same should apply for the result of GetProcAddress. Calling the result of
GetProcAddress should produce the same behavior (i.e. noop <or error> if
the extension isn't supported by the current context).
> 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!)
No doubt. In fact, the context must be currently bound in order to get
any meaningful information from glGetString. That's because the return
value of glGetString is context dependent (Actually, it's *driver*
dependent, which is not necessarily the same thing as context dependent
in a multi-headed environment).
> > [...]
> >
> > > 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.
Once again, Michael & I are in complete agreement (this is getting to be
*really* spooky man!).
Michael wrote:
> ...I feel we must have one of:
>
> a) context-dependent glGetProcAddress (can we handle remote GLX with this?)
>
> b) context-independent glXGetProcAddress
>
> c) context-dependent glXGetProcAddress
>
> but not:
>
> d) context-independent glGetProcAddress
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
