GLJPanel "hello world" woes: AWT event thread deadlocking?

OpenGL Development JOGL Development
#1

I’ve had pretty good luck with GLCanvases, but I need to use GLJPanels in a couple spots and I’m having trouble. After starting the application, it appears that all AWT events stop occuring: my top-level JFrame cannot get focus, no AWT event listeners are called, and there are no calls to my GLEventListener. My top-level JFrame is created and paint() is getting called at some point (I changed the background color so it would be obvious.)

My best guess is that there’s a deadlock or an unreported thread death (probably not an infinite loop, as I do not see elevated CPU usage) somewhere in the GLJPanel’s paint() code.

If I use a GLCanvas instead, I can render a few frames, but then it also appears that AWT events stop occuring.

I’m running x86 Fedora Core 5, java 1.5.0_06-b05. I’ve tried JSR231 dated 2/17 and the most recent nightly build with the same results. I have a nvidia Ti4200 using the proprietary nvidia driver 8178. Other OpenGL apps seem to work fine and glxinfo reports that direct rendering is enabled.

I will check my x86_64 machine when I get home-- my GLCanvas code worked fine on that machine last time I checked (but I don’t know whether I had GLJPanel problems.)

Any ideas?

-Ed

PS: Is there a graceful way to enable anti-aliasing if (and only if) it is supported? On my lesser x86 machine, I have to remember to disable anti-aliasing or a GLException is thrown complaining about XVisualInfos.

#2

Could you generate a thread dump using either Ctrl-\ or sending SIGQUIT to the target process when the hang occurs and post the output?

If you specify -Djogl.GLContext.noopt with the current nightly build does that change the behavior?

I thought you mentioned that GLCanvases were basically working for you, but later in your post you indicate that even using a GLCanvas causes a hang to occur. If this is the case, and it’s different than the other hang, could you post a thread dump for this as well?

Regarding antialiasing, could you post the exception stack trace? I would think that if you wrote your own GLCapabilitiesChooser as in the Multisample demo in the jogl-demos workspace that you could get full control over this.

#3

I’ve reproduced the problem again. I’m attaching the JOGL test application I’m using (very simple, but none of the GLEventListener methods are ever called, and the window fails to redraw itself in response to focus events.) I’m also attaching a thread dump which does seem to show the AWT Event thread stuck in a GL method. (Repeated Control-\s produce identical stack traces on that thread.)

RE: aliasing, I had overlooked the GLCapabilitiesChooser constructors and will give those a try!

-Ed

Linux version 2.6.16-1.2069_FC5 (bhcompile@hs20-bc1-3.build.redhat.com) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 Tue Mar 21 17:12:57 EST 2006
Nvidia 8178

#4

I’m not sure what’s going wrong. It does look like you’re using a slightly older version of JOGL judging from the thread dump, but you indicated you’ve also tried recent nightly builds.

Your test case works fine on both my Solaris/SPARC and Solaris/x86 machines, the latter of which has an NVidia card and is running NVidia’s Solaris/x86 drivers. I’m not sure what to suggest at this point. Does the JGears demo work? Your test case is about as simple as it can be already; the JGears demo would only be more complex, but at least is known to work on various configurations.

Can you create pbuffers successfully at all? Does the demos.proceduralTexturePhysics.ProceduralTexturePhysics demo work?

#5

I wanted to follow up briefly-- I’m still investigating.

The problem seems to occur consistently when rendering to a GLJPanel, but not when rendering to a GLCanvas.

I suspect there may be a driver stability issue involved too: when I use the GLJPanel, my X session will sometimes spontaneously die.

Is it perhaps a problem with the old graphics hardware in this machine? Perhaps the card does not support some of the off-screen rendering capabilties that GLJPanels require? (Or perhaps my dual-head configuration-- using two separate cards-- could be complicating things?)

Head 1 is a GeForce4 Ti 4200
Head 2 is a GeForce2 MX/MX 400

Would you like a stack dump using a particular build of JOGL?

#6

I’m not sure that will help. You are in uncharted territory with your dual-head setup. You would be much better off getting a newer card supporting dual outputs and driving both displays from it.

#7

well, the new nvidia drivers didn’t help either.

I’ll have some interesting data points soon: my advisor agreed to buy me a new video card… it’ll be interesting to see if the problem goes away!

#8

If its an AWT threading problem, check this out, Luke has come up with an elegant fix.

http://www.java-gaming.org/forums/index.php?topic=13211.new#new

Keith

#9

My god, is Sun really adopting the retarded windows-esque threading model? I’ve been telling my associates that Swing is cool because, unlike windows, you don’t have to invoke delegates to do simple things.

I followed some of the links, but I couldn’t find a succinct description of how deadlock occurs. It seems to me that most Swing classes are thread safe already: get() methods do nothing interesting, and set() methods modify the widget’s internal event and schedule a redraw via repaint(). Or do these problems only occur when the programmer tries to take control over paint events (as may be necessary in full-screen mode?)