| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WindowDriver.createWindow0(..)
OSX 10.14.3 Mojave issues a WARNING: NSWindow drag regions should only be invalidated on the Main Thread! This will throw an exception in the future.
The complaint about NativeWindow (NW)'s OSXUtil.CreateNSWindow0(..)
might be valid, which does create a NS Window instance w/ NSView and framebuffer initialized.
However, the complaint about NEWT's WindowDriver.createWindow0(..)
is not, since the initialization incl framebuffer happened later
on the main thread.
Regardless, encapsulated both construction fully to run on the Main-Thread.
+++
Originally the Main-Thread design spec was like:
Must run on Main-Thread when or after making visible.
Oh well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got access to a touchscreen laptop w/ Debian 9, hence I could fix and test the implementation.
X11 DisplayDriver.java:
- Store and pass through xi_opcode of XI extension, queried at initialization stage
X11Window.c Fixes:
- Initialize JavaWindow's xiTouchCoords[].id w/ -1, as required to track the pointer
- Pass through xi_opcode as stored in X11 DisplayDriver
X11Display.c Fixes:
- sendTouchScreenEvent: Throw RuntimeException if 0 > actionId (Internal Error: based on xiTouchCoords[].id tracking)
- DispatchMessages's windowPointer determination:
-- Query potenial XI Event first: IF XI Event, must use XIDeviceEvent's event Window
-- Only IF not an XI Event, we can use evt.xany.window as the event window
- DispatchMessages's XI Event Handling:
-- Always break deviceid search loop if id found, preserving index and time spend
Works on my Debian 9 device, tested w/ com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT:
- One pointer (finger) press, drag and release (click)
- PinchToZoomGesture works
- DoubleTabScrollGesture works
+++
Potential Issues:
JavaWindow's xiTouchCoords[].id accuracy is crucial to pointer tracking
during XI_TouchBegin -> XI_TouchUpdate -> XI_TouchEnd.
In the normal course of action:
- XI_TouchBegin sets the id, assuming it is yet set
- XI_TouchUpdate assumes it is set
- XI_TouchEnd clears the id, assuming it is set
This field in the JavaWindow array only gets reset to -1 once at native window
creation. We may need to figure out when to reset this field to -1.
If the XI_TouchEnd events would get lost for whatever reason,
the above tracking state would be broken.
|
|\
| |
| | |
Fix overlay/underlay position mismatch in X11UnderlayTracker (bug 1315)
|
| |
| |
| |
| |
| |
| | |
enabled
With the overscan enabled by the Raspberry Pi firmware, which seems to be the default for some attached displays, the underlayWindow size will be e.g. 1888x1048 (retrieved from X11), whereas the overlayWindow size remains at 1920x1080 (retrieved from the Broadcom VC IV implementation). This causes the overlay window to be visually offset by a few pixels. Correct this by applying an offset when the two don't match. (Both displays are assumed to have the same center.)
|
|\ \
| | |
| | | |
Fix mouse button reporting in X11UnderlayTracker
|
| |/ |
|
|\ \
| | |
| | | |
add touch event support for x11 server
|
| |/ |
|
|\ \
| | |
| | | |
Fix viewport height in BCM VC IV ScreenDriver
|
| |/
| |
| |
| | |
This should fix https://jogamp.org/bugzilla/show_bug.cgi?id=1254, which leads to windowed sketches not being centered in Processing.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NewtCanvasJFX
NewtCanvasJFX, a JavaFX Canvas Node, allows attaching a native NEWT Window to the JavaFX Node's native Window (if attached).
The mechanism is similar to NewtCanvasAWT.
Current implementation supports placing the NEWT Window
into the JavaFX scene of the native window correctly,
as well as the following different lifecycles
- attach NewtCanvasJFX to already visible group->scene->window
- attach NewtCanvasJFX to not yet visible or attached group->scene->window
- attach NEWT Window before or after NewtCanvasJFX's visibility
The above is covered by unit test: TestNewtCanvasJFXGLn
This is the initial commit for JavaFX support and has been tested on
- OpenJDK 8 + OpenJFX 8
- GNU/Linux X11
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSX El Capitan 10.11.1 using JRE 1.8.0_66:
Animated NEWT GLWindow flickers at resize.
While at live resize the animation thread renders
into the live resized NSView which causes flickering on OSX 10.11.
Resolution is to pause animation during live resize
and resume at its end.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding QUIRK_BIT_VISIBILITY
1) More visibility detection on post ConfigureNotify events,
since the latter may not yet contain the updated visibility state
as it whould (WM bug!):
- EnterNotify
- LeaveNotify
- Disabled
- Expose
- VisibilityNotify
2) Introducing quirks.
Setting QUIRK_BIT_VISIBILITY to handle the issue where
visibility -> false could not even be set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
addNotify, e.g. by moving to other monitor
AWTCanvas removeNotify didn't cause 'local' destruction of the NEWT window,
allowing a 'recreate' w/ subsequent addNotify.
This case has been hacked-into NEWT.AWT.WindowDriver + AWTCanvas:
- suppression of window destroy events
- keeping fields/states intact in NEWT.AWT.WindowDriver
- propagating signals appropriately
Note: This is barely a working hack and not a fine piece of software :)
This AWT backend driver exists only due to historical reasons.
This hack simply proves that JAWTWindow works properly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Handle case where KDE unmaps the window
Update our internal JavaWindow.isMapped according to MapNotify and UnmapNotify.
This takes care of a situation (KDE) where a window is unmapped
during IconicState.
For unmapped windows we cannot interprete _NET_WM_STATE_HIDDEN
and we have to issue XMapWindow for restoring the window.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ConfigureNotify event (2)
On gnome shell WM, sometimes KDE WM,
it has been observed that the _NET_WM_STATE_HIDDEN update (visible or invisible)
is not received at ConfigureNotify event.
Turns out the state is finally updated at FocusOut!
This change tests _NET_WM_STATE_HIDDEN visibility hint
for mapped window also for FocusIn and FocusOut events,
besides the ConfigureNotify event.
Further more, NormalState to restore a hidden but mapped
window did not work, so it is no more being sent.
We limit us here to _NET_ACTIVE_WINDOW.
2 unit tests are prepared to test this issue:
- TestGLWindows00NEWT
- TestParenting01NEWT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_NET_WM_STATE_HIDDEN; setVisible(true) not restoring from _NET_WM_STATE_HIDDEN
Using Gnome Shell 3.14.4-1~deb8u1 disclosed an issue w/ our newly utilized IconicState/_NET_WM_STATE_HIDDEN,
i.e. visibleChanged(false) was never received.
This is a regression of commit 2d837a7a7130702ad36b694875613fae77c7ef06,
which utilizes WM_CHANGE_STATE_IDX + IconicState for visibility
on top-level windows.
This bug consist out of _two_ isssue:
1) setVisible(false) IconicState not listening to _NET_WM_STATE_HIDDEN
Here, we 'listen' to _NET_WM_STATE_HIDDEN when receiving ConfigureNotify
if supported _and_ XMapWindow has been issued.
In such case existence/non-existence of _NET_WM_STATE_HIDDEN determines visibility.
Otherwise, we have wait for MapNotify/UnmapNotify.
The 'XMapWindow has been issued' criteria is tracked by new field 'JavaWindow.isMapped'
and set/cleared when we actually issue XMapWindow/XUnmapWindow!
2) setVisible(true) not restoring from _NET_WM_STATE_HIDDEN
It has been observed that restoring IconicState/_NET_WM_STATE_HIDDEN
via XMapWindow or even NormalState may not work reliably on WMs.
See <https://stackoverflow.com/questions/30192347/how-to-restore-a-window-with-xlib>
Hence we restore from this WM state via NormalState _and_ _NET_ACTIVE_WINDOW.
Both strategies seem to work well on KDE as well as on Gnome.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug 1199 - Add setting to disable default window icons
Bug 1238 - Fix NPE for Window-Icon's PNGPixelRect for unresolved location, i.e. null URLConnections
Testing w/ jogl/make/scripts/tests.sh USE_BUILDDIR=1,
discloses this issue - since the icons are available in jar only.
Handling all unresolved resources, i.e. null URLConnection,
is required.
Further more, the icon list passed via property 'newt.window.icons'
shall be separated by comma as well.
This allows passing the list via scripts more conveniently.
-Dnewt.window.icons="newt/data/jogamp-16x16.png,newt/data/jogamp-32x32.png"
+++
Bug 1199 - Add setting to disable default window icons
This patch also allows disabling JogAmp's own window icons
by simply defining a non-existing location, i.e.
-Dnewt.window.icons="null,null"
|
|
|
|
|
|
|
|
| |
d78bb1be0a6290cb94918b21865a023c01825048
- Skip relative lookup for IOUtil.ClassResources using 'asset' only (from JAR file)
- Tested w/ jar file and build-dir, see scripts/tests.sh 'USE_BUILDDIR'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Lack of Aero / Blur )
Adopting new undocumented user32.dll Windows >= 8 API:
- SetWindowCompositionAttribute / AccentState
See:
- <https://github.com/riverar/sample-win10-aeroglass/blob/master/MainWindow.xaml.cs>
- <http://withinrafael.com/adding-the-aero-glass-blur-to-your-windows-10-apps/>
- <http://undoc.airesoft.co.uk/user32.dll/SetWindowCompositionAttribute.php>
- <http://undoc.airesoft.co.uk/user32.dll/GetWindowCompositionAttribute.php>
+++
Cleaning up WindowsDWM.h, use on header file (in stub_includes)
for GlueGen and implementation.
+++
Merge java implementation within GDIUtil.DwmSetupTranslucency(..),
to be utilized by NEWT and JOGL.
NEWT issues GDIUtil.DwmSetupTranslucency(..) at creation
and when toggling decoration.
Toggling decoration on Win >= 8 leads to lost of translucency
when returning to decorated window.
On Win 7, this may work .. but is also buggy.
+++
Followup patch is needed for NEWT to _not_ clear the background!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility (Windows Onscreen)
WindowsWindow.c:
- WindowUserData.isInCreation set while window at initizalization,
i.e. before final size/pos/visibility.
Also no visibility until final NewtWindow_setVisiblePosSize(..) call.
This is possible since even w/o ShowWindow upfront,
UpdateInsets(..) is able to gather accurate values.
- Suppress any Java callback while WindowUserData.isInCreation,
issue one callback when window is final.
Use newly accumulated callback WindowImpl.sizePosInsetsFocusVisibleChanged(..)
- While WindowUserData.isInCreation, WM_PAINT triggers WM_ERASEBKGND
and WM_ERASEBKGND actually erases background w/ window background color.
|
|
|
|
| |
non default (performance)
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The NSWindow level must be set at window creation
- Levels are
- aontop: kCGMaximumWindowLevel
- aonbottom: kCGDesktopIconWindowLevel (w/ input)
- normal: NSNormalWindowLevel
- Hence we need to recreate the NSWindow if toggling the state,
similar to opaque .. etc.
|
|
|
|
|
|
|
| |
setMaximized(..) isReconfigureMaskSupported(..) was using the state bit-number
instead of the state bit-mask!
Fixed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
screenPositionChanged(..) in size[Screen]PosInsetsChanged(..) on OSX; Cleanup OSX Code
- Fix Deadlock in screenPositionChanged(..)
Defer requires to spawn whole child-window action to another thread
since we may come from native 'NewtWindow::windowDidMove()' on MainThread.
- Use screenPositionChanged(..) in size[Screen]PosInsetsChanged(..) on OSX
Move callback WindowImpl::sizePosInsetsChanged(..)
to OSX's WindowDriver::sizeScreenPosInsetsChanged(..),
since we need to use screenPositionChanged(..) to calculate
child window relative position to parent.
I.e. we receive the location on screen.
- Cleanup OSX Code
- Native JNI entries shall handle NULL windowHandle -> return
- Clarify usage of 'getWindowHandle()' and use 'isNativeValid()'
if appropriate.
- Don't re-use cached getWindowHandle()
for non-blocking off-thread actions, since handle may become invalid.
- Clarify getLocationOnScreen*(..) implementation code,
i.e. separate getLocationOnScreenByParent(..) semantics.
|
|
|
|
|
|
|
|
|
|
|
| |
screen
- On OSX (similar to X11) a created window with size > screen
will get resized to fit screen size implicitly.
- Fix detects insets, position and size after onscreen window creation.
- Patch also merges insets and size change java callback
|
|
|
|
| |
platforms, i.e. OSX)
|
|
|
|
| |
by API doc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InterruptedException(s)
Below is an updated list of Condition-Wait classifications
as described in Bug 1211.
This list includes recent changes on GlueGen
regarding this Bug 1211.
A followup commit will address the unit tests.
- Noncancelable + Persistent-Wait
- GLMediaPlayerImpl.StreamWorker thread (changed)
- pauses thread in case of intr
- Cancelable + Persistent-Wait:
- LFRingbuffer.getImpl(..)
- LFRingbuffer.waitForFreeSlots(int)
- SyncedRingbuffer.getImpl(..)
- SyncedRingbuffer.waitForFreeSlots(int)
- FunctionTask.invokeOnNewThread(..) (changed)
- RunnableTask.invokeOnNewThread(..) (changed)
- SharedResourceRunner.run()
- SharedResourceRunner.doAndWait() (changed)
- SharedResourceRunner.start() (changed)
- SharedResourceRunner.stop() (changed)
- GLMediaPlayerImpl.StreamWorker ctor (changed)
- GLMediaPlayerImpl caller thread actions do*() (changed)
- AndroidGLMediaPlayerAPI14.getNextTextureImpl(..) (changed)
- DisplayImpl.enqueueEvent(..) (changed)
-> Persistent-Wait
-> Cancels wait and NEWTEvent
-> dispatchMessage(NEWTEventTask): always notifyCaller!
- GLDrawableHelper.invoke(..) (changed)
- DefaultEDTUtil.waitUntilIdle() (changed)
- DefaultEDTUtil.waitUntilStopped() (changed)
- DefaultEDTUtil.invokeImpl(..) (changed)
- DefaultEDTUtil.NEDT.run(..) (changed)
- AWTEDTUtil.waitUntilStopped(..) (changed)
- AWTEDTUtil.invokeImpl(..) (changed)
- AWTEDTUtil.NEDT.run(..) (changed)
- SWTEDTUtil.invokeImpl(..) (changed)
- SWTEDTUtil.waitUntilStopped(..) (changed)
- SWTEDTUtil.NEDT.run(..) (changed)
- GLWorkerThread.invokeAndWait(..)
- GLWorkerThread.start() (changed)
- GLWorkerThread.WorkerRunnable.run() (changed)
- Animator.run() (changed)
- AnimatorBase.finishLifecycleAction() (changed)
- OSXUtil.RunOnMainThread(..) (changed)
- SingletonInstanceServerSocket.Server.shutdown() (changed)
- SingletonInstanceServerSocket.Server.start() (changed)
- com.jogamp.audio.windows.waveout.Mixer.shutdown() (changed)
- Extending/Using InterruptSource.Thread (changed)
- DefaultEDTUtil.NEDT
- AWTEDTUtil.NEDT
- SWTEDTUtil.NEDT
- GLWorkerThread.thread
- Mixer.FillerThread
- Mixer.MixerThread
- Using InterruptSource.Thread (changed)
- TempFileCache
- LauncherTempFileCache
- Animator.thread
- SingletonInstanceServerSocket.Server.serverThread
Deprecated:
- FunctionTask.invoke(..) (changed)
-> on current thread, no wait -> deprecated
- RunnableTask.invoke(..) (changed)
-> on current thread, no wait -> deprecated
|
|
|
|
|
|
|
|
|
|
| |
getSupportedStateMask()
- Skip operation if not supported
- Fix skip operation if isFullscreen() && !isNativeValid():
We have to store the state w/o action,
so the state can be picked up at native creation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(X11, Windows)
The regression was caused by WindowImpl changes:
(1) Not ignoring maximizedChanged(..) during fullscreen.
X11 windows may promote maximized state, which will be passed
in reconfigure -> non-fullscreen and hinders reseting the original size.
(2) getReconfigureMask(..) was wrongly translated to state-mask,
i.e. special handling of STATE_MASK_UNDECORATED and STATE_MASK_CHILDWIN
was removed.
- Issues above were corrected
- Replace PSTATE_MASK_FULLSCREEN_NFS* w/ own stateMaskNFS for simplification
|
|
|
|
|
|
|
|
|
| |
(adding STATE_MASK_FULLSCREEN)
Refine getSupportedStateMask():
- always for _after_ native creation, i.e. first visibility
- removed STATE_MASK_AUTOPOSITION
- adding STATE_MASK_FULLSCREEN to minimum requirements
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Xerxes Rånby <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Xerxes Rånby <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
- Fix STATE_MASK_CREATENATIVE
- Simplify resetStateMask()
- Windows WindowDriver: Remove STATE_MASK_STICKY from supported states
- TestGearsNEWT: Use NEWTDemoListener
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
getSupportedReconfigMaskImpl()
- See getSupportedStateMask() for semantics
- getSupportedReconfigMaskImpl() result now used for isReconfigureMaskSupported()
- getSupportedReconfigMaskImpl() implementations:
- Full featured: X11, Windows and OSX
- X11: Use WindowManager Atoms for certain features (dynamic)
- Others: Use fixed features.
- TODO: Consider avoiding actions if not supported.
|
| | |
|
|/
|
|
|
|
|
|
|
| |
- STATE_BIT_FULLSCREEN_SPAN is private and used for reconfigure,
hence STATE_BIT_COUNT_RECONFIG is needed.
- STATE_BIT_FULLSCREEN_SPAN is added at the end of public state bits
- PSTATE_BIT_MINMAXSIZE_SET is unused.
|
| |
|
|
|
|
|
|
|
| |
- to avoid resizing when toggling resizable (change of window border)
we maintain 'RECT insets' in our WindowUserData struct
and fix the client -> top position late in NewtWindow_setVisiblePosSize(..)
after any style change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WindowImpl
- remove updateMinMaxSize(..) - unused info
- fix appendStateToString: show all maximized state changes if reconfig
- add sizePosMaxInsetsChanged(..) and sendMouseEventRequestFocus(..)
accumulating multiple callbacks from impl.
- add: maximizedChanged(..) notification from native impl.
- refine manual maximized mode
used for OSX and Windows (single extent)
- reconfigMaximizedManual(..)
- resetMaximizedManual(..)
X11 WindowDriver:
- Update maximized at xreconfig, read from _NET_WM_STATE
- Use less Java callbacks from JNI
Windows WindowDriver:
- Use native maximized, if HORZ && VERT,
otherwise use manual maximized for single extent.
- Invisible of top-window -> MINIMIZED/ICONIFY
showing the app in task-bar.
|
|
|
|
|
|
| |
rely solely on insetsChanged(..) (event driven)
Only affected WindowDriver is AWT, which now updates the insets when setVisible(true).
|
|
|
|
|
|
| |
If not waiting for resize on main-thread,
corruption may happen at continued rendering.
This has been experienced w/ maximize-horizontally (Bug 1188).
|
|
|
|
| |
reconfig DEBUG
|
| |
|