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. |
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
|
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. 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 |
Free forum by Nabble | Edit this page |