I’m mixing JOGL and swing, and getting some sluggish response form my Swing components (thankfully, JOGL is still pretty speedy). I suspect that the JOGL thread is starving AWT. Is there some way to move it to a lower priority? At the moment, scrolling a JTree within a JScrollPane is pretty choppy.
You don’t need to use JOGL’s Animator class to cause your components to repaint, if that’s what you’re doing. Have you tried using the FPSAnimator, which should consume less CPU?
I’ve tried using FPSAnimator, but it’s not freeing up any CPU time. Even if I slim the FPS down to 10, it’s using the same amount of CPU power as an ordinary Animator. Does the FPSAnimator yeild the thread?
It uses java.util.Timer to implement itself with whatever thread yielding that class does.
What OS are you on? We have seen AWT event delivery problems more frequently on Linux than on Windows.
We have seen some weird issues where repaint() calls on Canvases (not even GLCanvases) seem to be given significantly lower priority than other AWT events. The workaround we found was to use EventQueue.invokeLater() to send a paint message directly to the target component. I don’t think this is the issue you’re running into, though.
Is your JOGL rendering very CPU-intensive? What happens if you don’t use any kind of Animator, but just let the window repaint itself on demand? Do you get the responsiveness back from the rest of the GUI?
I’m using Windows XP.
Ther rendering is intensive. It’s rendering animated content, so there is an update every frame. For now the geometry is simple: it’s just rendering the GLUT teapot with a multitexture. The profiler is showing that bliting this teapot is taking the bulk of the CPU rendering time at the moment. (I’m not using a display list)
This might be related to the situation in which I’m using it. The reason I started investigating the FPSAnimator is because I’m getting bad performance during debugging sessions under NetBeans. Things run fast enough when running normally and FPSAnimator seems to slow the frame rate down to the appropriate choppiness. However, when run under the debugger, FPSAnimator is not giving me any extra leeway.
If the rendering is CPU-intensive then you’re keeping the AWT event dispatch thread hung up for long periods of time which could explain the unresponsive other GUI elements.
I’m not sure there is a good solution for this aside from trying to make your rendering pass cheaper. There are hacks you can do (using undocumented JOGL system properties, for example) to move the OpenGL rendering work completely off the AWT event dispatch thread but I really wouldn’t recommend you go this route as we have experimented with it internally and it really isn’t robust across platforms.