how to tell context is going away?

OpenGL Development JOGL Development
#1

Hi. We are using jogl to provide contexts and control access, but are using other (non-Java) libraries to do our OpenGL work. We need to know when a context is going away, so that we can clean up some things that we remember are in the context.

In the case that a window is closed, we’re currently getting a removeNotify(), and calling display on the GLAutoDrawable. Then, inside the display call back to the listener, we know the context is valid and clean up what we need to clean up. It would be really nice if there were a 5th call to the listener, which was called with the context current and before it went away. Since there isn’t, what do people do instead? I imagine it isn’t necessary for all those doing everything in Java, but I know we’re not the only ones who aren’t. Maybe someone else has an idea.

A different case is when we’re using the GLJPanel and resizing forces a new context to be built. We get an initialize() call for the next context, but by then it is too late to clean up the old one. We’re not getting GLEventListener reshape calls or resize calls from the components in time to do the trick we do for the close (calling the display). Any suggestions for this case?

thanks,
andy

#2

The reason JOGL doesn’t provide a “destroy” callback is that it’s impossible to do it reliably. By the time the JOGL implementation receives notification that the underlying drawable is going away, there is no guarantee that the context can be made current again.

If you can provide more detail on exactly what kind of cleanup you need to do that would be helpful. You may be able to share textures, display lists, etc. with a 1x1 pbuffer and do your cleanup from the pbuffer’s context, but in theory you shouldn’t need to do any manual cleanup on OpenGL resources once all contexts that refer to them have gone away. Server-side OpenGL objects are reference counted from the contexts which refer to them.

#3

Well, we’re not really JOGL except to provide the context. Once we get a display() command, we’re off to tell our OpenSceneGraph (which we’re using for OpenGL) to start drawing.

OSG is a C++ API, and it deals with OpenGL itself. It has all its own OpenGL resources, and they need to be cleaned up. We think the context to which they belong needs to be current in order for them to be cleaned up.

So we know we’re not in the direct intended use for JOGL, but would appreciate any suggestions for how to know to clean up would be appreciated.

thanks,
andy

#4

The workaround you described above to override removeNotify() is exactly what I would have suggested for the GLCanvas case.

For the GLJPanel, I think you should be able to override both removeNotify() as well as reshape(int x, int y, int width, int height) and in both cases proactively destroy the OpenGL resources for the underlying scene graph during the next display(). It isn’t guaranteed that a reshape() will cause a destruction of the GLJPanel’s underlying pbuffer, but it shouldn’t kill your performance to do your needed cleanups every time. If it does, you can always copy the code for the GLJPanel and implement your own hooks – the pbuffer implementation of the GLJPanel is implemented using only public JSR-231 APIs.

#5

Thanks. I think we tried getting reshape(), but it didn’t happen before the context was gone. Maybe we could try it again.

However, we’ll also note your idea of copying the GLJPanel PBuffer code.

thanks,
andy