| I am at a loss. Now I live in a world of few contexts, so
| maybe my reasoning is wrong, but as we seems to be stuck
| at this point, maybe I'll describe my solution, and somebody
| points out where I'm naive.
I think it misses the point. It's not that someone couldn't
implement a layer to handle the context dependencies
and it's not that one couldn't stuff a bunch of wrapper
functions in GLU or some other utility library, its that
there isn't a need to since most OpenGL implementations
already use indirect dispatching and this layer could be
consolidated into that mechanism without much effort. Why do
something when you don't need to (especially if it causes
you to build additional API to do what you wanted in the first
place)? All of the performance related arguments up to this
point have been overstated as several people with OpenGL
implementation experience have pointed out.
Second, it only addresses part of the problem. The other
client side API functions are in fact just client side
wrappers which need to be properly vectored by an implementation
anyway. For example, if I use glFooEXT with two different
contexts pointing at two different screens, I still
need to do the correct dispatch for each of these inside
the OpenGL implementation. I can readily see the argument
that the function pointers are just a different implementation
of the client side bindings and they should just follow the
same rules. One wonders if the identity should hold true
that glGetProcAddr("glVertex3f") == glVertext3f.
The fact remains though, that different contexts may
not implement the same set of extensions, though it is
more likely the case that different screens may not implement
the same set of extensions, so applications are obliged to
check for the presence of the extension relative to each
context and adjust their behavior as necessary, but this
is orthogonal to whether the client pointer refers to
the same code segment or not.
-db
