hello,
when using a GLJPanel it may happen that the init() is called multiple times, since the context is recreated.
now this means that all the gl objects, like textures, shaders, displaylists and VBOs are lost. is there a way to save them? or to transport them from the old context to the new one?
thanks!
You should be able to create a pbuffer to share the objects, but I don’t know the details.
What I’ve done before is to have a higher level object that knows how to turn itself into a GL object (so it can init() and change the way things are rendered (shader), or actual render something(vbo)). Each time I render it, I check when it was last initialized and if the context it was initialized on isn’t the current one, then I know I have to re-init that particular gl object.
Of course, it’s more complicated if you have multiple windows, and in that case you’d probably save a lot on memory if you figured out how to share contexts with pbuffers.
Alternatively you can use small fixed size Pbuffer and use FBOs for your rendering and manually copying it back to CPU to render.
Beware that copying from GPU to CPU and back to render is very slow. Doesn’t matter if done “manually” or by GLJPanel. For realtime stuff consider using heavyweight components to clip child windows and using real GLCanvas or do overlay directly in OpenGL.
Just a note, GLJPanel can cooperate with Java2D OpenGL pipeline which gives both really good speed and Swing integration, but this pipeline is (due to various driver bugs) unusable to depend on in practice. Also I had input lag when using it.
thank you all for your help.
cylab, would that mean one pbuffer for each object, or one for all the objects? i have about 300+ textures in my game.
lhkbob, that sounds like a good idea. how exactly do you perform the check if the context of the object is current? isn’t that quite a costly check? and in case of textures doesn’t that mean that you will need to keep all the bufferedimages of the textures in memory, since you will need them when you reinitialize the texture-object?
jezek2, yeah i think getting all the textures down from the GPU might be too slow.
One pbuffer just to have a stable context. Search the forum, there should be some posts regarding the issue. I think jezek means to do all your rendering in the pbuffer and copy back the resulting framebuffer - which is afaik exactly what GLJPanel does for painting the swing canvas, but JOGL recreates this pbuffer/FBO on every resize, because you can’t resize pbuffers.
The way I checked it was pretty fast. I made a wrapper context class that I would pass around instead of GLs or GLAutoDrawables that would hold onto the GLAutoDrawable (to get the GL instance when needed) and to keep count of all the times the wrapper’s GLEventListener init() method was called. This count would then be used as a version, so when applying some object to my scene, the object would see which context version it had last updated itself on. If the count was not the same, the object would re-send itself to the graphics card before continuing.
With my strategy you do need to keep everything in memory, which is unfortunate, or you could reload everything when an initializing was called again. I had tried using the single pbuffer to share objects with but couldn’t seem to get it to work (the docs says it’s not always supported, too), so I decided to go with a guaranteed solution even if it wasn’t optimal.