Re: How I fixed a "JOGL loads extremely slowly" problem
Posted by Sven Gothel on
URL: https://forum.jogamp.org/How-I-fixed-a-JOGL-loads-extremely-slowly-problem-tp4033180p4033184.html
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
URL: https://forum.jogamp.org/How-I-fixed-a-JOGL-loads-extremely-slowly-problem-tp4033180p4033184.html
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.
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) | Free forum by Nabble | Edit this page |