strange repaint problems

OpenGL Development JOGL Development
#1

Hello everyone,

I am having strange problems when using jogl in the following scenario:

Windows 2000
Java sdk 1.4.1_01
Nvidia Quadro FX 500 128 meg adapter

The application has a single GLCanvas which is positioned inside a JPanel using a Border Layout. The GLCanvas is in the CENTER. A toolbar is in the NORTH and a status bar is in the SOUTH. The JPanel with its 3 parts is inside a JFrame.

Here is the code fragment that sets these up.

/*
 * Now that all the members have default values, create the
 * toolbar, canvas and status bars and add them to the panel.
 * This has to come last because the toolbar queries the
 * members of this panel to fill in defaults for its dialogs.
 */
    setLayout (new BorderLayout());
    setMinimumSize (new Dimension (2, 2));

/*
 * Create a J3DToolBar and put it in the NORTH position.
 */
    toolBar = new J3DToolBar (this);
    add (BorderLayout.NORTH, toolBar);

/*
 * Create a GLCanvas and put it in the CENTER position.
 */
    GLCapabilities c = new GLCapabilities ();
    canvas =
        GLDrawableFactory.getFactory().createGLCanvas (c);

    isDoubleBuffered = c.getDoubleBuffered ();

    canvas.addGLEventListener (this);

    add (BorderLayout.CENTER, canvas);

    canvas.addMouseListener(mouse_listen);
    canvas.addMouseWheelListener(wheel_listen);
    canvas.addMouseMotionListener(mouse_listen);

/*
 * Create a status bar and put it into the SOUTH position
 */
    createStatusBar ();
    add (BorderLayout.SOUTH, statusPanel);

When the JFrame is first shown, the 3D view is ok, but the toolbar and status bar will not be painted, or be only partially painted. On subsequent interaction with the 3D canvas (picking, redrawing, etc.) then the toolbar and status bar will sometimes be repainted and sometimes be erased. I do not use my own paintComponent method in either the toolbar or status bar. I rely on the underlying swing behavior.

In addition, other frames in the application will often not be repainted when they are exposed or otherwise made “dirty”. In the case of one frame, which is a 2D drawing frame, I have my own paintComponent method which I have verified is being called and working correctly. This
2D frame will draw an image to the graphics2d, but the image never shows up. I have tried the drawing both with and without double buffering and the problem exists on both.

I run the same application on other systems, using other graphics cards, and these problems do not occur. The two computers we have that run the Nvidia quadro 500 both show the problems. Java applications that do not use any
jogl do not show the problems.

I am guessing that somehow the quadro 500, in combination with jogl, are interfering with the normal swing painting mechanism.

Any comments or observations are very welcome.

Thank you,

Glenn Pinkerton

#2

Hello again,

I think my problem may be from improper thread interaction. I admit that I am very confused with the issue of threads and JOGL.

I create the GLCanvas in the main thread. Then, when a mouse click is done, I am in the event thread and I call the GLCanvas.display() method, as the user’s guide suggests. This causes the listener’s display method to be called, but it is still in the event thread. The user’s guide says that no JOGL commands should be done in the event thread. I thought calling GLCanvas.display() was supposed to take care of the thread issues. I’m obviously missing something here.

Does anyone have source code that draws using JOGL and also has the AWT event processing going on? I could definately use some guidance here.

Thanks,

Glenn

#3

Sounds similar to what I’m looking at.

As far as I can see, calling GLCanvas.display() sets up and calls your GLEventListener.display() right then, in whatever thread you’re in. Setting the rendering thread does not mean that when you call GLCanvas.display() on the AWT thread it will switch to the other thread and call GLEventListener.display().

I’ve been able to get a rendering thread to start (and then call GLCanvas.display()), getting the GLEventListener.display() in the right thread. But if I use the AWT’s call to GLEventListener.display() to tell my rendering thread to go, then I start having problems with thread synchronization, plus a new issue I found in the Feb 4 nightly build.

So what I’d like to do is have AWT tell me to start my rendering thread without going through Jogl. But GLCanvas is final, so I can’t extend it to override the paint() method. So if I initiate the rendering, I’m fine. But if I expose the thing, the GLCanvas gets the paint, and doesn’t say anything about it. If there were another method in GLEventListener to tell me that a paint event came in, then I could start my rendering thread, which could be the only thread to talk to Jogl.

As I said on my post, I get the impression that I’m between the two expected ways to use Jogl:

  • just using the AWT calls to display()
  • calling display() continuously

andy

#4

Never mind, I don’t want to add a method like this to the GLEventListener, because those methods are distributed using the invokeGL stuff in GLContext, and that will have some of the same thread problems.

Maybe it would be OK if it just called its parent’s paint.

andy