rendering stops after first frame

[joshua]

Hi y'all!

After developing some 2d-animation under mac os x, i tried to make it run with windows. It renders the first frame then it doesn't do anything, not even throw an exception.

Disappointed I tried if some of NeHe's demos work (lesson04 and lesson06), but neither did (no modification, of course). They all stop after the first frame being rendered.

Looks like display() is called just once,  what can I do?

My project has to be done ntil next week and there's still lots of work to do. I don't want to go back to Java2d, which was much too slow.

Thanks in advance

[turquoise3232]

Have you set an Animator Class that call the new displays periodically?

[joshua]

Yes, of course I have.

As I wrote I tried two JOGL-ports from NeHe's tutorials and the did not work either, so this does not seem to be a problem with my code only.

Games published by our own members! Check 'em out!

[turquoise3232]

Yes, sorry i haven't  read well...
Does the background becomes gray....

[GKW]

If you are using the latest binaries try -DATI_WORKAROUND=false at the command line.

[joshua]

No, it renders the first frame - which looks as expected - and then just stops being called (I put a System.out.println(frame); into my display() method, it just gives a single "1")

I've read somewhere, one should add the glCanvas to the Frame after the call to setVisible(). Now the screen gets white, when I start my program.

I also read that it might help passing -Dsun.java2d.noddraw=true to the VM, which did not change anything at all.

[Ken Russell]

Try hitting Ctrl-Break on the command line after the first frame renders and see where the program is executing. If you can boil down your program into a small test case please file an Issue on the JOGL web page and attach a test case.

[joshua]

If you are using the latest binaries try -DATI_WORKAROUND=false at the command line.

YEAH, YEAH, YEAH!

That did it, thanks a very lot!

Where do I find hints like taht without annoying people around here? I searched the board, google, nearly all sites I found about JOGL, but that flag's new to me.

Have a nice day ... (I do now)

[Bombadil]

The problem could be related do what I've seen on another PC: just the 1st frame has been rendered.

Some time ago I've opened a thread for it: Radeon 9800 XL experiences?

[Bombadil]

