| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
GLProfile.initSingleton(firstUIAction)
|
|
|
|
| |
TO otherwise.
|
|
|
|
|
|
|
|
| |
Due to Display's reusage and hence concurrent involvement in off-thread animation,
the X11 default lock is required.
In case you require 2 GLWindow's w/o interference to each other (ie. locking),
you need to use separate Display instances.
|
| |
|
|
|
|
| |
setToolkitLock(..) swaps the lock thread safe.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Completes review of the underlying locking mechanism:
- commit e341ad8db546530b3a49c56c32cc26980e296201
- commit c84e235b3284d0e18481748b44594116e25821a9
- commit a94c1a2945a31aa5d93e354da3bc80f59f253ec4
- commit 7ae0f2df39692e82d7955dbcd09c35c36382726c
- commit 6b8f6e8d7c548cb6bfed14d8a04c9cf252ca7c4d
- commit 9ef0a0c185ace5217efc014809e97c5eead842cc
- commit 0314be79a7a93931a74fe4322bc78e699d7741e9
|
| |
|
|
|
|
|
|
| |
- WindowImpl exposes private non-delegated GraphicsConfiguration,
- which is being used by GLWindow's wrapped NativeWindow instantiation (eg: AWT driver)
- Fix NewtFactoryAWT.getNativeWindow() use AWTGraphicsConfiguration.create(..)
|
|
|
|
|
|
|
|
|
|
|
|
| |
XLockDisplay/XUnlockDisplay shall only be used if XInitThreads() was successful,
otherwise it has no effect (X11 spec).
- Only issue XInitThreads() if firstX11ActionOnProcess==true,
store result to determing whether we can utilize XLockDisplay/XUnlockDisplay.
- If we cannot utilize XLockDisplay/XUnlockDisplay, use RecursiveLock
- NativeWindowFactory: Only return AWTToolkitLock or X11JAWTToolkitLock if explicitly requested
|
|
|
|
|
| |
- remove validateNative()
- don't dispose AWT component, since we are an immutable uplink (was disposed if Window)
|
|
|
|
|
|
|
| |
- GLXUtil: Distinguish between client and server GLX information, cache client information.
- GLXDrawableFactory: Utilize GLXUtil client data, as well as cache (SharedResource) GLX server data,
avoiding 'uncontrolled' GLX queries, ie. w/o locking.
- isMultisampleAvailable = isClientMultisampleAvailable && isServerMultisampleAvailable
|
|
|
|
|
|
| |
CLASSPATH specific vars
Enable tests w/ and w/o AWT JARs ..
|
|
|
|
|
|
|
| |
connection open/close in various order
XLockDisplay/XUnlockDisplay shall only be used if XInitThreads() was successful,
otherwise it has no effect (X11 spec).
|
| |
|
|
|
|
| |
constructor
|
|
|
|
| |
AWTDevice: Remove subtype
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeWindow X11AWTGraphicsConfigurationFactory
X11AWTGraphicsConfigurationFactory properly construct a AWTGraphicsConfiguration
encapsulated a native X11GraphicsConfiguration, now available for non JOGL modules, ie NEWT.
AWTGraphicsConfiguration's create() utilizes the X11AWTGraphicsConfigurationFactory
via the generic factory mechanism and hence allows encapsulating a native [X11]GraphicsConfiguration.
NewtCanvasAWT creates/destroys the JAWT NativeWindow on addNotify/removeNotify (reparentWindow) again.
Hence the JAWTWindow is instantiated completly only, instead of utilizing updateConfiguration(..),
which simplifies the mechanism.
|
|
|
|
|
|
| |
instead of constructor for clarity.
- prepare for 'jogamp.nativewindow.x11.awt.X11AWTGraphicsConfigurationFactory'
|
|
|
|
|
|
|
|
|
|
|
| |
AbstractGraphicsConfiguration, if delegation is used.
This change restricts the usage of AbstractGraphicsConfiguration's getNativeGraphicsConfiguration()
to NativeSurface implementations and hence reduces complexity.
NativeSurface implementations are adapted and access to it's AbstractGraphicsConfiguration
is controlled via get/set method avoiding flawed usage (read/write), since read access shall
return the delegated AbstractGraphicsConfiguration, if used.
|
| |
|
|
|
|
| |
ie. delegated in all cases.
|
|
|
|
| |
remark and native test.
|
| |
|
|
|
|
|
|
|
| |
instance pair
Don't use the shared device due to locking issues on X11.
Other platform impl. usually don't have native semantics on device/screen and may use it.
|
|
|
|
| |
(minor edits)
|
| |
|
|
|
|
| |
leaving privileged block
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
public class GLDrawableFactoryImpl.
Michael Weber's test case (commit e7388512b69979d00e5a213a1b166a1b1726ae0c)
pointed me to the flaw in GLDrawableFactory which exposed a non-public method,
ie. 'getOrCreateSharedContext()'.
This lead to the assumption, that the 'shared' drawable/context of the factory is multi purpose
and may be used for application context sharing - which is not the case.
Changed Michael's test case to use a local shared pbuffer based drawable/context
and made the method non-public, where it belongs.
|
| |
|
|\
| |
| | |
New test case that demonstates bug 523, hang on application exit
|
| |
| |
| |
| |
| | |
GLContext objects are shared across GLWindow instances. This bug does
not manifest in the latest source.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- MacWindow/OffscreeSurface
- Exclude native NEWT window calls in case it's an offscreen surface
- MacWindow/DriverClearFocus
- Introduce driver detail DriverClearFocus interface
- OS X needs to clear the focus, before another TK (eg. AWT) can claim it's (native parent window focus)
- MacWindow/KeyCode:
- Move OS X keyCode utils to MacKeyUtil
- MacKeyUtil now uses OS X virtual key codes first, before matching keyChar -> keyCode
- NewtCanvasAWT
- Issue all AWT 'requestFocus()' on current thread,
Newt-EDT -> AWT-EDT may freeze Window's native peer requestFocus() impl.
- FocusAction directly issue action on Newt-EDT,
also request AWT focus if not having it (proper AWT traversal)
- Add an FocusPropertyChangeListener, detecting focus lost
to issue DriverClearFocus's clearFocus() if available.
- merge configureNewtChildInputEventHandler() code into configureNewtChild()
to simplify call tree.
- WindowImplAccess: Use getDelegatedWindow()
|
| |
| |
| |
| | |
deadlocks and simplify call-tree
|
| | |
|
| |
| |
| |
| | |
delegate (ie GLWindow)
|
| | |
|
| | |
|
| |
| |
| |
| | |
creation on AWT thread (may deadlock)
|
| |
| |
| |
| |
| |
| | |
d644e9321dceeecdd94a1797e25e6e356d957c23)
Missed build-nativewindow.xml commit
|
| |
| |
| |
| | |
- need to set setFocusable(true) manually due to z-order (newt child upfront)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
KeyListener handling (Bug 526)
NativeWindow:
- expose 'hasFocus()'
Window:
- 'protected enqueueRequestFocus(..)' -> 'public requestFocus(boolean wait)'
- New: 'setKeyboardFocusHandler(KeyListener)' allowing focus traversal co-op w/ covered TK (AWT)
WindowImpl:
- Impl Window changes (see above)
- Impl 'consumedTag' see commit 3b38957f36d4f89b85730755a41c00892ac70591
NewtCanvasAWT:
- FocusAction only removes the global AWT focus owner.
This fixes a deadlock on the Windows platform of AWT's native peer requestFocus impl,
since it's no more called at this point.
- NEW FocusTraversalKeyListener is set as the newtChild's KeyboardFocusHandler,
allowing traversal to the next/previous AWT component.
AWTParentWindowAdapter:
- focusGained(..) clears AWT focus and propagates focus to Newt child,
non blocking w/ 'requestFocus(false)' (see above)
KeyEvent:
- Document limitations of getKeyChar() (Bug 526)
MacWindow:
- only deliver keyChar on key Typed events, harmonizing platform behavior (Bug 526)
WindowsWindow:
- regenerate the keyCode for EVENT_KEY_TYPED (Bug 526)
X11Windows:
- complete keyCode mapping X11 -> Newt - X11KeySym2NewtVKey()
- only deliver keyChar on key Typed events, harmonizing platform behavior (Bug 526)
Tests:
- GearsES2: Make focus visible
- TestParentingFocusTraversal01AWT: unit test for keyboard focus traversal w/ NewtCanvasAWT
|
| |
| |
| |
| | |
which ends event propagation if attach to an InputEvent.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
AttachJAWTSurfaceLayer() OSXUtil -> MacOSXJAWTWindow
Threading/sync issue when creating a NEWT window, which issues a Java callback from native code (positionChanged()).
The latter requires a location validation w/ getLocationOnScreen() involved.
Hence getLocationOnScreen() shall not lock the JAWT native resources,
since it may not be ready yet (-> threading/sync issue).
|