Re: [oglbase-discuss] OK, back to Re: 2nd draft:GL_EXT_get_proc_address spec

[Michael I Gold]

I am not aware of a precedent for any piece of state returned by a context
being applicable to any other context, with the noteable exception of
shared display lists and texture objects.  In these exceptional cases,
there are well defined criteria for sharing, and coincidently, these shared
contexts can also share ext function ptrs.

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.

How difficult is this?  Not.  Its a lot simpler in the app than in the
implementation.

init context:

   this->ActiveTextureArb = glXGetProcAddress("glActiveTextureARB");

#define glActiveTextureArb (*this->ActiveTextureARB)

Straight C implementation left as an exercise for the user.


Regarding the proposed dynamic allocation of ptr slots in a libGL.so
dispatch table: this depends on the ability to use assembly to jump to the
real function w/o modifying the call stack.  This is not difficult, but it
seems strange that we cannot write a sample implementation in straight C.
I don't know if this is a consideration, but it seems interesting nonetheless.