| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
sed -i 's/javax\.media\.opengl/com\.jogamp\.opengl/g' `grep -Rl "javax\.media\.opengl" src`
sed -i 's/javax\.media\.nativewindow/com\.jogamp\.nativewindow/g' `grep -Rl "javax\.media\.nativewindow" src`
sed -i 's/javax\/media\//com\/jogamp\//g' `grep -Rl "javax/media/" src`
sed -i 's/javax\/media\//com\/jogamp\//g' `grep -Rl "javax/media/" doc`
Manually edited all occurences within make/**
|
| | |
|
| |
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
| |
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
| |
|
|
| |
(detecting impl. bugs)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
+++
- X11Lib: Add QueryExtension(dpy, name) allowing early driver determination w/o GL
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locking, resulting in a native-lock-free impl.
The X11 implementation details of NativeWindow and NEWT used the X11 implicit locking facility
XLockDisplay/XUnlockDisplay, enabled via XInitThreads().
The latter useage is complicated within an unsure environment where the initialization point of JOGL
is unknown, but XInitThreads() requires to be called once and before any other X11 calls.
The solution is simple and thorough, replace native X11 locking w/ 'application level' locking.
Following this pattern actually cleans up a pretty messy part of X11 NativeWindow and NEWT,
since the generalization of platform independent locking simplifies code.
Simply using our RecursiveLock also speeds up locking, since it doesn't require JNI calls down to X11 anymore.
It allows us to get rid of X11ToolkitLock and X11JAWTToolkitLock.
Using the RecursiveLock also allows us to remove the shortcut of explicitly createing
a NullToolkitLocked device for 'private' display connections.
All devices use proper locking as claimed in their toolkit util 'requiresToolkitLock()' in X11Util, OSXUtil, ..
Further more a bug has been fixed of X11ErrorHandler usage, i.e. we need to keep our handler alive at all times
due to async X11 messaging behavior. This allows to remove the redundant code in X11/NEWT.
The AbstractGraphicsDevice lifecycle has been fixed as well, i.e. called when closing NEWT's Display
for all driver implementations.
On the NEWT side the Display's AbstractGraphicsDevice semantics has been clarified,
i.e. it's usage for EDT and lifecycle operations.
Hence the X11 Display 2nd device for rendering operations has been moved to X11 Window
where it belongs - and the X11 Display's default device used for EDT/lifecycle-ops as it should be.
This allows running X11/NEWT properly with the default usage, where the Display instance
and hence the EDT thread is shared with many Screen and Window.
Rendering using NEWT Window is decoupled from it's shared Display lock
via it's own native X11 display.
Lock free AbstractGraphicsDevice impl. (Windows, OSX, ..) don't require any attention in this regard
since they use NullToolkitLock.
Tests:
======
This implementation has been tested manually with Mesa3d (soft, Intel), ATI and Nvidia
on X11, Windows and OSX w/o any regressions found in any unit test.
Issues on ATI:
==============
Only on ATI w/o a composite renderer the unit tests expose a driver or WM bug where XCB
claims a lack of locking. Setting env. var 'LIBXCB_ALLOW_SLOPPY_LOCK=true' is one workaround
if users refuse to enable compositing. We may investigate this issue in more detail later on.
|
| |
|
|
|
| |
- Don't call "NativeWindowFactory.initSingleton(true);" after "GLProfile.initSingleton(true);",
since it's redundant, the former call issues the removed one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
jogamp.<module> (2/2) - edit files
- com.jogamp.opengl.impl -> jogamp.opengl
- com.jogamp.opengl.util.glsl.fixedfunc.impl -> jogamp.opengl.util.glsl.fixedfunc
- com.jogamp.nativewindow.impl -> jogamp.nativewindow
- com.jogamp.newt.impl -> jogamp.newt
This sorts implementation details from the top level, ie skipping the public 'com',
allowing a better seperation of public classes and implementation details
and also reduces strings.
This approach of public/private seperation is also used in the OpenJDK.
|
|
|
jogamp.<module> (1/2) - rename task
- com.jogamp.opengl.impl -> jogamp.opengl
- com.jogamp.opengl.util.glsl.fixedfunc.impl -> jogamp.opengl.util.glsl.fixedfunc
- com.jogamp.nativewindow.impl -> jogamp.nativewindow
- com.jogamp.newt.impl -> jogamp.newt
This sorts implementation details from the top level, ie skipping the public 'com',
allowing a better seperation of public classes and implementation details
and also reduces strings.
This approach of public/private seperation is also used in the OpenJDK.
|
