Absolutely, Stephen, and very well put.
Further arguing towards the same conclusion I must reiterate that a
context-independent glGetProcAddress is simply semantically incorrect,
regardless of library or application implementation issues. Core GL
functions may only be called when a context is bound, and any data
returned is context-dependent. My limited brain will not distinguish
a function pointer from other context-dependent constant data, like
GL_MAX_something or the extension strings, so I can reach no other
conclusion.
Context-dependent glGetProcAddress is semantically correct, as is
context-independent glXGetProcAddress. Either is fine with me,
and if we go with context-independent glXGetProcAddress I will
support the implementation of a context-independent
aglGetProcAddress on the Mac for portability.
Bob Beretta
Apple Computer
Stephen J Baker wrote:
> On Thu, 21 Oct 1999, David Blythe wrote:
>
> > I'm interested in food, or arguing the point, although I much more in
> > favour of just moving on.
>
> Indeed.
>
> I was originally in favor of context-free pointers - but having
> listened to the (extensive) debate, I'm a convert to context-
> dependent pointers. here is why:
>
> * Since not all contexts will implement a given
> extension, the application (and any libraries
> it calls that make use of extensions) will have
> to have code that is context-dependent wherever
> an extension is called.
>
> * You can't find out whether a context will support
> an extension without creating and binding that
> context and doing a glGetString. It's just as
> easy to do the glGetProcAddress right then as
> it would be to do it earlier...and the application
> won't end up querying the addresses of loads of
> functions that don't exist.
>
> * That being the case, the application will likely
> need to build a table of per-extension flags for
> each context to say whether that context implements
> that extension. From the application's perspective,
> there might as well be the address of the function
> in that same table - so per-context function
> pointers don't make the applications' job any harder.
>
> * So, from an application's perspective it doesn't
> make a whole lot of difference whether the pointers
> are context specific or context dependent.
>
> * Which should we choose then? If the application
> doesn't care - then it should be whichever makes
> the driver writer's task easier - and since it
> looks like at least some of the driver writers
> are on the side of context-dependent pointers on
> grounds of simplicity - then that's what we should
> choose.
>
> * If for some reason it should turn out to be simpler
> NOT to make them context-dependent - then context-free
> pointers are not prohibited by the rules - they are
> simply not guaranteed.
>
> The only remaining problem I have with context-specific
> pointers is that newbies will (in error) attempt to
> glGetProcAddress with no current context open - and
> that will result in lots of hard-to-find errors. This
> could be alleviated greatly by having that routine
> be *required* to return NULL when no context is bound.
> That way lazy single-context implementations won't be
> able to simply hard-code the return addresses and
> cause incorrectly written applications to *appear*
> to work - only to fail when linked against multi-context
> OpenGL implementations.
>
> Finally, if pointers are to be context-specific then
> it is important (IMHO) that the name of the function
> to fetch them is glGetProcAddress and not glXGetProcAddress
> because gl functions are typically tied to a specific
> context and glX functions are (in general) not.
>
> I think we should end the debate and get on with life.
>
> glGetProcAddress - context-specific.
>
> 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
