GLEventListener destroying method

Hi all, I’m Matteo and I’m new to this board as well for JOGL.

My main problem is on GLEventListener.
Inside 1 native (ansi C) method i create some OpenGL resources (say display lists and shaders).
Inside 1 native (ansi C) method i destroy the previous generated resources.

I’ve found that the public void init(GLAutoDrawable drawable) method is the right place where to call my first native method, because on init function the OpenGL context has been already opened and made the current.
But unfortunately (I’ve spent several hours in searching) i cannot find a destroy-like method that is called before the OpenGL context is being destroyed. Calling my second native method on other parts (say when the GLUT loop class stops) results in OpenGL errors (error code 0x502) that indicate invalid operations because the OpenGL context has been already destroyed.

Please i need your help.
Thanks in advance.

Just add your cleanup code to your main display loop. When your quit flag is set then run one last time through the display code and destroy your display lists and textures.

In the context of JOGL, where you’re potentially dealing with OpenGL widgets being added and removed from the widget hierarchy, it’s basically impossible to provide a “destroy” callback. There is no guarantee that you’re going to be able to make the context current “one last time” to clean up resources.

One important point to make is that OpenGL resources like textures and display lists are reference counted among contexts. So if you have a context that doesn’t share textures and display lists with any other one, and that context is destroyed, then all of the textures and display lists are destroyed along with it.

You can notice that a new context was created (and implicitly that the old one was destroyed) in your init() callback, assuming you aren’t sharing textures / display lists with another context.

If you are sharing, then these objects have the lifetime of the longest-lived OpenGL context in the share set. It’s then up to your application to determine when a call to init() really needs to re-create any of these objects.

Depending on how your native code is written (in particular, where the display list and shader IDs are stored) you may not need to call your second native method at all (and still not have memory leaks).