Bug 554

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]
test log

Created attachment 323 [details]
test debug log

Hi

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
Buildfile: C:\dev\java.net\raven\trunk\proj\FBOTest\build.xml

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)



    <target name="run-cmd">
        <java classname="com.kitfox.fbotest.FBOTestFrame"
            fork="true"
            failonerror="true">
            <arg value="-ea"/>
            <arg value="-Xms32m"/>
            <arg value="-Xmx1024m"/>
            <arg value="-Djava.library.path=../../lib/jogamp/lib"/>
            
            <classpath>
                <pathelement location="dist/FBOTest.jar"/>
                <fileset dir="../../lib/jogamp/jar">
                    <include name="**/*.jar"/>
                </fileset>
            </classpath>
            
               
        </java>
    </target>

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:
  glVertex2d(double, double)

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?