Multiple GLEventListeners, coordinate systems, and a JNI error

OpenGL Development JOGL Development
#1

Hello all. I’m an experienced programmer, though relativly new to OpenGL and JOGL, and new to this forum. I’ve gotten to the point where I can draw points, lines, triangles, etc, and have some level of comfortability doing so.

I have a scene to set up, with different types of objects added “on the fly”, with a main backdrop having some objects itself, and handling GLEventListener.init. Currently, I’m calling GLPanel.addGLEventListener for each object, and drawing on the GLEventListener.display. This produces irratic behaviour. What I mean by that is that sometimes it renders, and sometimes it doesn’t, although the main backdrop objects for the scene do consistently render. I have also tried keeping an ArrayList of objects added on the fly, and manually calling each objects display method at the end of the main backdrop’s GLEventListener.display, or even creating a new method, void draw(GL gl). I consistently get inconsitent behaviour.

Secondly, I see a lot of examples using gluOrtho2d to set up the type of coordinate system where there are four quandrants and negatives. Cartiesian I think I heard it refered to as. I’m setting it up to have 0,0 at the leftmost bottom of the screen. Is there a reason to do otherwise?

Lastly, I occasionaly see “ERROR: JDWP Unable to get JNI 1.2 environment, jvm->GetEnv() return code = -2” after my application exits on the eclipse console. Nothing else seems to disfuntion or be out of place, save for the above mentioned. Should this worry me?

I’m running on win xp, jdk 1.6.0. My display is a crappy run-of-the-mill onboard card. I can’t even get the manufacturer info for it from windows (go figure).

Thanks in advance for helping this noob.

#2

This sounds more like driver-level issues than anything. Do the JOGL demos work properly? Can you launch the Gears demo from within your IDE? Does the behavior change if you specify -Dsun.java2d.noddraw=true on the command line? Are you using the latest JOGL version? Have you tried using the GLCanvas rather than the GLJPanel?

It’s totally up to your application.

This sounds like a problem upon JVM teardown. Unless it’s getting in the way I wouldn’t worry about it.

#3

Yes.

[quote]Can you launch the Gears demo from within your IDE?
[/quote]
Yeah. I’m using Eclipse 3.1.

[quote]Does the behavior change if you specify -Dsun.java2d.noddraw=true on the command line?
[/quote]
Sadly, no. It gave me a glimmer of hope to try, but alas it doesn’t seem to change things.

[quote]Are you using the latest JOGL version?
[/quote]
I just downloaded the libs the other day. I have JSR-231 beta 02 build.

[quote]Have you tried using the GLCanvas rather than the GLJPanel?
[/quote]
No, but I have some swing integration stuff here too, so I was under the impression I should be using GLJPanel, not GLJCanvas.

Sweet. Thanks.

[quote]This sounds like a problem upon JVM teardown. Unless it’s getting in the way I wouldn’t worry about it.
[/quote]
Thanks again.

#4

Yeah. I’m using Eclipse 3.1.
[/quote]
Are there similar issues with the Gears demo?

Have you tried installing a DebugGL pipeline in your GLEventListener.init() method (see the Gears demo for an example)? That should quickly track down any OpenGL-related errors in your application.

You’ll get even better error reporting if you run with the current JOGL nightly build.

No, but I have some swing integration stuff here too, so I was under the impression I should be using GLJPanel, not GLJCanvas.
[/quote]
The only time you really absolutely need to use a GLJPanel to interoperate with Swing is if lightweight components can overlap your OpenGL widget, for example if it’s in a JInternalFrame. Otherwise you can follow the tips in the section of the JOGL User’s Guide on mixing heavyweight and lightweight components and you should be able to use the GLCanvas. I don’t know whether that could be causing your problems but it’s worth a try.

#5

I updated to the latest nightly build, and re-ran some demos launched from eclipse. I have not had any problem with any of the demos, including gears. I have had a DebugGL in there, but it hasn’t complained about anything that wasn’t immeditaly obvious. I have to be able to overlay swing components directly on the GLDrawable.

I can’t post the actual code here, but I made a true to app representation of the problem. I’d be forever (limit: 2 weeks) grateful if you or someone here could take a glance at it, or even possibly run it a few times.

http://cedar.tzo.com:1024/Triangulator.jar

should let you download it. I never figured out how to put a jar in the cp from another jar, let alone jni libs, so it’s not immediatly runnable, but contains the two source files that demonstrate this problem. Funny thing is, this stripped down version fails 1 in 10 times (roughly) whereas the slightly larger app fails 1 in 3 times (roughly). Am I doing something weird here?

Thanks

#6

The jar seems to be corrupt. Did you upload it in ASCII mode instead of binary?

#7

