As far as I understand OpenGL, it's got one current context per thread, and libGL does all sorts of evil things with threads and thread-local storage to make it all work transparently. An object-oriented OpenGL interface seems like the right way to go, though, for all sorts of other reasons.
That's correct. The problem is that since OpenGL APIs do not have a way to indicate which context to use (it assumes the "current" context), there's nothing you can pass to a callback to ensure it has the right context.
What I've done in the past is to create an OpenGL context using a 0x0 Window display, and cache that based on device/display depth/type (RGB, RGBA, etc). This can be used to query capabilities and extension support, as well as create offscreen contexts (eg: FBOs). I use this to create OpenGL objects.
libGL is interesting in that it attempts to abstract WGL and GLX (via Mesa) - the downside is that Mesa is behind the curve in supporting OpenGL extensions. It'll be worth exploring to see if it makes sense to extend Mesa, or to just leverage what libGL has done within POGL.
Good input - thanks! - Bob
