Shader descrution in Jogl

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Shader descrution in Jogl

slajar
Hey there,


I am using jogl now for years and it has been performing great since jogl1 :) Now I just upgraded to jogl2 and it still is superb. Thumbs up.

Now, my question. I have many shaders running in my app. Actually there should only run two vertex and two fragment shaders at once. Since my shaders need have high computing impact. I really would like to destroy the "old" ones.
I have got my own shader object with a my own destroy method. This works pretty good when I changed the shaders from outside. No memory lea occours in this case.

The only problem occours if, my windows is closed by the user and after that it is reopened. My shader class cannot destroy the shaders in the new window since it has another GL-Context and another calling thread.

I know there is dispose() in GLEventListener. Unfortunately, the glAutoDrawable looks not the same as it was at the time of creation of the shader at init().
Is there something like a best practice for destroying unused ressources in Jogl?


kind regards
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Shader descrution in Jogl

gouessej
Administrator
Hi

Actually, when you add a GLEventListener into a GLAutoDrawable, all its callback including init and dispose should pass the same GLAutoDrawable except if it gets destroyed and recreated in the meantime but if it's recreated, init is called anew too. The OpenGL context is destroyed just after dispose(). I think that you don't have to do anything in your case. Keep in mind that init and dispose can be called multiple times in the lifetime of a window.

"unused ressources" is a bit vague. If you want to release some resources at runtime before closing a window, it's up to you to do that. JOGL manages the life cycle of its abstractions and allows you to force the destruction by calling destroy(). If you want to delete an OpenGL identifier (texture, buffer, shader, ...) earlier before the destruction of the context, you have to do it yourself when this context is current. Of course, you have to handle off-heap native resources by yourself too, especially direct NIO buffers.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Shader descrution in Jogl

slajar
thank you for your reply.
The problem on my side is not the GLAutoDrawable in destroy, but it is the context that becomes invalid. I created another thread for this.