----- Original Message -----
From: Michael I. Gold <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 1999 10:55 AM
Subject: Re: [oglbase-discuss] Updated GL_EXT_get_proc_address spec
> >- GLUT could offer a neutral wrapper for wgl/glx/aglGetProcAddress
>
> ... which would have to be context-dependent because of wglGetProcAddress.
> For better or worse, MS has blazed the trail on this one, and
> cross-platform portability demands that we accomodate the least common
> denominator.
Not necessarily. Glut could implement the same context independence
approach as glxGetProcAddress, though at the cost of an wrapper layer.
>
>
> In case i'm confusing anyone with my stance, I feel we must have one of:
Nice summary of choices below. I'll reference them directly.
>
> a) context-dependent glGetProcAddress (can we handle remote GLX with
this?)
I can understand the attraction of thinking of an extension proc as context
specific state, but I'm uncomfortable removing the context neutrality of the
extentions relative to all of the other gl functions. Eventually these
queried extensions will show up in the header files and regular dispatch
tables (even if as noops). At that point the user will have built now
useless infrastructure into their code and either have to remove it or keep
it as bloat. Also, I am unsure of how to handle some of the difficulties
that arise from it. What happens when one moves a window from a display
that supports an extension to one that doesn't? (actually I have no idea how
one does this in Win at all even without extensions) Does the app have to
scrap all their pointers and start again? What about utility libraries that
have stored the pointers in their initialization (for a given context)? What
happens when you make a proc call in the wrong context? Do we validate the
context? If so we've just paid the wrapper overhead of the context
independent GetProc without gaining any of the benefit. If we don't
validate the context are we likely to do "something bad" (tm) to the driver
(e.g. when it looks at the incorrect current context and finds some
assertion violated or worse tries to access extension specific state out of
the now wrong size structure*)?
Maybe I'm paranoid but this seems like a big stack of questions. Now,
there's nothing in the implementation of (b) that prevents eventually
implementing (a) at a later time when (1) we give up on certain large
software companies ever implementing context independent getProc or (2) are
all as confident as Michael that (a) is neither a pain in the butt for the
application developers nor dangerous in terms of driver stability.
* the device independant ogl context structure is probably the same size but
what about the device dependent part (right where extension state would be)?
Big Ouch!
>
> 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? It's context independent.
This means that it shouldn't depend on the exsistance of any given EXT in
any given context. As it's unlikely in the world of multihead (which is why
context dependencies arose) that we can require the application to create
all possible contexts a priori (and that's when the app is going to want to
GetProc, at initialization) Thus, the wrapper return is the only choice. On
the positive, this also would allow the context to dynamically change the
behavior of a proc for a given context (e.g. when it gets dragged to another
window).
>
> c) context-dependent glXGetProcAddress
I don't see the attraction of this vs. (a). Were one to implement (a)
compatibly with the wgl call, then one could move the whole shebang into the
gl spec eliminating the source code distinction. Same concerns as with (a).
>
> but not:
>
> d) context-independent glGetProcAddress
I can see the point here, especially as the current likelihood of ARB
adoption pretty low since given the current probabilities of "broader
adoption" as both Apple and MS have other current solutions. Now if
wglGetProc and glxGetProc ever get the same semantics... that's a different
matter.
John M. Zulauf
Santa Barbara, CA
