At 05:41 PM 9/17/99 -0400, you wrote:
>> I'm not comfortable with changing this semantic unless there is a
>> compelling reason. Applications which use multiple contexts are already
>> prepared to handle per-context state and I do not see any burden with
>> requiring the same for ext function pointers.
>
>Michael makes a good and valid point here as long as you believe application
>authors (and OGL implementors) understand the issues. My experience suggests
>otherwise :-( Why not avoid as much confusion as we are able to? Just imagine
>all the hours you'll save by not having to explain this over and over again,
>you
>could go on vacation :-) Gee, now thats a goal I could live with...
Hee hee! If that were true I'd be all over it.
The truth is that, in my experience, this has never been an issue for
Windows developers. The most common problem is when people call
wglGetProcAddress without a current context, but wouldn't that be an issue
for the glX version too? I guess that's why I don't see it as a big deal,
billions of application developers (heh) have already learned to live with
this requirement. Granted, multimon is not prevelant on Windows...
I've spent more time on this thread than I have spent helping all Windows
OpenGL developers understand wglGetProcAddress in the three years I've been
working on this platform. I believe we are trying to solve a non-problem.
By the way, I believe we have been focused on direct renderers only. How
does this all play in an indirect rendering context? We need both client
side and server side dispatch, not to mention protocol for unknown
extensions. How does this requirement affect the discussion of context
dependent vs independent functions? I think this necessarily dictates that
we talk about a glXGetProcAddress rather than glGetProcAddress. Apologies
if this has already been discussed, I don't remember it and can't find
mention of a proposal in the current spec.
