JOGL Within Protege

OpenGL Development JOGL Development
#1

As part of my work, im trying to write a plugin for a program called Protege using JOGL. Essentially, all you have to do is extend the AbstractTabWidget class provided in the API and away you go. This seems to work…ish. Using my current approach, the JOGL window overwrites all the other tabs in the protege application “until” the JOGL tab is selected. Switching to the other tabs results in just a grey area until the window is resized. Performance, as whole, on the other tabs is quite slow. I’d like JOGL to only do its rendering loop when it is at the forefront and to call a repaint when its not doing anything. Here is the the code i have and the hierarchy of the tab widget class from the javadoc:

java.lang.Object
java.awt.Component
java.awt.Container
javax.swing.JComponent
javax.swing.JPanel
edu.stanford.smi.protege.widget.AbstractWidget
edu.stanford.smi.protege.widget.AbstractTabWidget

Code in the tab:

public void fireGL() {

behaviour3D = new Behaviour3D(owlData);
//Now we will create our GLCanvas 
GLCapabilities glcaps = new GLCapabilities();
glcaps.setHardwareAccelerated(true);        glcaps.setDoubleBuffered(true);   
glcaps.setSampleBuffers(true);
glcaps.setNumSamples(4);
GLDrawableFactory gldFactory = GLDrawableFactory.getFactory();
GLCanvas glcanvas = gldFactory.createGLCanvas(glcaps);
glcanvas.addGLEventListener(behaviour3D);

//create the animator
animator = new Animator(glcanvas);

//add the GLCanvas just like we would any Component
add(glcanvas, BorderLayout.CENTER);
glcanvas.setSize(500, 300);

//center the JFrame on the screen
centerWindow(this);

}

#2

Performance, as whole, on the other tabs is quite slow.

This is probably caused by the animator. The animator runs in a tight loop calling display over and over again. The program consumes all available processing power drawing things to the frame buffer although they are never actually visible on screen.

The other problems might also be caused to this.

Try to remove the animator and call repaint on the GLCanvas at the end of your display implementation instead. Java swing should automatically supress these continous repaints when the GLCanvas is hidden by other tabs.

#3

It shouldn’t be necessary to call repaint() manually; just remove the Animator and the GLCanvas should automatically call your GLEventListener for repaint events.

#4

Excellent, thanks for the help. That seems to have worked although the events that the GLEventListener takes care of should now fire off a repaint i think, so that i can get the keys to move around the scene etc, but yes, it does seem to work better. Only thing is, when the tabs of the program are loaded, the GLCanvas is superimposed over all of them. When i select the java tab with the canva then switch to on of the other tabs, everything works fine again. Maybe i can delay loading the glcanvas till its tab is selected. Probably the best method. anyway, thanks for the help :slight_smile:

#5

Hmmm, im not sure this is right. Everytime i resize the window, im guessing a repaint is called. However, i keep getting this message:

glLoadTransposeMatrixfARB() supported: true
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: ATI Radeon 9600 OpenGL Engine
GL_VERSION: 1.5 ATI-1.3.28

It seems like its restarting totally from scratch. Is this right or not? Cheers

#6

It sounds like the tabbed pane widget is lightweight and that you’re running into problems with the heavyweight GLCanvas overlapping the contents of the other panes. If you remove and re-add the GLCanvas every time then yes, your init() method is going to be called again because the OpenGL context will be destroyed and recreated. As a workaround you might try resizing the GLCanvas to (1, 1) or (0, 0) when it isn’t visible.