JOGL vanishing textures!

[STRESS]

I have a rather strange problem and I can't really figure out what it is since it does not make any sense.

Okay here it goes:

I've got two Containers both containing a jReality viewer using the JOGL render backend. Both have a different GL context. When I generate texture objects in both container they get the same OpenGL texture IDs which is okay since the GL context are different and therefore ID shouldn't be shared.
However, when I remove the container during running the application and the garbage collector cleans up all the Java objects I notice that at the final stage of the JOGLRender dispose method it will delete all the textureIDs that have been created in its GL context it does that successfully, however textureIDs that have the same ID in the second container and its GL context vanish as well.

That shouldn't happen and I can't understand why it does happen. Has anyone else seen this problem?

[gunn]

I think the solution may lie in a static boolean in JOGLConfiguration class. It's called sharedContexts, and it controls an argument to the constructor that returns a GLCanvas. When it's true (the default) then the created GLContext's will share display lists and texture ID's and other such resources with a given GLContext. Here's the relevant part of the javadoc for that constructor:

... The passed GLContext specifies an OpenGL context with which to share textures, display lists and other OpenGL state, and may be null if sharing is not desired. See the note in the overview documentation on context sharing. ...

The default value, as noted above, is true, which means that all GLContext's will share resources with the first one created. To set it to false, you need to pass a VM argument of the form:

Code: Select all

-Djreality.jogl.sharedContexts=false

I unfortunately don't have an example with two separate viewers on which to test out this hypothesis. I have found and corrected a bug in JOGLConfiguration that prevented setting sharedContexts to false. So please update that file from the repository before trying to set it to false.

It may be that the current code in the JOGL backend actually expects sharedContexts to be true when textures or geometry (including display lists) is being rendered in two different containers. For example, there is no facility for storing off display lists on a per-context basis. But the texture ID's are stored off in GLContext-specific lists. You can help us out by reporting back on your experience when this variable is set to false.

[STRESS]

Hi Gunn,

No I am pretty sure there is no sharedContext used. Otherwise the texture IDs wouldn't overlap between the two different context but would be in a continous sequence.

Also I am using a SWT GLCanvas and I definitely do not create a sharedContext, I even changed the sharedContext to false in the JOGLConfiguration class. So it can't be that.

[gunn]

OK. I wasn't aware you were using a SWT GLCanvas, so I can't be much help here.

But I would encourage you to check the following. Somewhere you are creating a GLCanvas -- make sure that you are not passing in an existing GLContext as an argument. The point is this: even when sharing resources, the GLContext's that are returned are all different. But the display lists and texture id's that are created are shared between these contexts. This is consistent with what you are seeing: the GLContext's are all different, but the texture ID's are repeated. I think texture ID's are global ID's (not per context), and when you see a repeated texture ID, it really refers to the same texture.

[STRESS]

OK. I wasn't aware you were using a SWT GLCanvas, so I can't be much help here.

But I would encourage you to check the following. Somewhere you are creating a GLCanvas -- make sure that you are not passing in an existing GLContext as an argument. The point is this: even when sharing resources, the GLContext's that are returned are all different. But the display lists

Thanks gunn,

Yep I am pretty sure that's not the case. Since sharedContext feature was only added in Eclipse3.5 while I am still using Eclipse3.4 that's why I am really confused.