I have an application that works well, using a single GLCanvas for drawing. When I add a second GLCanvas to the outer JFrame, the JFrame and dialogs modal dialogs created over it no longer repaint correctly. The two GLCanvas objects are updating, but the Swing objects in the aplication appear to repaint on some random schedule. Has anyone else seen this?
Are you running on Windows? Have you specified -Dsun.java2d.noddraw=true on the command line (required for all JOGL applications on Windows)?
Do you have a test case?
i had this problem too, it seems there are too much jogl thread time compared to AWT thread time
if only one of your canvas is “moving” at the time and this others display a still picture as long as noonne touch them (this was my case) you should stop all “inactive canvas”'s animators and only start the animator of the one canvas that is moving
but if you have, lets say, two simultaneous display of a moving scene from different point of view, i don’t know what to do
If you have multiple GLCanvases and are using an Animator to drive each of them then I would strongly recommend you use only one Animator object and add both GLCanvases to it. Otherwise you will definitely swamp the CPU with the animation threads.
I had a similar problem and using a single Animator made a big improvement. But I still see slow repaints of a dialog when draging around the dialog over the top of a canvas (that is being animated). Also some users have repoted that closing the dialog leaves a black rectangular hole on the underlying canvas, that just doesnt get repainted.
Peter
What JDK are you running on? Have you tried using an FPSAnimator, which will throttle back the CPU usage more? If you’re on 5.0 or later, does the command line option -XX:-UseThreadPriorities help when the dialog is being dragged?
On systems where the canvas doesn’t seem to get repainted after closing a dialog which occludes it, do you know what graphics chipset is in use?
The flag doesn’t help, but it seems like the CPU is just maxing out when dragging a dialog. That probably explains the slow repaint. In fact its more like a black shadow that follows the dragging rather than the actual dialog not repainting.
I’ll try and determine the graphics card thet the shadow stays on after dialog close…
Thanks
Peter
java version “1.5.0_06”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot™ Client VM (build 1.5.0_06-b05, mixed mode)
If on Windows, have you specified -Dsun.java2d.noddraw=true on the command line?
yes I’m using the noddraw flag.
I don’t have a simple test case, but I could email you a login for the app?
This is the info for the user reporting the ‘black hole’ in the screen after closing the dialog.
GL_VENDOR=S3 Graphics
GL_RENDERER=KM400/KN400/MMX/K3D
DRAWABLE_GL=com.sun.opengl.impl.GLImpl
cheers
Peter
Feel free to email me instructions at my dev.java.net email address (linked from the jogl home page).
With an S3 graphics chip I think it’s a miracle that any OpenGL is working at all. I’d recommend you suggest to that user to look for an updated driver and if there is none then to email S3 about the problem. Personally I strongly prefer NVidia hardware even in notebooks.
FYI:
My black shadow issue was fixed by using the following flag:
-Dsun.awt.noerasebackground=true
Thanks to Ken for that!
Peter
whitehexagon.com - one step closer to online LEGO 
Note that this flag and its effects are documented in the JOGL User’s Guide. Please feel free to post if you think it warrants more documentation. This is an issue for basically any OpenGL / JOGL app that you expect to drag other windows on top of, but doesn’t have a good general solution before Java SE 6. (In Mustang we were able to turn this flag on only for GLCanvases and not for all windows globally.)