I've just downloaded JOGL 1.1 beta 04 (July 16, 2004). A small app using JOGL directly (*) works on my ATI 9600pro, however my Xith application using JOGL doesn't: it doesn't even render the 1st frame anymore, just does nothing - still it doesn't hang, but the Canvas isn't being updated.
Looks similar to the effect the original poster observed (except that I don't even get the 1st frame rendered).

When I use the -DATI_WORKAROUND=false switch the Xith application works.

I'll also ask in the Xith forum, maybe some people know more.


(*) It doesn't use the Animator class but a time controlled direct call to glCanvas_object.display()

Games published by our own members! Check 'em out!

[Ken Russell]

Can you please file an issue on this topic on the JOGL web page? Please include the thread dump (Ctrl-Break on the command line, on Windows, or Ctrl-\ or SIGQUIT on Unix) once the application appears to hang. The ATI_WORKAROUND code should (obviously) not have this kind of effect, but only make the system more stable by forcing all rendering operations onto the AWT event queue thread. This hanging behavior didn't appear on any of the machines (ATI or NVidia) I originally tested the workaround code on.

[Bombadil]

Can you please file an issue on this topic on the JOGL web page? Please include the thread dump

Yes, filed as issue #98.

I've seen the hang for the Xith demos as well. It's not the very latest Xith version but I don't think they changed anything at the rendering loop.

Strangly enough my direct Jogl app doesn't hang here on the Radeon 9600, but it did so on a Radeon 9800 XL with the Jogl version prior to the latest...

I still think Ati isn't doing a good job with OpenGL drivers. Even though Ati's drivers have improved, I still think John Carmack's statement is correct, which he did over two years ago:

Nvidia's OpenGL drivers are my "gold standard", and it has been quite a while since I have had to report a problem to them, and even their brand new extensions work as documented the first time I try them. When I have a problem on an Nvidia, I assume that it is my fault. With anyone else's drivers, I assume it is their fault. This has turned out correct almost all the time.

Sigh. Unfortunately not a big help for us poor Ati users.

[Ken Russell]

I updated Issue 98 with a comment indicating that I can't see an obvious deadlock in the thread dump and requesting some more information. Hopefully with that we can get to the bottom of these problems.

[Bombadil]

I updated Issue 98 with a comment indicating that I can't see an obvious deadlock in the thread dump and requesting some more information. Hopefully with that we can get to the bottom of these problems.

I'll have to ask some Xith experts first on how to do this. As soon I find out more, I'll report it here (and on the Jogl issue tracker).

[Caoimhin]

I can get any jogl app to hang at the first frame without the ATI_WORKAROUND flag with this ATI Rage 128 Pro.  Is there any data I can collect for you?

[Ken Russell]

Can you run the Gears demo, wait for it to hang, and then hit Ctrl-Break and attach the thread dump to Issue 98?

[Caoimhin]

Ok, I've attached a threaddump text file to issue 98.

[Ken Russell]

Looking at the dump it looks like there is no deadlock. Could you put a println in the Gears demo's display() routine and see whether it is actually running the rendering loop?

[Caoimhin]

Just to be sure you have a clear picture of the the problem, we get the first frame, but then nothing after that.  It's more like rendering a still image.  The gears are displayed, but there's no animation.

The frame also does not process any repaint notifications.  If I partically cover the window and then bring it to the foregound, I simply get a white rect where the window was obscured.



Here is the complete output from the program.  I added the two Entering/Leaving lines within the display() method.

CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
Using ATI workaround of dispatching display() on event thread
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RAGE 128 Pro Ultra x86/SSE2
GL_VERSION: 1.2.1716 WinXP Release

glLoadTransposeMatrixfARB() supported: true
Entering display()
Leaving display()

[Bombadil]

Just to be sure you have a clear picture of the the problem, we get the first frame, but then nothing after that.

I too can confirm this is exactly what I see with my ATI 9600pro and the Gears demo, Vertex Program Warp demo, etc, with Jogl v1.1 beta 04, Catalyst 4.7 and a newly booted PC.

When I set the -DATI_WORKAROUND switch to false, the Gears demo runs OK sometimes, while sometimes it produces a VM crash dump then.
After some VM crashes the demo sometimes runs OK no matter of the Ati_Workaround switch. Maybe once the Ati OpenGL driver is in a strange state, it works randomly...
If I find out how to attach a file to the Jogl issue tracker's #98 issue, I could post the VM dump file.

It's a pity there's so much trouble with ATI's OpenGL drivers. Not only does this lead to very unstable Jogl-Java applications, but also it brings a bad light on OpenGL and Java apps/programmers when you try to show them to non Java people. I know it's not the fault of the Jogl developers and community and OpenGL. :-(
Thanks for the effort you Jogl developers and community people put into solving these issues.

[Caoimhin]

Yes, I also get the occasional VM crashes.  And the likelyhood that I'll crash on startup seems to increase as I run the app over and over.

[z.e.r.o]

I can confirm the crash on repeately runs of the jogl application, with or without ATI workarounds enabled.

I tried to run JOGL on j2 5.0 b3 and it crashes almost everytime. In 1.4.2 the crashes are sporadic but more common if you try to run the app two times straight with a short dealy between them.

The behaviour cannot be reproduced everytime I try to crash it

[keving]

Hi

FWIW, I have just tried an earlier GL4Java version of the www.digiturf.com "enhanced" race viewer on an IBM thinkpad with ATI Mobility Radeon 7500 and it too stops after the first frame, with VM crash etc., just like the JOGL version. This is with the latest drivers from IBM.

Looks like this problem is not limited to JOGL?

Kevin

[princec]

The drivers are well behind the latest ATI ones unfortunately. Expect all sorts of trouble.

Cas

[Ken Russell]

Here is the complete output from the program.  I added the two Entering/Leaving lines within the display() method.

CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
Using ATI workaround of dispatching display() on event thread
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RAGE 128 Pro Ultra x86/SSE2
GL_VERSION: 1.2.1716 WinXP Release

glLoadTransposeMatrixfARB() supported: true
Entering display()
Leaving display()

Thanks. This is helpful but I still don't know what could be happening. None of the calls being made in the stack trace you attached to the bug report should be blocking calls; the EventQueue thread should complete its notifyAll() and the Animator thread should resume after that. Could you take a few more thread dumps and see whether all of the threads are in the same state every time? Also, there aren't any exceptions being thrown?

[Ken Russell]

FWIW, I have just tried an earlier GL4Java version of the www.digiturf.com "enhanced" race viewer on an IBM thinkpad with ATI Mobility Radeon 7500 and it too stops after the first frame, with VM crash etc., just like the JOGL version. This is with the latest drivers from IBM.

Looks like this problem is not limited to JOGL?

No, I don't think it is. I was able to reproduce the reshape / corruption bugs people reported against JOGL with GL4Java. However, the new ATI_WORKAROUND code addressed the issue on the machines I had available to test with.

[Ken Russell]

I tried running the Gears demo on a Windows 98 machine with an ATI Rage Pro and probably old drivers and the demo came up OK, but the VM crashed on the first resize regardless of whether the ATI_WORKAROUND property was set to true or false. Visual C++ wasn't available to try to debug the issue further.

I'll try to run some tests with a more recent OS and drivers.

[Caoimhin]

I tried running the Gears demo on a Windows 98 machine with an ATI Rage Pro and probably old drivers and the demo came up OK, but the VM crashed on the first resize regardless of whether the ATI_WORKAROUND property was set to true or false. Visual C++ wasn't available to try to debug the issue further.

I'll try to run some tests with a more recent OS and drivers.

For reference, DxDiag reports this about the display on this machine:

------------------
System Information
------------------
Time of this report: 7/27/2004, 09:09:13
      Machine name: KDULING-PC
  Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 1 (2600.xpsp2.030422-1633)
          Language: English (Regional Setting: English)
System Manufacturer: Dell Computer Corporation
      System Model: OptiPlex GX240              
              BIOS: Default System BIOS
         Processor: Intel(R) Pentium(R) 4 CPU 2.20GHz
            Memory: 512MB RAM
         Page File: 281MB used, 968MB available
       Windows Dir: C:\WINDOWS
   DirectX Version: DirectX 9.0b (4.09.0000.0902)
DX Setup Parameters: Not found
    DxDiag Version: 5.03.0001.0902 32bit Unicode

---------------
Display Devices
---------------
       Card name: 16MB ATI Rage 128 Ultra
    Manufacturer: ATI Technologies Inc.
       Chip type: RAGE128 PRO II, (AGP 4X/PCI)
        DAC type: Internal DAC (350Mhz)
      Device Key: Enum\PCI\VEN_1002&DEV_5446&SUBSYS_04081002&REV_00
  Display Memory: 16.0 MB
    Current Mode: 1600 x 1200 (32 bit) (85Hz)
         Monitor: Plug and Play Monitor
 Monitor Max Res: 1600,1200
     Driver Name: ati2dvaa.dll
  Driver Version: 6.13.0010.5004 (English)
     DDI Version: 8
Driver Attributes: Final Retail
Driver Date/Size: 1/11/2002 00:23:06, 318080 bytes
     WHQL Logo'd: n/a
 WHQL Date Stamp: n/a
             VDD: n/a
        Mini VDD: ati2mtaa.sys
   Mini VDD Date: 1/11/2002 00:22:10, 295168 bytes
Device Identifier: {D7B71EE2-1706-11CF-3E60-0224A2C2CB35}
       Vendor ID: 0x1002
       Device ID: 0x5446
       SubSys ID: 0x04081002
     Revision ID: 0x0000
     Revision ID: 0x0000
     Video Accel: ModeMPEG2_C ModeMPEG2_D
Deinterlace Caps: n/a
        Registry: OK
    DDraw Status: Enabled
      D3D Status: Enabled
      AGP Status: Enabled

[Caoimhin]

Thanks. This is helpful but I still don't know what could be happening. None of the calls being made in the stack trace you attached to the bug report should be blocking calls; the EventQueue thread should complete its notifyAll() and the Animator thread should resume after that. Could you take a few more thread dumps and see whether all of the threads are in the same state every time? Also, there aren't any exceptions being thrown?

This is a single run with two thread dumps taken about 20 seconds apart.

> diff dump1.txt dump2.txt
5c5
< "Thread-1" prio=5 tid=0x02db6708 nid=0x1ca0 in Object.wait() [465f000..465fd8c]
---
> "Thread-1" prio=5 tid=0x02db6708 nid=0x1ca0 runnable [465f000..465fd8c]
9c9
<       - locked <0x10010f20> (a java.awt.EventQueue$1AWTInvocationLock)
---
>       - locked <0x10081b58> (a java.awt.EventQueue$1AWTInvocationLock)

[Ken Russell]

I still don't see what is happening. The AWT event queue thread should be doing a notifyAll() on the invocation lock which should wake up the Animator thread. notifyAll() is not a blocking operation.

If I could run on your machine, I would instrument the JOGL code in GLCanvas.displayImpl() and see whether displayImpl() is getting called more than once while the screen remains white, and whether the code in the Runnable that is being passed over to the AWT event queue thread is being run.