Where did my texture go?

OpenGL Development JOGL Development
#1

I have an array of JPanels that are sequenced by button clicks onto a static area on the screen. One of the JPanels happens to be a GLJPanel with textures in the rendered scene. The textures are loaded only once in the constructor of the GLJPanel. When the GLJPanel is initially sequenced into view everything renders fine, but the next time it comes into view the textures are lost.

I have posted a sequence of views:

The initial view…
A button is clicked to cause the openGL window to be displayed…
Now the openGL window was hidden then accessed again for a second time…

Like I said before, the panels are not destroyed when not in view; they are kept in an array. My initial thought was to call updateSubImage(), but that did not seem to work.

Any thoughts?

#2

Hey.

Your links don’t seem to work for me. Offhand, I don’t want to insult your intelligence, but I’d suggest you make sure you don’t reinitialize your array of textures (assuming you have an array of textures.) Print out the textures, see if the numbers revert to zero.

#3

Ha, I wish it was that simple. The images are loaded when the 3ds models are loaded. The 3ds models are still active (they are being rendered), but the texture is lost.

btw, the links should work now.

#4

Have you put in printlns in your init(), reshape() and display() methods to see what is being called? It’s possible with the GLJPanel that you’re seeing more calls to init() than you might expect with a GLCanvas due to how it’s implemented and that you’ll need to reload your textures more than once.

#5

Hmm. I added a print statement in the init method, and sure enough it gets called every time the GLJPanel is brought into view.

Question: The background fullscreen panel is a GLJPanel. Would I see any anomalies if I changed the smaller GLJPanel that sits ontop of the background to a heavyweight GLCanvas, and would it solve the texture problem?

#6

It might solve the problem. It sounds like with the layout of components in your application the Z-ordering issue where the smaller GLCanvas would obstruct anything behind it won’t be a problem.

What JDK are you running with? I recall seeing situations where lots of addNotify() calls were being made on GLJPanels with 1.4.2 but these appeared to be fixed with 5.0.

#7

JDK 1.6.0

#8

There might still be issues with components which overlap in certain ways which is causing the unnecessary addNotify / removeNotify calls. If you can write a small test case which demonstrates this please file a bug with the JOGL Issue Tracker and attach it. I’ll distill it and file a bug against the JDK.

In the meantime, your GLCanvas workaround may work, or you could consider just doing your sub-component rendering using pure OpenGL rather than by adding another component to the widget hierarchy.

#9

Wouldn’t using the OpenGL/Java2d pipeline fix the problem anyway? Or using the background jpanel to load all textures and share it’s context to all subpanels?

#10

The views I posted are with the OpenGL/Java2D pipeline enabled.

I haven’t put much thought into sharing the context, but that sounds like a good option.

I will code up a small app that uses my current configuration, then one with a GLCanvas, and then one with a shared context.