This is a problem I've encountered with JOGL for the past year or two. It seems that any JOGL based program I've ever written will begin to run slowly after my machine has been up for a few days.
I've been using the below program to help me diagnose the problem:
Given how long it takes to reproduce this bug, I've been unable to create a useable test case. My best guess is "Use a Windows 7 machine to develop software with for a few days and then try and run a program which uses JOGL". I don't know if it's Java, Firefox, Flash, Windows sleep mode or maybe something else that is causing this. I've not yet gotten consistent results. However, when I first boot the machine, the above program will run so quickly the numbers it prints will blur on the screen. As time passes, the above program is more likely to have a slow run, where the numbers flash by at about 1 fps. After a few days, running the program is very likely to produce a slow run, although the occasional fast run will still occur.
Created attachment 317 [details]
Heap dump from a slow run
Created attachment 318 [details]
Thread dump of slow run
Created attachment 319 [details]
Memory profile of slow run
Created attachment 320 [details]
Cpu profile of a slow run
Created attachment 321 [details]
Output generated when run with JOGL debug flags
Created attachment 322 [details]
Created attachment 323 [details]
test debug log
Please use Buffers.newDirect*Buffer() to create your buffers. Do you reproduce this problem with GLCanvas?
The problem occurs with both GLJPanel and GLCanvas. I'm allocating the buffers the way they are because I'm trying to create a cross platform library and com.jogamp.common.nio.Buffers locks me into Jogamp. However, I switched to Buffers.* for a few runs, and there is no difference.
(In reply to comment #9)
> The problem occurs with both GLJPanel and GLCanvas. I'm allocating the buffers
> the way they are because I'm trying to create a cross platform library and
> com.jogamp.common.nio.Buffers locks me into Jogamp. However, I switched to
> Buffers.* for a few runs, and there is no difference.
Does this problem occur with GLWindow too? I would like to know whether the problem could come from JAWT.
(In reply to comment #3)
> Created attachment 319 [details]
> Memory profile of slow run
Why are there some traces of RMI calls?
(In reply to comment #4)
> Created attachment 320 [details]
> Cpu profile of a slow run
sun.java2d.d3d.D3DScreenUpdateManager should not be used. Can you disable d3d please?
I tried to create a panel that inherits from GLWindow, but could not because it has no public constructors. How would I create a GLWindow?
The RMI calls might be something the NetBeans editor is creating. I tried to run my own version from the command line using just Ant and Cygwin, but am running into errors. Would you know why the ant task cannot seem to find gluegen-rt-natives-windows-i586.jar? It should be in the classpath.
$ ant run-cmd
[java] java.io.FileNotFoundException: C:\dev\java.net\raven\trunk\proj\FBOTest\dist\lib\gluegen-rt-natives-windows-i586.jar (The system cannot find the file specified)
[java] at java.util.zip.ZipFile.open(Native Method)
[java] at java.util.zip.ZipFile.<init>(ZipFile.java:214)
Created attachment 324 [details]
profile of a fast run
I've done some more testing. This morning, FBOTest was mysteriously giving me fast runs (first time I've ever seen it jump from doing slow runs one day to doing all fast runs the next). Anyhow, I disabled d3d and did more profiling. I've attached the results.
Created attachment 325 [details]
Profile of a slow run
I was able to observe a slow run after making the changes you suggested. Here are my profiling results.
Created attachment 326 [details]
A better slow run
Profiled another slow run. This time, I remembered to do it from the command line, so there are no RMI calls.
Created attachment 327 [details]
Correct slow run this time
Accidentally uploaded the same slow run twice. Here's the actual second one.
(In reply to comment #18)
> Created attachment 327 [details]
> Correct slow run this time
> Accidentally uploaded the same slow run twice. Here's the actual second one.
I verified this attachment of yours and opened it in 'jvisualvm'.
The containing cpu dump 'snapshot-1329328196165.nps'
clearly shows that all the 'time' is being spend in your FBOTestPanel:
The memory dump does not show any irregularities, i.e. it's normal / not conclusive.
The cpu dump shows an overall of 55357 ms duration of the AWT EDT thread,
where display is being invoked 144 times -> 384ms / frame -> 2.6 fps.
You call 'glVertex2d(double, double)' 161280 times within 29175ms, hence 180 ms / call.
Also.. it's 1120 times per frame.
IMHO the throttling happens due to the native OpenGL implementation,
which ofc emulates the fixed function pipeline while creating an internal VBO
and shader code. See <http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html>.
JOGL doesn't do anything here and is not the culprit.
To simple improve performance and reliability I would just drop immediate mode
(begin, vertex2d, end), and use a VBO object.
Closing this bug report, since IMHO we are not the culprit.
If you have proof otherwise, please reopen it.
(Sort of unrelated to the performance issue:)
In your source code <http://java.net/projects/raven/sources/svn/show/trunk/proj/FBOTest?rev=63>,
I see you derive from the GLAutoDrawable GLJPanel directly, which is of course not advised!
There you directly instantiate an Animator in your specialization .. etc.
If you choose to use the GLEventListener/GLAutoDrawable managed code path we offer,
why not using it (properly) ? If you desire not to follow the managed code path, you can also
utilize the GLDrawableFactory directly - just a hint.
Well, I still don't see how this problem was only occurring after extended use and in other programs that did not use immediate mode. However, the problem seems to have gone away with the version of JOGL I downloaded a few months ago, so it may have been related to another bug, or maybe to NetBeans. Thanks.
The GLAutoDrawable/JGLPanel setup I'm using is the best I could figure out from a demo JOGL program I came across. What's the proper way to set this up? Do you have a webpage describing this?