Workaround for Bug 623: Sporadic XCB assertion failures w/ ATI proprietary driver and w/o native X11 locking
The proprietary ATI X11 driver does not handle multi-threaded [GL] clients well, i.e. triggers an XCB assertion 'from time to time'.
It almost seems like that the driver either: - aliases all display connections to it's connection name, i.e. server; or - utilizes a build-in display connection w/o locking, used for some reason
- X11Util detects 'requiresGlobalToolkitLock' and 'markAllDisplaysUnclosable' via X11 extensions. In case certain ATI extensions are available, both are set to true.
- X11GLXDrawableFactory: Dropped setting 'markAllDisplaysUnclosable', using X11Util's detection (see above).
- New GlobalToolkitLock to satisfy certain driver restrictions (ATI's XCB multithreading bug)
- NativeWindowFactory handles new property requiresGlobalToolkitLock, in which case the new GlobalToolkitLock is being used instead of ResourceToolkitLock.
- JAWTUtil ToolkitLock locks GlobalToolkitLock 1st to match new 'requiresGlobalToolkitLock' property.
- Document static method requirement of X11Util, GDIUtil and OSXUtil via marker interface ToolkitProperties
- ToolkitLock: New method 'validateLocked()', allowing use to validate whether the device/toolkit is properly locked and hence to detect implementation bugs. See unit test class: ValidateLockListener
Relax Bug 613 workaround of commit 92398025abdabb2fdef0d78edd41e730991a6f94
Utilizing a GlobalToolkitLock in general to lock the display connection results in deadlock situations where locked surfaces signal other [offscreen] surfaces to render.
We have to see whether we find a better solution, for now sporadic XCB assertion still happen. But it is preferrable to point to the root cause, then to jumping through hoops to complicate locking or even to deadlock.
- Newt/X11Window: Discard display events after window close.
Relax ATI XCB/threading bug workaround: - ToolkitProperties: requiresGlobalToolkitLock() -> hasThreadingIssues() - NativeWindowFactory: Don't use GlobalToolkitLock in case of 'threadingIssues' the impact is too severe (see above) - NativeWindowFactory: Add getGlobalToolkitLockIfRequired(): To be used for small code blocks. If having 'threadingIssues' a GlobalToolkitLock is returned, otherwise NullToolkitLock. - X11GLXContext: [create/destroy]ContextARBImpl: Use 'NativeWindowFactory.getGlobalToolkitLockIfRequired()' for extra locking
Misc Cleanup: - *DrawableFactory createMutableSurface: Also create new device if type is not suitable - *DrawableFactory createDummySurfaceImpl: Pass chosenCaps and use it (preserves orig. requested user caps)
X11Util/Native: Fix X11Util_initialize0() arguments were wrong and code still invoked XInitThreads() .. woops; Added missing included "jogamp_nativewindow_x11_X11Util.h" incl. it's generation via javah, which was the culprit of not detecting it at compile time. This is a fix for commit fbe331f013608eb31ff0d8675f4e4c9881c9c48b
Fix regression of fbe331f013608eb31ff0d8675f4e4c9881c9c48b [Remove XInitThreads()]
NativeWindowFactory.getDefaultToolkitLock() is no more a global singleton, but an instance which has to track/lock a single resource. Hence the decoration w/ it in GLDrawableFactory is useless and applying lock/unlock on a new instance also a bug/regression.
Update PMVMatrix/GLMatrixFunc API doc and refine PMVMatrix update / get-Mvi/Mvit-Matrix operation. (Minor API change)
Using bitmask for requested Mvi and Mvit matrices, same as dirty-bits to ease matching and update operation.
Update of Mvi and Mvit will be performed only if it's dirty-bit and request-bit set within update(). The individual dirty bit is cleared only if it's matrix update is performed.
Update is also issued at get-Mvi/Mvit-Matrix operations to ensure proper values w/o update call w/o clearing the modified-bits.
update() returns true if the Mvi or Mvit matrix got updated _or_ one of the modified bits is set. update() clears the modified-bits.
Adding explicit getModifiedBits() to get and clear it's state.
Footprint Stats ; Fix Bug 624 - Compile and generate android JAR files (jogl-all-android.jar, jogl-test-android.jar) if android SDK JAR files are available. ; Split up atomic jogl-util.jar
Compile and generate android JAR files (jogl-all-android.jar, jogl-test-android.jar) if android SDK JAR files are available. - See gluegen commit 55b4552aef7882c358d545d020d6f12c958ed8ed
Also split up atomic jogl-util.jar - jogl-util.jar -> jogl-util.jar + jogl-util-graph.jar
Footprint Stats:
This demonstrates small footprint of a minimum configuration, all numbers in kilobytes (du -ksc). NOTE the min size of ~ 1MB!
![[Jenkins]](/chuck/static/5bc96da9/images/svgs/logo.svg){kind=logo}
