Confused about GL contexts and texture loading...

OpenGL Development JOGL Development
#1

I’ve got myself a bit confused about GL contexts with JSR-231 and was hoping the good people here could help me:

The general tactic used in a lot of the utility code seems to be to the current GL from GLU.getCurrentGL () rather than passing it around. This is particularly the case in the JOGL utility code supporting Textures which I’m looking to move to.

However applications may end up using distinct GL contexts particularly if PBuffers are used. In this case textures loaded in one context are invalid when used in another context. In the past I have keyed texture IDs off GLDrawable/GLAutoDrawable.

What is the preferred pattern these days? Should I have a texture wrapper class that keys from GL (or GLAutoDrawable or GLContext…) to com.sun.opengl.util.Texture or extend Texture to handle keying ID to context internally? Or avoid having multiple contexts like the plague…?

#2

You can try to structure your application to share textures and display lists among all created contexts. Keep in mind though that different OpenGL implementations may have different restrictions on what kinds of contexts may share textures and display lists.

If you’re dealing with the case of a single OpenGL context, or multiple contexts not sharing textures, it is correct to map Texture to GLContext. When a GLContext is re-created (makeCurrent returns CONTEXT_CURRENT_NEW), or GLEventListener.init() is called, this means that all of the associated textures have been blown away and you have to reload them.

When you’re sharing textures among multiple contexts, this is no longer the case. In this case the textures are all deleted at the point when all of the contexts are destroyed.

Depending on your application it may be easier to try to do things with one context. If you need offscreen rendering as well you might want to try sharing textures with the pbuffer to simplify things.

#3

Thanks, Ken. Does that mean texture sharing works with pbuffers? Or only depending on OpenGL implementation? If the latter, how does one tell whether the local texture shares textures IDs? I have some places where offscreen rendering would be very useful, but I’m currently reusing the main frame buffer to avoid reloading textures - perhaps unnecessarily.

#4

Yes, you should be able to share textures and display lists between an on-screen GLCanvas and an off-screen GLPbuffer. However I believe that it’s theoretically possible for this to fail in which case you would get a GLException when the JOGL implementation tries to enable the texture sharing. Basically if you pass the correct value for the “shareWith” parameter to the GLCanvas / GLPbuffer construction methods and you don’t get any exceptions then texture sharing is enabled.

#5

Excellent - that’ll make things a lot easier!
Cheers.