Hi all. I’ve placed a GLCanvas inside of a Frame, but I don’t seem to get any events anymore. Clicking on the window close widget does nothing (it doesn’t update and I can’t drag the window). This is on windows xp and using jogl 1.1b7. I also have a lot of trouble killing the app as it jumps to 100% cpu usage when I try to defocus it and use taskmanager to kill it.
I am on a ATI card, but trying -DATI_WORKAROUND=false didn’t help. I’m using an Animator.
Any ideas what i may be doing wrong?
Do any of the JOGL demos work?
Have you tried putting in a Thread.sleep(10) or similar at the bottom of your display() routine?
Are you using the latest ATI drivers?
Thanks for the quick reply.
The JOGL demos seem to behave the same way. I’m using the latest drivers that IBM offers. (I’m on a thinkpad with a FireGL 9000 and ATI doesn’t offer direct support)
I have tried adding a call to sleep, but that seems to do nothing. The eventQueue thread is blocked in pumpOneEventForHierarchy so no events are flowing.
I’ve tried all manner of setIgnoreRepaint, setNoAutoRedrawMode and noddraw. As well as adding GLCanvas only after the frame is visible. (I had problems with this with earlier versions of jogl.) Any other thoughts.
Have you tried not using the Animator, but instead just letting the GLCanvas repaint itself on demand?
Yes, Not animating does allow window events through… but I’m looking for animation. I did try setting up my own animator that would request a repaint, but that seemed to have the same problem. Even if I was only rendering a frame once every second or so.
The funny thing is, that the app goes wild and uses up 100% of my cpu. Even rendering on 1 fps.
It sounds like a driver bug where problems occur if the OpenGL context is accessed from more than one thread. I would have thought the ATI_WORKAROUND should help here by forcing all operations to be performed on the AWT thread, where the component is realized in the first place. If you specify -DATI_WORKAROUND=true does that change anything?
[quote]If you specify -DATI_WORKAROUND=true does that change anything?
[/quote]
Unfortunately no. Setting it to true, my frame and canvas never display.
Could you hit Ctrl-Break when that happens and post the output of the full thread dump?
This is while running the gears demo
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: MOBILITY FIRE GL 9000 DDR Pentium 4 (SSE2)
GL_VERSION: 1.3.4650
glLoadTransposeMatrixfARB() supported: true
Full thread dump Java HotSpot™ Client VM (1.5.0-b64 mixed mode):
“Thread-4” prio=5 tid=0x0af61e70 nid=0x39c runnable [0x0f85f000…0x0f85fb68]
at net.java.games.jogl.impl.windows.WGL.NativeEventLoop(Native Method)
at net.java.games.jogl.impl.windows.WindowsGLContextFactory$NativeWindowThread.run(WindowsGLContextFactory.java:272)
“DestroyJavaVM” prio=5 tid=0x00036c78 nid=0x974 waiting on condition [0x00000000…0x0007fae8]
“Thread-3” prio=5 tid=0x0afb31c0 nid=0x528 runnable [0x0f81f000…0x0f81fbe8]
at java.awt.EventQueue.postEvent(Unknown Source)
at java.awt.EventQueue.invokeAndWait(Unknown Source)
- locked <0x02b4bb20> (a java.awt.EventQueue$1AWTInvocationLock)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:203)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75)
at net.java.games.jogl.Animator$1.run(Animator.java:107)
at java.lang.Thread.run(Unknown Source)
“AWT-EventQueue-0” prio=7 tid=0x0af72b20 nid=0xc7c waiting for monitor entry [0x0f7df000…0x0f7dfc68]
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
- waiting to lock <0x02b4bb20> (a java.awt.EventQueue$1AWTInvocationLock)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
“AWT-Windows” daemon prio=7 tid=0x0af52790 nid=0x8a0 runnable [0x0b36f000…0x0b36fce8]
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
“AWT-Shutdown” prio=5 tid=0x0ac7cd60 nid=0xe28 in Object.wait() [0x0b32f000…0x0b32fd68]
at java.lang.Object.wait(Native Method)
- waiting on <0x030678a8> (a java.lang.Object)
at java.lang.Object.wait(Unknown Source)
at sun.awt.AWTAutoShutdown.run(Unknown Source)
- locked <0x030678a8> (a java.lang.Object)
at java.lang.Thread.run(Unknown Source)
“Java2D Disposer” daemon prio=10 tid=0x0af4d6c8 nid=0xddc in Object.wait() [0x0b2ef000…0x0b2ef9e8]
at java.lang.Object.wait(Native Method)
- waiting on <0x03067930> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x03067930> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at sun.java2d.Disposer.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
“Low Memory Detector” daemon prio=5 tid=0x00a91370 nid=0x84c runnable [0x00000000…0x00000000]
“CompilerThread0” daemon prio=10 tid=0x00a8ff48 nid=0xc88 waiting on condition [0x00000000…0x0abcf8c0]
“Signal Dispatcher” daemon prio=10 tid=0x00a8f2d0 nid=0xd28 waiting on condition [0x00000000…0x00000000]
“Finalizer” daemon prio=9 tid=0x00a86850 nid=0x828 in Object.wait() [0x0ab4f000…0x0ab4fc68]
at java.lang.Object.wait(Native Method)
- waiting on <0x02fda000> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x02fda000> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
“Reference Handler” daemon prio=10 tid=0x00a853c0 nid=0x9d4 in Object.wait() [0x0ab0f000…0x0ab0fce8]
at java.lang.Object.wait(Native Method)
- waiting on <0x02fda080> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Unknown Source)
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
- locked <0x02fda080> (a java.lang.ref.Reference$Lock)
“VM Thread” prio=10 tid=0x00a81278 nid=0xf88 runnable
“VM Periodic Task Thread” prio=10 tid=0x00aabd90 nid=0xd38 waiting on condition
I’ve tried this on my setup and don’t think there should be a deadlock there. Thread-3 should finish the postEvent call and wait on the AWT Invocation Lock, which should later be acquired by the AWT-EventQueue-0 thread. I think the thread snapshot below is probably changing over time as opposed to being deadlocked. My guess is that a driver problem is preventing the window from being realized and the OpenGL context created, so the Animator is spinning in a tight loop waiting for the window to be created.
Well, the window has already been created and the animator is animating and painting to the screen, but I’m sure you’re right that it is a driver problem.
I installed the radeon drivers via driver mod and a rename of atiglxx.dll to atiglgl.dll. Its slower, but the events are coming through again. These mobile gl drivers are so flakey. (Had no luck with the unified gl drivers) Guess its time to get a laptop with a real video chipset.