Re: Hangs and Freezes (JOGL 2.2.4 & 2.3.0, MacOS X Yosemite, JDK 6, 7 & 8, SWT 3.8.2 & 4.4.2)
Posted by Sven Gothel on Mar 27, 2015; 11:29am
URL: https://forum.jogamp.org/Hangs-and-Freezes-JOGL-2-2-4-2-3-0-MacOS-X-Yosemite-JDK-6-7-8-SWT-3-8-2-4-4-2-tp4034199p4034203.html
On 03/27/2015 03:29 AM, Alexis Drogoul [via jogamp] wrote:
> Hi all,
>
Thank you for your elaborate bug report.
>
> Since JOGL has made tremendous progresses in supporting the SWT environment,
> we then decided to try out a pure SWT-based view for rendering OpenGL
> displays. I derived an "SWT" view based on the JOGL SWT GLCanvas, and tested
> the following combinations (only on MacOS X Yosemite, but we anyway need to
> have GAMA working on the 3 environments, on a 2011 17" MacBook Pro):
I still have to update and test for 'MacOS X Yosemite' in general.
It should not cause issues .. but hey, they do change things
under the hood quite often.
>
> - JDK 1.6 (the latest from Apple), JOGL 2.2.4 & 2.3, SWT 3.8.2.
> - JDK 1.7u76 (the latest 1.7 from Oracle), JOGL 2.2.4 & 2.3, SWT 3.8.2.
> - JDK 1.8u25 (the latest 1.8 from Oracle), JOGL 2.2.4 & 2.4, SWT 3.8.2
> - + all the above with a mixture of Eclipse 3.8.2 & SWT 4.4.2 (the latest from
> Eclipse).
>
> Not all combinations worked flawlessly, but they did at least display
> something, which was already great news (no more fiddling with AWT/SWT inter
> threading issues !). However, they *all* showed the exact same problem, which
> is the main reason why I decided to write this (long) message:
>
> 1) The initialization of OpenGL is slow. The UI is blocked something like 1 or
> 2 seconds, while it is much faster using the AWT based views. I dont
> understand why, as this initialization has normally nothing to do with AWT or
> SWT. One reason could be that GLProfile.initSingeton() is called as soon as we
> open an OpenGL display, and maybe it's blocking the SWT thread and not the AWT
> one. I did not investigate more, and I could benchmark this, probably, by
> explicitly calling initSingleton() in a different thread, but this issue is
> not a priority right now.Our unit test cases show that JOGL initialization is fast.
As Julien suggested .. maybe perform it outside of SWT upfront,
maybe some blocking occurs and SWT waits a bit longer.
>
> 2) Closing a view (either by hand or programmatically, when switching to a
> different model or simulation or relaunching a simulation) blocks the UI for 5
> to 10 seconds, with the closing OpenGL viewpart being emptied, then shown
> during this period, until it is closed and another one is opened. The logs
> show in all cases the exact same messages: "java.lang.RuntimeException: Waited
> 5000ms for: …" after a call to lockSurface() by the animator thread + a stack
> trace corresponding to the various dispose() calls (from the ViewPane to the
> GLCanvas). I've tried to stop the animator first, do some preliminary
> dispose() of various components, destroy the context, etc. with no luck.
> Disposing a view containing a JOGL SWT GLCanvas always hangs (and this is a
> pity, since the view works quite well…). I just noticed that this behavior
> does not happen if we simply open a view, obtain the first displaying of the
> model (the animator is anyway running behind), do not run the simulation (i.e.
> no wiping, no replacement of the displayed objects occur) and then close it.
> As if having some "contents" in the view would prevent the view from closing.
>
> 3) Closing the application freezes it if an OpenGL part is still open. The
> same message is displayed, but then nothing happens and I have to force-quit it.
>
> Pretty frustrating as I was quite close to the goal ! Now, I dont expect the
> members of the forum to magically solve this problem as it is clearly not a
> proper issue report. GAMA is a complex platform and it is perfectly possible
> that some of our design choices are the causes of this disappointing behavior.
>
> Instead, I would like to have advices on how to test this progressively. In
> the light of what I have exposed, what kind of repeatable benchmark should I
> try to run to eliminate the different causes of this behavior. Are there some
> available in the test units of JOGL ? A simple setup with the JOGL SWT
> GLCanvas that I could try and then progressively complexify by myself ?We do have SWT unit tests, of course.
Please check the jogl git repo.
Indeed it would be great, if you could extract a smallest possible
unit test for your (pure) SWT issues.
>
> Also, does this report make sense for other users/developers of JOGL ?
SWT is not my personal priority, however - there are users.
Hence .. it makes sense.
> Sometimes, simply mentioning a similar problem can shed a light on a part of
> the software I hadn't thought about before.
>
> Advices on how to proceed to obtain a working SWT-based OpenGL view are
> however what I expect the most, and I thank you in advance for your comment !
IMHO:
- Check out bugzilla database, whether an already existing SWT bug exists
and reply to it - or -
- Create a new bug entry ..
- Add unit tests via git repo ..
- We should have a 'most important SWT' bug group
(a new bug entry, all those most desired bugs will block)
The real problem is: Who will fix the bug?
While I have limited resources (SWT is low prio for me),
maybe somebody else likes to help you out?
At least .. I can assist.
In the end - pushing and managing SWT support by you
could help a lot!
Cheers, Sven
URL: https://forum.jogamp.org/Hangs-and-Freezes-JOGL-2-2-4-2-3-0-MacOS-X-Yosemite-JDK-6-7-8-SWT-3-8-2-4-4-2-tp4034199p4034203.html
On 03/27/2015 03:29 AM, Alexis Drogoul [via jogamp] wrote:
> Hi all,
>
Thank you for your elaborate bug report.
>
> Since JOGL has made tremendous progresses in supporting the SWT environment,
> we then decided to try out a pure SWT-based view for rendering OpenGL
> displays. I derived an "SWT" view based on the JOGL SWT GLCanvas, and tested
> the following combinations (only on MacOS X Yosemite, but we anyway need to
> have GAMA working on the 3 environments, on a 2011 17" MacBook Pro):
I still have to update and test for 'MacOS X Yosemite' in general.
It should not cause issues .. but hey, they do change things
under the hood quite often.
>
> - JDK 1.6 (the latest from Apple), JOGL 2.2.4 & 2.3, SWT 3.8.2.
> - JDK 1.7u76 (the latest 1.7 from Oracle), JOGL 2.2.4 & 2.3, SWT 3.8.2.
> - JDK 1.8u25 (the latest 1.8 from Oracle), JOGL 2.2.4 & 2.4, SWT 3.8.2
> - + all the above with a mixture of Eclipse 3.8.2 & SWT 4.4.2 (the latest from
> Eclipse).
>
> Not all combinations worked flawlessly, but they did at least display
> something, which was already great news (no more fiddling with AWT/SWT inter
> threading issues !). However, they *all* showed the exact same problem, which
> is the main reason why I decided to write this (long) message:
>
> 1) The initialization of OpenGL is slow. The UI is blocked something like 1 or
> 2 seconds, while it is much faster using the AWT based views. I dont
> understand why, as this initialization has normally nothing to do with AWT or
> SWT. One reason could be that GLProfile.initSingeton() is called as soon as we
> open an OpenGL display, and maybe it's blocking the SWT thread and not the AWT
> one. I did not investigate more, and I could benchmark this, probably, by
> explicitly calling initSingleton() in a different thread, but this issue is
> not a priority right now.
maybe some blocking occurs and SWT waits a bit longer.
>
> 2) Closing a view (either by hand or programmatically, when switching to a
> different model or simulation or relaunching a simulation) blocks the UI for 5
> to 10 seconds, with the closing OpenGL viewpart being emptied, then shown
> during this period, until it is closed and another one is opened. The logs
> show in all cases the exact same messages: "java.lang.RuntimeException: Waited
> 5000ms for: …" after a call to lockSurface() by the animator thread + a stack
> trace corresponding to the various dispose() calls (from the ViewPane to the
> GLCanvas). I've tried to stop the animator first, do some preliminary
> dispose() of various components, destroy the context, etc. with no luck.
> Disposing a view containing a JOGL SWT GLCanvas always hangs (and this is a
> pity, since the view works quite well…). I just noticed that this behavior
> does not happen if we simply open a view, obtain the first displaying of the
> model (the animator is anyway running behind), do not run the simulation (i.e.
> no wiping, no replacement of the displayed objects occur) and then close it.
> As if having some "contents" in the view would prevent the view from closing.
>
> 3) Closing the application freezes it if an OpenGL part is still open. The
> same message is displayed, but then nothing happens and I have to force-quit it.
>
> Pretty frustrating as I was quite close to the goal ! Now, I dont expect the
> members of the forum to magically solve this problem as it is clearly not a
> proper issue report. GAMA is a complex platform and it is perfectly possible
> that some of our design choices are the causes of this disappointing behavior.
>
> Instead, I would like to have advices on how to test this progressively. In
> the light of what I have exposed, what kind of repeatable benchmark should I
> try to run to eliminate the different causes of this behavior. Are there some
> available in the test units of JOGL ? A simple setup with the JOGL SWT
> GLCanvas that I could try and then progressively complexify by myself ?
Please check the jogl git repo.
Indeed it would be great, if you could extract a smallest possible
unit test for your (pure) SWT issues.
>
> Also, does this report make sense for other users/developers of JOGL ?
SWT is not my personal priority, however - there are users.
Hence .. it makes sense.
> Sometimes, simply mentioning a similar problem can shed a light on a part of
> the software I hadn't thought about before.
>
> Advices on how to proceed to obtain a working SWT-based OpenGL view are
> however what I expect the most, and I thank you in advance for your comment !
IMHO:
- Check out bugzilla database, whether an already existing SWT bug exists
and reply to it - or -
- Create a new bug entry ..
- Add unit tests via git repo ..
- We should have a 'most important SWT' bug group
(a new bug entry, all those most desired bugs will block)
The real problem is: Who will fix the bug?
While I have limited resources (SWT is low prio for me),
maybe somebody else likes to help you out?
At least .. I can assist.
In the end - pushing and managing SWT support by you
could help a lot!
Cheers, Sven
signature.asc (828 bytes) | Free forum by Nabble | Edit this page |