While its unfortunate that we have become so bogged down on a single
implementation issue, its understandable given the requirement of defining
the sematics in a multi-context environment. We couple play it safe and
keep the Windows semantics, which I prefer, or embark on this path of
context independence for dubious benefit. The latter clearly imposes
implementation constraints, while the former does not.
In my mind there are two unresolved issues:
1) Whether or not returned pointers are context independent
2) Whether this is a GL extension or a GLX extension
and I see the two as being peripherally related.
If we are going to allow context-independent pointers, then this MUST be a
GLX extension. If its a GL extension, it doesn't make any sense
semantically to allow the same value to be used with other contexts.
Give that so many (otherwise reasonable ;-) people are pushing for context
independence, I'm nearly out of energy to fight this. Sorry to bring up
impementation details again, but let me remind you that in the Good Old
Days before we made this decision, it was possible to change dispatch
tables with a single assignment:
gc->currentDispatchState = __glImmedState;
Now we'll have to do "extra stuff" to copy all but the core 1.0 entry
points into the libGL.so dispatch table.
In the Windows world we have an unfortunate (and avoidable) requirement to
do "extra stuff" whenever we modify the dispatch table or bind a context;
we call a callback in opengl32.dll which copies the entire core dispatch
state into a hidden table in the opengl32.dll TLS. I was hoping we could
do away with such overhead and simply bang on the dispatch state directly.
With the model people are pushing for here, we'll simply have to keep the
requirement to do "extra work" after tweaking the dispatch table. This
extra work may be ugly, as it now must map extension entry points into
dynamically allocated libGL dispatch slots, but its clearly possible, if
not desireable.
Therefore, unless I think of something even worse than the issues I am
already concerned about, I will simply register my very strong objects but
stop fighting it. I think we are making a mistake and will not understand
the full impact until actually trying to implement this. Now, if someone
else wants to take up the cause on my behalf, be my guest. :-)
Sigh,
-- Michael
