Thomas Roell writes:
> It's still an ugly problem. For an application programmers point of
> view, I really don't like the idea of GetProcAddress() be dependant
> upon the context it's called under. It's just a nightmare and a
> predictable recipe for disaster. On the other hand, letting libGL do
> the indirection for unknown extensions is very tricky.
And potentially slow?
This reminds me of a similar problem in the Java Native
Interface, where the JNIEnv environment (a vtable struct)
could be thread specific, as are the opaque handles for
fields and method. The native code gets the former when
invoked, and can opt to cache latter - implicitely being
responsible for tracking the context.
My vote would be in favor of a solution that puts the
burden on the application. It is an limited problem
to solve: the app needs to maintain some GLEnv per-context
storage of pointers (as long as we promise that pointers
stay valid for the entire existence of a context). This
is generic enough to be put into some portable toolkit,
isn't it? I mean, the Quake-style dlopen/dlsym table
could handle this kind of switching easily.
b.
