How I fixed a "JOGL loads extremely slowly" problem

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How I fixed a "JOGL loads extremely slowly" problem

Quizzical
Two days, I updated to the latest version of JOGL for the first time in a long time.  I also updated Java, Eclipse, and my video drivers.  Whereas formerly a game that I had been programming would take a few seconds to load, now it suddenly took more than a minute.  At first, I thought the program was hanging entirely, but after letting it run for long enough, I found that it usually would load, but typically took more than a minute.  Some timing statements tracked down the problem to the GLProfile.get(something) method that used to take about a second suddenly taking over a minute.

Today, I figured out how to fix the problem, so I figured I'd share in case someone else was having the same problem.  The fix is pretty simple.  Make the first line of code in your main method:

GLProfile.initSingleton();

That takes a second or so to run, but once it's done, everything else ran at the normal speed.

The reason I post this is that I hate it when I have some weird programming bug, do a Google search, find someone asking for help exactly the same problem, and then find a reply saying something to the effect of "I fixed it", without saying what the fix is.  So if someone else is having the same problem, this might help fix it.

But I suspect that I know why most people wouldn't have this problem.  My main method is not in the rendering thread class that implements GLEventListener, as it typically would be for a simple program.  Rather, I have both OpenGL 3.3 and OpenGL 4.2 versions of my code.  They have some code in common, but a lot of the code is different, in part because most of the vertex data and many shaders are different.  (The reason for the difference is that tessellation can do some really cool stuff, but requires OpenGL 4.0 or later.)  My main method has to check settings to figure out which version the user wants, then kicks off the appropriate thread that handles the OpenGL stuff more directly.

I'm not sure if it would be appropriate to make some changes to JOGL itself to make it not matter whether initSingleton() (which is called by GLProfile.get(whatever)) needs to be in the main method.  Regardless, calling it in the first line of code of the main method fixes the problem for me.
Reply | Threaded
Open this post in threaded view
|

Re: How I fixed a "JOGL loads extremely slowly" problem

gouessej
Administrator
Hi

My main method is not in the rendering thread class that implements GLEventListener too but I don't need to call GLProfile.initSingleton() and I don't reproduce your problem. Please provide much more information on your configuration.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: How I fixed a "JOGL loads extremely slowly" problem

Sven Gothel
Administrator
In reply to this post by Quizzical
On 09/20/2014 06:02 PM, Quizzical [via jogamp] wrote:

<snip/>

> Today, I figured out how to fix the problem, so I figured I'd share in case
> someone else was having the same problem.  The fix is pretty simple.  

Thank you!

> Make the first line of code in your main method:
>
> GLProfile.initSingleton();
>
> That takes a second or so to run, but once it's done, everything else ran at
> the normal speed.
>

<snip/>

>
> But I suspect that I know why most people wouldn't have this problem.  My main
> method is not in the rendering thread class that implements GLEventListener,
> as it typically would be for a simple program.  Rather, I have both OpenGL 3.3
> and OpenGL 4.2 versions of my code.  They have some code in common, but a lot
> of the code is different, in part because most of the vertex data and many
> shaders are different.  (The reason for the difference is that tessellation
> can do some really cool stuff, but requires OpenGL 4.0 or later.)  My main
> method has to check settings to figure out which version the user wants, then
> kicks off the appropriate thread that handles the OpenGL stuff more directly.
>
> I'm not sure if it would be appropriate to make some changes to JOGL itself to
> make it not matter whether initSingleton() (which is called by
> GLProfile.get(whatever)) needs to be in the main method.  Regardless, calling
> it in the first line of code of the main method fixes the problem for me.
This indeed is very interesting!

Yes, GLProfile.initSingleton() is a blocking operation
spawns the 'shared resource' thread to probe all available profiles.

As you indicated, this shall only take a few milliseconds.

In your case and considering some of my experiences:
  - maybe the initial GLProfile.initSingleton() call
    comes from an 'unlucky thread'.
    I.e. somehow this thread is shortly pre-empted
    and takes too much time to continue ?

  - Our post locking notify() does not wake up the other blocked threads
    properly -> a bug on our behalf (?)

It would be great to have a unit test reproducing this behavior,
maybe you can modify one of the below test ?

I have modified the following tests,
so each is testing implicit and concurrent GLProfile.initSingleton() calls:
  com.jogamp.opengl.test.junit.jogl.acore.TestInitConcurrent01NEWT
  com.jogamp.opengl.test.junit.jogl.acore.TestInitConcurrent02NEWT

see <http://jogamp.org/git/?p=jogl.git;a=commit;h=cecc00efb3c47928dd8080577645b2d8633fa159>

2 other tests are also available:
  com.jogamp.opengl.test.junit.jogl.acore.TestShutdownCompleteNEWT
  com.jogamp.opengl.test.junit.jogl.acore.TestShutdownCompleteAWT

~Sven



signature.asc (828 bytes) Download Attachment