| Summary: | Applications hang when making base frame visible | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | Bill Clark <bclark> |
| Component: | x11 | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | wwalker3 |
| Priority: | --- | ||
| Version: | 2 | ||
| Hardware: | pc_all | ||
| OS: | linux | ||
| Type: | --- | SCM Refs: | |
| Workaround: | --- | ||
| Attachments: |
output of test.sh
test case |
||
Created attachment 249 [details]
test case
Running on CentOS 5.5 from within Eclipse, the app freezes after it prints this (and I can't close the window): Info: XInitThreads() called for concurrent Thread support GL3 is availableProfile: GLProfile[GL2/GL2] Xlib: unexpected async reply (sequence 0xa4)! Xlib: sequence lost (0x10000 > 0xa4) in reply type 0x21! But when I change GLProfile.initSingleton( true ) to GLProfile.initSingleton( false ), the app works correctly and I get this output: Info: XInitThreads() called for concurrent Thread support GL3 is availableProfile: GLProfile[GL2/GL2] Card Vendor: NVIDIA Corporation GL Version: 3.0.0 NVIDIA 260.19.29 Renderer: Quadro NVS 295/PCI/SSE2 Could you try changing/removing GLProfile.initSingleton() to see if it makes a difference on your machine? My understanding was that GLProfile.initSingleton() is supposed to be optional, so your program should work without it. Not sure what's supposed to happen if you tell it "true" when you're not actually before all other X calls -- Sven? (In reply to comment #2) > > But when I change GLProfile.initSingleton( true ) to GLProfile.initSingleton( > false ), the app works correctly and I get this output: > Calling initSingleton(false) fixed all my hangs as well. the call with true wasn't the very first piece of code executed just close to it. When I make the call to initSingleton(true) as the very first thing in main() it also works perfectly. Thanks for your work! Let's wait and see what Sven says -- I didn't think it should be possible to crash an app by using initSingleton() wrong :) Re comment 2 > My understanding was that GLProfile.initSingleton() is supposed to be optional, > so your program should work without it. Not sure what's supposed to happen if > you tell it "true" when you're not actually before all other X calls -- Sven? initSingleton(boolean firstUIActionOnProcess) http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLProfile.html#initSingleton%28boolean%29 The parameter 'firstUIActionOnProcess' shall reflect the situation whether any other UI toolkit (UI-TK) operation has been issued before using JOGL (calling initSingleton(boolean)) in the process. In case initSingleton(boolean) is not called explicitly, JOGL will implicitly call 'initSingleton(false)'. If 'firstUIActionOnProcess' is 'true' JOGL will assume safe multithreading usage of the UI-TK, otherwise expensive locking of the UI-TK must be utilized (sequential use). This is currently true for X11 only and related to the XInitThreads() call, http://tronche.com/gui/x/xlib/display/XInitThreads.html Exception: If something else uses the UI-TK (X11) before JOGL in the process, but is thread safe due to calling XInitThreads() upfront, you _can_ pass 'true' as a parameter. In case of IDEs, applets, etc .. where JOGL is not the 1st UI-TK user in the process and the aforementioned did not make UI-TK thread safe (XInitThreads()), you shall pass 'false' as it's argument. Re comment 3 > Calling initSingleton(false) fixed all my hangs as well. the call with true > wasn't the very first piece of code executed just close to it. When I make the > call to initSingleton(true) as the very first thing in main() it also works > perfectly. Thanks for your work! This behavior reflects the API doc and the above description. Re comment 4 > Let's wait and see what Sven says -- I didn't think it should be possible to > crash an app by using initSingleton() wrong :) If you explicitly issue 'initSingleton(true)' in a situation where eg the IDE used the UI-TK before JOGL in a non thread safe manner (no call to XInitThreads()), then indeed you could crash the process. However, not calling 'initSingleton(boolean)' at all should be safe, since JOGL will implicitly call 'initSingleton(false)'. |
Created attachment 248 [details] output of test.sh Running Ubuntu 10.04 on both 32 bit and 64 bit pcs - test.log from the 32 bit OS. JOGL build: Release candidate 2 (jogl-2.0-b23-20110303-linux-i586) - problem started with devbuild b308 and continues to present. Build b303 still works well. OpenGL: NVidia driver 260.19.26 - covers up to OpenGL 3.3. Graphics card: Nvidia GeForce GTS 250. Java version: jdk1.6.0_23. Error message (from command line only - just hangs in Eclipse): Nativewindow X11 IOError: Display 0x81696d0 (:0.0): Resource temporarily unavailable