? What is best way to keep context after reinit/reshape ?

[Z-Knight]

When you reinitialize/reshape a JOGL display I believe the context get destroyed and the init() method has to be called again to restore things. This is bad because I lose things like my display lists or my VBOs or Vertex Arrays and I have to recreate/rebind them, etc.

What is the best way to prevent this…how can I maintain reference to, say a display list, so a reshape doesn’t require me to remake it? If I’m resizing my window or revalidating the panel that my GLJPanel resides in then I lose my context and I have to wait and rebuild things - this can be annoying for users.

I read a while ago about “sharing contexts” but I don’t know how that works. Any suggestions on what to do?

[Z-Knight]

I had posed this question a while back in: http://www.java-gaming.org/topics/gljpanel-and-the-init-method/18054/msg/141666/view.html#msg141666

The answer at the time involved “It was suggested that I essentially build a separate GLContext at the start where I load my textures and models (make it current initially and then release it), then follow this with building the normal GLContext for my scene and then share the initial context data with it in the init() function (i.e. following resizes, etc).” … has anyone done this?

[Z-Knight]

Sorry for my constant posts…here is what rogersgb had suggested…I may need to look at this:

I have the same problem with textures and display lists on a GLJPanel. I store them in hash tables when they are created. If they need re-initialized due to context destruction I just grab them back out of the hash table. That implementation works for a heavyweight canvas as well.

[lhkbob]

A couple of things:

1. GLCanvas doesn’t have this resize problem. But the problem happens if it’s hidden and then shown again. GLJPanel has issues with resize because it uses a pbuffer, which has a fixed size.
2. I have done context sharing and I don’t think it is that difficult, especially if you’re not worrying about multi-threading (which you shouldn’t). However, if you’re game or app is simple enough that it can hold most things in memory, then rogersgb’s approach is much simpler and less prone to bugs, although less efficient. At a small scale, that efficiency won’t matter.

[Z-Knight]

I have to use the GLJPanel because I’m inside a Swing component/frame so the GLCanvas won’t help me. I’m not doing anything as taxing as a game, simply I’m drawing a 3D scene with the International Space Station vehicle (loaded from a 3DS file) and other approaching vehicles to show their relative position/attitude. I don’t think it has to be on par with game performance, as long as I can get sub-second updates of the scene because my telemetry updates would come down at least at 1sec rate and I can’t be waiting for the graphics to still update.

How do you go about the context sharing - I understand the concept in principle but have no idea how to even start that. As for the HashTable approach, I’m not sure how do I use it to use it to deal with more complicated things besides display lists - like the textures or buffers? In either case, at minimum I need to make sure that once I load my textures and buffers that I store them away and only during init() do I bind them - right? There is nothing else like having to recreate buffers (I just can’t recall)?

I guess what I’m asking is for some direction on how to do the context sharing and/or hash table approach - is there some good reference I can look at or do you have some sample I can check out? The main reason I need this ability is because the graphics card I use on my development machine is poor and display list updates (and vertex buffer/array updates) for my 3DS models seem to take a long time, and if the user does too much resizing then they will really start to get annoyed at the delay.

thanks.

[gouessej]

@Z-Knight

I have to use the GLJPanel because I’m inside a Swing component/frame so the GLCanvas won’t help me.

GLCanvas is enough in most cases even with Swing components except when using internal frames. Otherwise, NEWT is a bit more robust to do that. I have already tested NEWT with AWT components; if you need to use it with Swing, I will test it with Swing too. I think it would be a better solution because your context would not be destroyed even though you hide the GLWindow (NEWT) and you show it anew later. Maybe this would be enough for your needs.

I already had the same problems when I wanted to implement a fullscreen toggle in a commercial application. The user could modify some meshes in windowed mode and I had to keep the context alive when he switched to full screen mode and vice versa.

[Z-Knight]

I noticed one thing strange in my GLCanvas version that has me additionally focused on the GLJPanel and that was some horrible flickering. I need to test it again but it was the flickering of the canvas itself that just made it too frustrating to use.

Edit: yeah, still have it. When I move my frame the GLCanvas section just flickers until I stop and sometimes it just goes blank (disappears) and I have to click inside the GLCanvas section to get it to come back. It is frustrating as hell.

Edit 2: I saw a post by ‘cgull’ at http://stackoverflow.com/questions/414915/jmenus-caused-jogl-glcanvas-canvas-to-flicker that said the following in the quote below…and it seems to be working. I just need to make sure it doesn’t break something else.

This is caused by AWT erasing the GLCanvas every time before JOGL repaints it and can be worked around by inserting the following line into your main() method:

System.setProperty(“sun.awt.noerasebackground”, “true”);

While this solves the given problem, side effects are possible in other areas of the application such as visible artifacts when resizing the window. I use this in all my JOGL apps though without any problems.

Edit 3: I need to give up…I really do. Now the noerasebackground is essentially preventing any updates to my scene unless I move my mouse in the view. This is so damn frustrating - have I said that yet?!

[Z-Knight]

So far, the main break I have after fixing the flicker (see above) is that my JMenus appear beneath the GLCanvas - basically a lightweight/heavyweight issue.

I saw that this kind of issue seemed to be fixed with JDK 6.0 update 12 and above…but I have update 23 and I still see it. This is the quote I found http://java.sun.com/developer/technicalArticles/GUI/mixing_components/. Maybe I need to try JDK 7

As of the JDK 6 Update 12 and JDK 7 build 19 releases, it is now possible to seamlessly mix heavyweight and lightweight components within the same container. The following screen captures show the same three examples, run under the JDK 7 release, with no changes to the code. In each case, it just works.

Edit: GLCanvas is still causing my popup panels (JWindows) to get partially hidden. Too bad this wasn’t truly fixed as they say.

[Z-Knight]

Another thing I noticed with GLCanvas has to do with resizing it. I have it part of a top component of a JSplitPane. When I resize the bottom component by moving the divider down the GLCanvas grows bigger but then it prevents me from shrinking it back. The bigger it gets the bigger it stays and won’t let me make it smaller? Any idea why?

Edit: Seems like others have had the same issue and this is due to the heavyweight of GLCanvas
http://forums.techarena.in/software-development/1267145.htm

Sigh…now you see why I chose GLJPanel. ;D

Edit 2: It seems I need to do more searching…hehe. Here is the solution http://www.java-gaming.org/index.php/topic,18457…

Basically I added this setMinimumSize() on the panel that contained my GLCanvas:

// We need to create a Dimension object for the JPanel (containing the GLCanvas) minimum 
// size to fix a GLCanvas resize bug. The GLCanvas normally won't recieve resize events 
// that shrink a JPanel controled by a JSplitPane. 
setMinimumSize(new Dimension());    

Thank God for JOGL developers that came before me.