C:\Temp>curl http://cedar.tzo.com:1024/Triangulator.jar >Triangulator.jar && unzip -t Triangulator.jar
% Total % Received % Xferd Average Speed Time Curr.
Dload Upload Total Current Left Speed
100 1283k 100 1283k 0 0 165k 0 0:00:07 0:00:07 0:00:00 175k
Archive: Triangulator.jar
testing: META-INF/MANIFEST.MF OK
testing: Triangulator.jar OK
testing: com/tzo/cedar/examples/Triangulator$1.class OK
testing: com/tzo/cedar/examples/Triangulator.class OK
testing: com/tzo/cedar/examples/Triangulator.java OK
testing: com/tzo/cedar/examples/GreenTriangulator.class OK
testing: com/tzo/cedar/examples/GreenTriangulator.java OK
testing: .settings/org.eclipse.jdt.core.prefs OK
testing: .settings/org.eclipse.jdt.ui.prefs OK
testing: lib/jogl-natives-win32.jar OK
testing: lib/jogl.dll OK
testing: lib/jogl.jar OK
testing: lib/jogl_awt.dll OK
testing: lib/jogl_cg.dll OK
testing: lib/log4j-1.2.13.jar OK
No errors detected in compressed data of Triangulator.jar.

Seems to be fine for me. I extracted on the site: http://cedar.tzo.com:1024/Triangulator/ to make it browsable instead.

#8

How did you create this jar file? If you made it with the “jar” command, what JDK version (vendor included)? jar xvf chokes on this archive on my system though you’re right that unzip works.

#9

Regarding your test case: I ran it about 50 times with Mustang build 70 and didn’t see any problems. I am running however on a single-CPU machine. Are you running on a dual-CPU box? What is the failure mode when the test fails? Does only the “exit” button show up but not the OpenGL rendering?

Have you tried upgrading to the latest available set of drivers from your manufacturer?

I could imagine there being some potential race conditions in the setting up of fullscreen mode in your app. In particular you’re setting the full-screen window before the window is realized. I assume the JDK handles this but am not 100% sure. You might want to try posting in the Swing and AWT forum on javadesktop.org for some hints about the correct way to set up full-screen mode. You might also want to look at the full-screen demos in the jogl-demos workspace under demos/fullscreen/ though I’m not sure they’re any more correct. It would be good to know whether these demos also show the same sorts of problems on your setup.

#10

That jar was created by Eclipse’s Export… function. My test machine is a single cpu compaq 2.4GHz P4, win xp sp 2. I noticed the fullscreen thing too after I posted (I was kinda in a hurry), but the regular app doesn’t have that problem, and both produce the failure. The “failure” was that the swing button appeared, and the red triangle, but the green triangle showed up only 9 in 10 times.

Bad stuff man …

I thought maybe it was just my crappy on board unidentified card, so I brought an ATI Rage 128 (16MB) from home & installed. I updated with the drivers from ATI, and tried JGears:

Caused by: javax.media.opengl.GLException: Error releasing pbuffer device context: error code 0
	at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.destroy(WindowsPbufferGLDrawable.java:92)
	at com.sun.opengl.impl.GLPbufferImpl.destroy(GLPbufferImpl.java:176)
	at javax.media.opengl.GLJPanel.handleReshape(GLJPanel.java:636)
	at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:276)
	at demos.jgears.JGears.paintComponent(JGears.java:56)
	at javax.swing.JComponent.paint(JComponent.java:967)
	at javax.swing.JComponent.paintChildren(JComponent.java:804)
	at javax.swing.JComponent.paint(JComponent.java:976)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5072)
	at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:279)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1105)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5020)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4838)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:670)
	at com.sun.opengl.utils.Animator$1.run(Animator.java:302)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1320)
	at com.sun.opengl.utils.Animator.display(Animator.java:158)
	at com.sun.opengl.utils.Animator$MainLoop.run(Animator.java:181)
	at java.lang.Thread.run(Thread.java:626)

This repeats until I forcibly terminate the process. Is it just this crappy crappy computer I’m on or am I missing something? Tried with both nightly build and latest release.

#11

Sorry to say but the ATI Rage 128 is a pretty crappy card too with pretty crappy driver support. I’d really recommend you shell out the $40 or so for a low-end NVidia card. You should get a massive speedup as well as a big reliability improvement.

The exception backtrace above looks like it’s caused by bugs in ATI’s pbuffer support. Especially on the Rage 128 that doesn’t surprise me.

#12

Man … I suck. After swapping the video card for another ATI Radeon 7200 I revisited the fullscreen issue, and yes … that did seem to cause the problem. I am glad though, because I saw the horrors of the ATI Rage 128. I guess I just have to tell this company to require thier customers to use decent recent video cards? I hate to have to require any type of video card. I guess that’s just a pipe dream though, eh? Thanks a bunch for the help.

#13

I agree that it’s unfortunate to have to require a certain video card but the fact of the matter is that pbuffer support was pretty flaky on these older cards. The most well tested code path in JOGL and that which is supported on the majority of video cards is using the GLCanvas. The GLJPanel uses either pbuffers or software rendering; on older cards pbuffers aren’t robust and software rendering will probably be unacceptably slow and have poor feature support.

Glad you’ve isolated the problem to the fulscreen support; please post if there appears to be a problem in how JOGL is handling anything.