On Fri, 22 Oct 1999 [EMAIL PROTECTED] wrote:
>
> Oh, no! Steve's gone over to the dark side!
I think this is beyond debate now - we are voting.
However, if you want some justification for my (b) vote:
Let me make it clear thought that I don't *WANT* context-dependent
extension function pointers. But I do believe that anyone can easily
*TOLERATE* them in any real application that is complex enough to need
multiple contexts.
That being the case, I see no reason to shackle OGL implementors
to a higher standard than is necessary. So, regardless of the
GL-side technicalities, it makes sense not to require more
constraints in the OpenGL driver than the application can make
use of. Hence, I voted (b).
> Look, let me try one last variant on the ``design principle''
> argument, then I'll shut up.
>
> You folks who want context-dependent extension function pointers, do
> you also want the addresses of *core* routines to be
> context-dependent?
I can tolerate it. No simple application is going to use pointers
for the core OpenGL 1.1 functionality - so the behavior of glGetProcAddress
for those functions is largely irrelevent to 'real' applications.
If the application does want a context independent address for
a core function, it can always get it by taking the address of
the directly callable function. "ptr = & glBegin ;"
OpenGL 1.2 (and later) functions might as well be treated as extensions
since you can't guarantee that all implementations will have them.
You may later decide that OpenGL 1.2 is ubiquitous enough that you
can simply call 1.2 functions directly - and then the behavior of
glGetProcAddress for the 1.2-specific functions becomes irrelevent.
(There is an open question of whether this standard should allow
- or perhaps require - conforming Linux OpenGL's to support
different OpenGL revisions in different rendering contexts...
That's rather freaky! It also makes naming the library
"interesting" - but it does seem possible that we could allow
this).
> If yes, then in the long run we're moving toward a COM-style
> interface where all functions are per-object (context) and
> must be queried before use. This is not necessarily an awful
> thing, but please be aware of the change in direction; this is
> not how ordinary C function libraries behave today. ``p =
> &glBegin'' yields a function pointer than can be used on all
> contexts on all OpenGL implementations with which I'm
> familiar. That simplicity has value.
That hasn't changed. Only "p = glGetProcAddress("glBegin");" has
changed - and there is no reason to favor that over "p = &glBegin;"
for core functions.
> If no, then what is it about extension routines that makes
> them so different in principle from the routines in the core?
Indeed - that's why the answer is "yes".
> We know it's not the implementation; we know of efficient ways
> to make extension routine pointers context-independent.
I agree...
...but some of us evidently don't - or else we wouldn't have all
this L-O-N-G debate. The debate has gone on long enough that we
are not going to change anyone's mind now. We *MUST* come up with
a final decision - and it needs to be before Mesa 3.1 hits the
streets.
> And why do you want extension function pointers to be
> context-dependent now, but expect them to become
> context-independent when the same functions are eventually
> added to the core?
I don't *want* function pointers to be context-dependent - I just
don't see any application-side problems if they are. Hence I'll
let the OpenGL implementors be sloppy and return different addresses.
Once the function makes it into the core, I still don't care
if glGetProcAddress returns different addresses for the same
core function...because I can just call the function directly.
Clearly once a function is in the core API, driver writers
MUST have a single function I can call directly.
> Not only does this seem inconsistent...
Well, that's why the answer to the question you posed is "yes".
> but it leaves apps that use extensions with a bunch of bloat
> to handle per-context pointers that they won't need in the
> future.
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
