JOGL slows down after extended use

I've noticed that JOGl will often become very slow if my machine had been on for an extended period of time.  This problem has occurred across pretty much every JOGL program I've ever used or written - even very simple programs that just render simple geometry to the screen without too much else going on.  If I reboot my machine, JOGL will revert back to drawing quickly.  However, if I leave my machine on too long, JOGL will become quite slow once again.

This happens for both GLJPanels and GLCanvases.  I will occasionally get a fast run once amongst the slow runs, but it is pretty rare.  There are no obvious error messages - JOGL just slows down.

It would be nice to know what is happening and if there is some way to get around it.  I don't want to have to tell clients that every time they notice their program is running slowly that they need to reboot their machine.

Hi

Use a profiler to find what is wrong. However, I know at least one person who used JOGL for an application displaying 3D models on big screens for hours and he has never had such problems. JOGL isn't a very high level API, it contains a very few high level features. I fixed a problem impacting the memory footprint when displaying text but JOGL cannot be accused of everything... GLJPanel is known to be memory intensive and in some cases, I (hardly) succeeded in reproducing the same behavior with GLCanvas when disabling the auto swap buffer mode.

What sort of profiler should I use?  The problem isn't the Java program itself.  I've written a very simple JOGL test program that just redraws a texture to the screen over and over again and which runs very quickly if my machine is freshly booted but very slowly if it has been up for a day or more.

Is there some way to dump the JOGL state?  Does JOGL fall back to buffering or software emulation in certain situations, and if so, is there a way to detect this?

JVisualVM should be enough. Have a look at JProfiler or YourKit if you prefer using proprietary softwares.

Ok, you have a test case, please publish it. Maybe there is a tiny thing causing your problem.

JOGL does not contain a software renderer but it can work with a software implementation of OpenGL. Look at the string of the GL renderer.

Some years ago, I noticed that JOGL has a kind of state stack, I don't remember how it works. Nifty GUI has its own state stack too and it was particularly memory intensive. I have to look at this...

Please look at these classes:
https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/GLBufferStateTracker.java
https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/GLStateTracker.java

Tell me whether instances of these classes are created "under the hood" when you're not in debug. If it is the case, please write a bug report and ask for an enhancement. In my humble opinion, these trackers should be used only in debug mode, not in production :s

On 02/02/2012 07:02 PM, gouessej [via jogamp] wrote: Our state tracker are essential for security measures.

GLBufferStateTracker identifies the bound buffer object.

  - It validates it's access state (VBO enabled/disable)
    e.g. for VertexAttribPointer calls when using VBO or not.

  - It also tracks the buffer size for the actual MapBuffer call
    which is required and predetermined by BufferData.
    Another HashMap of type MemoryObject then stores
    the adress, size and the actual NIO memory object to be reused.
    the latter allows covering multiple memory 'windows' in one
    and reducing the number of costly NIO objects and calls.

  - Above state objects are bound to the GL/GLContext instance
    and 'freed' with the destruction of the GL/GLContext object.
    I currently fail to see further side effects.

  - The GL spec does not allow us to free the resources at an
    earlier point. UnmapBuffer could be used though, but a usual
    application may like to reuse the [NIO] buffer object.
    We may could introduce an addition entry point
    where the user explicitly releases memory bound objects.
    Currently this would be the GLContext destruction.

  - Resume: This tracker is essential and more a boost to JOGL's
    performance than slowing down baggage. Of course, if you can
    give use cases w/ test code to reproduce showing
    inefficiencies or even bugs, we shall fix it.

GLStateTracker is a simple GLContext bound int/int hash map
providing very fast access to client sides pixel states (16 values).
It is very unlikely this tracker slows down anything or even
causes a memory leak.

In my humble opinion, these trackers should be used only
> in debug mode, not in production :s

see above, both, especially the former is an essential core component.
W/o it we could not implement the GL functionality [properly].

~Sven

On 02/02/2012 06:07 PM, kitfox [via jogamp] wrote: As Julien mentioned, JVisualVM is a great tool.

Please provide a recipe to reproduce your experience.
Best case would be using on of our unit tests,
incl. some instructions like platform, etc (see Wiki/FAQ/Bugreport).
If our unit test are not able to reproduce the behavior,
pls send us your little test case (BSD license).

~Sven

Will Apache 2 do? :)

You can find the test case in this project;
http://java.net/projects/raven/sources/svn/show/trunk/proj/FBOTest

It's called FBO test, but all the FBO stuff if if(false)'d out.

Unfortunately, I cannot provide a test case that will always reproduce the problem, since it seems that I need to have had my computer running for at least a day before it occurs.  However, when the problem is occurring, the above program will run (on my machine at least) at about 1 fps.

I'm running this on Windows 7 Ultimate and have a NVidia Quadro video card.  I've experienced it with JDKs 6 and 7 and with JSR 231, including the latest.

Thanks for pointing out JvisualVM.  I'd always used the profiler integrated into NetBeans before.  The next time the problem occurs, I'll see if the profiler turns up anything interesting.

On 02/03/2012 06:33 AM, kitfox [via jogamp] wrote: So will it reproduce the behavior within 1 day, always ?

>
> I'm running this on Windows 7 Ultimate and have a NVidia Quadro video card.
> I've experienced it with JDKs 6 and 7 and with JSR 231, including the
> latest.

Please follow Bugreport instructions as described in the post
<http://forum.jogamp.org/Problem-with-GLProfile-and-jogl2-rc2-td3447491.html#a3447546>

This is required to recreate your environment as close as possible.

>
> Thanks for pointing out JvisualVM.  I'd always used the profiler integrated
> into NetBeans before.  The next time the problem occurs, I'll see if the
> profiler turns up anything interesting.

Sounds great.

~Sven

I was finally able to create a bug for this:

https://jogamp.org/bugzilla/show_bug.cgi?id=554

I've uploaded as much info as I can.  Unfortunately, I haven't yet come up with a reliable test case.  Please let me know if there is any more info I can provide.

On 02/07/2012 05:27 AM, kitfox [via jogamp] wrote:
>  as much info as I can.  Unfortunately, I haven't yet come up
> with a reliable test case.  Please let me know

Thank you - your data is very much appreciated.

I will read through it and cont. the discussion in the bugreport,
<https://jogamp.org/bugzilla/show_bug.cgi?id=554>.

~Sven

I will contribute that I have a Swing/JOGL app where the OpenGL piece is a fairly complex animation: about 40,000 triangles, FBOs shadow buffers, simple texture mapping, and a sky box.  I've deliberately run it for 48 hours to see what would happen and it works fine. The VM working set size stayed the same.  

I did take pains not to generate much garbage in the inner loop.  Maybe your application has some kind of pathological heap fragmentation problem.  Just a guess.  But the profiler ought to reveal this.