JSplitPane.setTopComponent crashes *I think* my glCanvas

I have two components to this problem.

Component A is a GLCanvas inside a JPanel of a JTabbedPane.
Component B is just a JTextArea inside a JPanel.

When my program is started, componentA (with the glCanvas) is the default view of the top component of a JSplitPane. when the user selects a certain node of a JTree, I make a call to JSplitPane.setTopComponent() inside the TreeSelectionListener valueChanged() and set it to componentB, that works fine.

My problem is when I try to go back to componentA by calling setTopComponent(componentA) again (after I’ve already set the top component to componentB). It crashes.

If I comment out the few lines of code that change the setting of top components in my JSplitPane, then my program works fine. Otherwise, it crashes in an area that redraws the model in my glCanvas.

So I have the feeling it’s got something to do with the glCanvas and placing it back in the top area of the JSplitPane.

Does anyone have ideas on this, or know what might be going on?

Do you have a test case showing the problem? If so, could you file a bug with the JOGL Issue Tracker?

Are you using the latest nightly build?

I have a feeling that the problem with swapping out components of a JSplitPane has something to do w/ the GLCanvas that is contained within the JTabbedPane of the top component of a JSplitPane.

I have two JSplitPanes, splitA has a left and right side, and splitB is
contained in the right pane of splitA. splitB has a top and bottom
component. Sorta looks like this …

±----------+
| | top |

  • |-------+
    | | bot |
    ±----------+
    (l) ®

splitA = left and right
splitB = top and bottom (contained within right)

When calling JSplitPane.setTopComponent() on splitB from a JTabbedPane
to a simple JPanel, it works very smoothly and changes the top
component out correctly. But when I call setTopComponent again and put
my JTabbedPane back in (which btw hold a JPanel w/ the GLCanvas inside it), the entire window of my app blinks, both SplitPanes flash, even though I’m only calling setTopComponent of the inner splitPane (splitB). It doesn’t
change out smoothly like the first call did with just a simple JPanel.

I don’t think it’s anything wrong with the glCanvas, but I have an idea it might be the way I’m using it. I make the calls like this.


public class MyTreeSelectionListener implements TreeSelectionListener
{
   public void valueChanged(TreeSelectionEvent tse) {
      ...
      setComponentView(info);
   }

   public void setComponentView(MyInfo info) {
      if (myApp.rightSplitPane.getTopComponent().toString().contains(
            "JTabbedPane")) {

         if (info.getType() == PANEL_A) {
            myApp.rightSplitPane.setTopComponent(myApp.panelA);
         }
      }
      else {
         if (info.getType() != PANEL_A) {
            myApp.rightSplitPane.setTopComponent(myApp.tabbedPane);
         }
      }

      return;
   }
} 

myApp.tabbedPane is a JTabbedPane() component built like this:


   glPanel = new JPanel(new BorderLayout());
   GLCapabilities caps = new GLCapabilities();
   caps.setHardwareAccelerated(true);
   caps.setDoubleBuffered(true); 

   glCanvas = GLDrawableFactory.getFactory().createGLCanvas(caps);
   ...
   glCanvas.addGLEventListener(glRenderer);
		
   glPanel.add(glCanvas, BorderLayout.CENTER);

   tabbedPane = new JTabbedPane();

   tabbedPane.addTab("tab1" , glPanel);
   tabbedPane.addChangeListener(this);

Just wondering if someone might pickup on what’s going on here better. Any help much appreciated.

The current nightly builds are the current development build of the forthcoming JSR-231 reference implementation. The APIs have changed somewhat but the implementation has been drastically changed and is more robust than the 1.1.1 release. I would strongly recommend you upgrade your application to the new jogl.jar and native libraries. Regardless, if you can create a small test case illustrating your problem please file a bug and attach it.

Submit a bug with the JOGL Issue Tracker. You’ll need to log in and probably be an Observer of the project in order to properly file the bug and attach your test case.

I suspect the cause of your crashes is due to incorrect use of OpenGL in a multithreaded fashion in your app, especially because your small test case doesn’t seem to crash.