Re: JOGL/JDK7 RC10+ Display Issue, With Test Case
Posted by Sven Gothel on
URL: https://forum.jogamp.org/JOGL-JDK7-RC10-Display-Issue-With-Test-Case-tp4025819p4025826.html
On 08/17/2012 09:20 PM, rhatcher [via jogamp] wrote:
> Possible workaround (?):
>
> I attempted to reproduce this problem with Java2D without JOGL in the loop but
> couldn't make it fail.
>
> This pointed another finger at the GLProfile initSingleton method's indirect
> interruption of the event dispatch thread as the triggering event that
> eventually leads to the hangs, so I took a closer look at this method and
> noticed that its javadoc said:
>
> "Applications using this method may place it's (sic) call before any other UI
> invocation in the main class's static block or within the main function. In
> such case, applications may pass firstUIActionOnProcess=true to use native
> toolkit locking."
>
> Based on this suggestion I added a call to GLProfile.initSingleton() to the
> test app as one of the earliest things it does and this hang problem seems to
> have disappeared in JDK7. GLProfile.initSingleton(true) also worked, though
> it is deprecated. This also seems to fix the similar issue I was having in
> our full-up software set.
>
> I'm not sure what this says about how GLProfile.initSingleton() works. I'm
> still inclined to believe this is a race in JDK7's AWT that initSingleton()
> just happened to stimulate at the wrong time.GLProfile.initSingleton() calls GLProfile.initSingleton(false)
and initializes the whole JOGL GLProfile/GLContext availability state.
This task is pretty intensive and also involves kicking off
a designated thread holding a shared context/drawable for availability features
and to provide a common GLContext where necessary.
This off-thread initialization blocks the calling thread, AWT-EDT here, until finished.
Even though it is not clear to me how it freezes AWT-EDT indefinetly
for sure this complication has potential to cause havoc, as you have experienced.
Yes, hence it is a good idea to trigger initialization upfront in a more controlled
environment - read: out of AWT-EDT.
Usually this is done by any public GLProfile method like 'GLProfile GLProfile.get*(*)'
which is considered to be run from a user thread - at least in all of our use cases.
Maybe there is some new complication w/ JDK7 which exposes this regression.. dunno.
I will try your use case in a bit later on.
>
>
> Is there any disadvantage to making the initSingleton call early? If not then
> I'm going to forge ahead with this workaround.
Nope. It's actually good to have it done ASAP, allowing you to query some
JOGL availability - or to be allowed to crash w/o any other dependencies
if there is a JOGL bug etc.
Note [to myself]: I will cleanup the code path regarding the passed boolean 'firstUIActionOnProcess'
so there is no more behavioral difference. This is important since the method is deprecated
and same behavior is intended. Currently the only difference is _when_ X11 XInitThreads() gets called.
~Sven
URL: https://forum.jogamp.org/JOGL-JDK7-RC10-Display-Issue-With-Test-Case-tp4025819p4025826.html
On 08/17/2012 09:20 PM, rhatcher [via jogamp] wrote:
> Possible workaround (?):
>
> I attempted to reproduce this problem with Java2D without JOGL in the loop but
> couldn't make it fail.
>
> This pointed another finger at the GLProfile initSingleton method's indirect
> interruption of the event dispatch thread as the triggering event that
> eventually leads to the hangs, so I took a closer look at this method and
> noticed that its javadoc said:
>
> "Applications using this method may place it's (sic) call before any other UI
> invocation in the main class's static block or within the main function. In
> such case, applications may pass firstUIActionOnProcess=true to use native
> toolkit locking."
>
> Based on this suggestion I added a call to GLProfile.initSingleton() to the
> test app as one of the earliest things it does and this hang problem seems to
> have disappeared in JDK7. GLProfile.initSingleton(true) also worked, though
> it is deprecated. This also seems to fix the similar issue I was having in
> our full-up software set.
>
> I'm not sure what this says about how GLProfile.initSingleton() works. I'm
> still inclined to believe this is a race in JDK7's AWT that initSingleton()
> just happened to stimulate at the wrong time.
and initializes the whole JOGL GLProfile/GLContext availability state.
This task is pretty intensive and also involves kicking off
a designated thread holding a shared context/drawable for availability features
and to provide a common GLContext where necessary.
This off-thread initialization blocks the calling thread, AWT-EDT here, until finished.
Even though it is not clear to me how it freezes AWT-EDT indefinetly
for sure this complication has potential to cause havoc, as you have experienced.
Yes, hence it is a good idea to trigger initialization upfront in a more controlled
environment - read: out of AWT-EDT.
Usually this is done by any public GLProfile method like 'GLProfile GLProfile.get*(*)'
which is considered to be run from a user thread - at least in all of our use cases.
Maybe there is some new complication w/ JDK7 which exposes this regression.. dunno.
I will try your use case in a bit later on.
>
>
> Is there any disadvantage to making the initSingleton call early? If not then
> I'm going to forge ahead with this workaround.
Nope. It's actually good to have it done ASAP, allowing you to query some
JOGL availability - or to be allowed to crash w/o any other dependencies
if there is a JOGL bug etc.
Note [to myself]: I will cleanup the code path regarding the passed boolean 'firstUIActionOnProcess'
so there is no more behavioral difference. This is important since the method is deprecated
and same behavior is intended. Currently the only difference is _when_ X11 XInitThreads() gets called.
~Sven
signature.asc (910 bytes) | Free forum by Nabble | Edit this page |