| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
746383476aa449e9cab4a25df27be85b61aa074b
Add more verbose DBG_PRINT
- @ CreateWindow: extension, scanning device/class, registered deviceid
- @ DispatchMessage: XI_TouchBegin, XI_TouchUpdate and XI_TouchEnd
On my test machine w/o a touchscreen I correctly:
- detected extension
- detected no XITouchClass device, hence no deviceid registered
X11: [CreateWindow]: XI: Window 0x6600016, Extension 131
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[1/7]: type 1 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[2/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[3/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[4/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[5/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[6/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[1/13].class[7/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[2/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[3/13].class[1/3]: type 1 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[3/13].class[2/3]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[3/13].class[3/3]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[4/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[5/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[6/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[7/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[1/7]: type 1 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[2/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[3/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[4/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[5/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[6/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[8/13].class[7/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[1/7]: type 1 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[2/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[3/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[4/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[5/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[6/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[9/13].class[7/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[10/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[11/13].class[1/1]: type 0 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[1/7]: type 1 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[2/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[3/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[4/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[5/7]: type 2 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[6/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[12/13].class[7/7]: type 3 (is XITouchClass 0)
X11: [CreateWindow]: XI: Scan Window 0x6600016, device[13/13].class[1/1]: type 0 (is XITouchClass 0)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
92006e4baef57f1f3fb647dd307aed5989fd4c8d
Previous commit 92006e4baef57f1f3fb647dd307aed5989fd4c8d
(Note to Danny: I cannot test this now - please re-test and/or review)
X11Common::JavaWindow
- Owns XI extension's xiOpcode, selected xiTouchDeviceId and tracked XITouchPosition array
X11Window::CreateWindow
- Query XI extension only once @ window creation and earmark xiOpcode in JavaWindow instance
- Fix: Device selection code was "class->type != XITouchClass",
but shouldn't it be 'XITouchClass == class->type' (as patched here)
- Fix: Free XIQueryDevice returned XIDeviceInfo array via XIFreeDeviceInfo
- Earmark deviceid in JavaWindow instance
X11Display
- Moved global static touch_coordinates to JavaWindow::xiTouchCoords instance
X11Display::DispatchMessage
- Changed event handling structure similar to https://keithp.com/blogs/Cursor_tracking/
- Fix: Free XGetEventData's optional memory allocation via XFreeEventData
- Reuse JavaWindow's queried xiOpcode
- Fix: Don't overrise windowPointer, instead validate and require a match. JavaWindow must match!
- Fix: Also validate chosen deviceid with JavaWindow's registered device
Newt Build:
- Added libXi in build recipe and doc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Translucency Windows >= 8
Reverting 'clear backrgound' portion of commit f607c0148736fa198fb91b60123824e53366022e.
It has been identified, that Windows does initialize onscreen windows (i.e. w/ white/DESKTOP color).
This is also required for allowing translucent windows,
since clearing the background intefers on Windows >= 8 (undecorated windows).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility (X11 Onscreen)
X11Window.c:
Adding CWBackPixel BlackPixel(..) resulting in an initial black window (zero).
com.jogamp.opengl.test.junit.newt.TestWindows02NEWT shows the content
w/ opaque background and transparent one.
Note: To be able to receive a transparent background,
one needs to utilize a compositor WM (e.g. KWin w/ effects enabled).
Due to commit cf9e2f2cb8ead7efd7751dcbfaecb36ed06cf9d6 (Bug 1210)
this works in pure NEWT mode w/o utilizing GLX.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Fullscreen on Bottom not working though)
- Terminology
- ALWAYSONBOTTOM -> isOnBottom
- ALWAYSONTOP -> isOnTop
- Better support for 'isOnBottom' on Windows
- Refine 'SetWindowPos(..)' calls to handle isOn[Top|Bottom]
- Refine 'ShowWindow(..)' calls to handle isOnBottom
- Intercept WM_WINDOWPOSCHANGING to enforce isOn[Top|Bottom],
i.e. change params (hwndInsertAfter and flags).
- Fullscreen on Bottom not working
- While we change all flags appropriately (NOACTIVATE, ..)
and don't issue CDS_FULLSCREEN is on bottom,
Windows seems to enforce the window to be on top
if it is sized to the screen maximum.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Unresolved strncpy_s (MSVCRT) on WinXP,
as shown w/ dependency walker (red module, red unresolved line).
Mapped: _tcsncpy_s -> strncpy_s (!UNICODE).
On WinXP MSVCRT has no strncpy_s.
_tcsncpy_s(sOut, sOutLen, s, len)
-> bound-check + _tcsncpy(sOut, s, len)
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|\ |
|
| |
| |
| |
| | |
empty data
|
|/ |
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
|
|
|
| |
child windows
It has been experienced that UnmapNotify is not sent for child windows when using IconicState!
Hence the visible:=false event never reaches the Window, causing an error.
This patch only uses IconicState for top-level windows and if requested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
alwaysOnBottom and sticky/all-desktop (Part 1)
Change also implements Bug 1186: 'NEWT Window: Use a Bitfield holding all state flags and expose it accordingly',
since it is essential for an efficient implementation.
Part 1:
- Bug 1186
- Using Bitfield, holding public (Window) and private state bits/mask
- Bug 1188
- Window adds:
- [is|set]AlwaysOnBottom(..),
- [is|set]Resizable(..),
- [is|set]Sticky(..),
- [is|set]Maximized(..),
- isChildWindow(),
- Full implementation for X11
- TODO: Implement for OSX and Windows
- Manual tests:
- TestGearsES2NEWT, TestGearsES2NEWTSimple and TestGearsES2NewtCanvasAWT
utilize new NewtDemoListener, which has a key-listener to perform
all [new] actions. See source code of NewtDemoListener.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
creation
- Refines commit a566a1b5a2828b38f1a5c4dfb215ab9b03e7acaa
- Issue clamping at 'canCreateNativeImpl()' instead of 'createNativeImpl()',
allowing to define clamped position and size before utilizing these values
at caller 'createNative()'.
Otherwise a clamped position would cause to wait for the original position
after 'createNativeImpl()'.
This also allows to remove the positionChanged(..) / sizeChanged(..) calls in
the native CreateWindow0() implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
out-of screen window positions on BCM VC IV hardware
Out of screen window positions on BCM VC IV hardware cause:
- Misalignment of self-rendered mouse-pointer / window
due to window-offset.
- Artifacts when moving the mouse pointer partially
out of screen.
We still need to add the window position to rel. mouse-pointer position.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adopt to bug 1147, commit 2c88b6dfd4eb7e2cd9a50fa48e08ecafc980931a.
Using the native unique deviceID makes monitor identification more robust.
This also allows us simplify
displayID -> NSScreen-idx -> MonitorDevice
into
displayID -> MonitorDevice
and to survive a primary monitor change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ids, ..
RandR 1.3 XRRSetCrtcConfig related:
- X11RandR13 now sets the new screen size via XRRSetScreenSize(..)
- X11RandR13 now propagates RRScreenChangeNotify events
via XRRUpdateConfiguration(event).
Hence reporting virtual desktop size now.
- X11RandR13 now disables the CRTC before XRRSetCrtcConfig(..)
to avoid invalid configuration (see spec)!
RandR 1.3 General:
- Uses unique id named instead of unstable index
for modes and CRTC.
This allows proper identification even for 'swizzled' devices.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support added for
- Windows
- X11 XRandR 1.3
- OSX
Note: Our whole MonitorMode association handling is currently _not_ dynamic.
- only on Windows we actually use native unique ID,
which might not change (adapter and monitor idx)
- On OSX and X11 we simply use indices,
but if monitor setup changes - they refer to different instances.
In case it is desired to cover dynamic monitor setup change,
we need to address this issue in a new bug entry.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Iterate-over and identify all adapter:monitor. (Bug 1129)
- Identify cloned devices (fully covered)
- MonitorDevice gets 'isCloned()' to identify whether
it is a cloned device, i.e. fully covered by another monitor.
This detection may happen natively but will always performed
platform agnostic.
- getMainMonitor(..) now exclude 'cloned' devices
- Windows: Iterate-over and identify all adapter:monitor
- Since we also list cloned monitor,
we need to iterate over all adapter and all it's monitor-devices.
- The native monitor-id is now defined as: ( adapter-idx << 8 ) | monitor-idx.
- Bug 1129 <- listed under this bug entry for convenience
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, one must read the monitor's EDID data as stored in the registry,
no 'simple' API works otherwise.
The proper way requires utilizing the Windows Setup-API.
This code is inspired by Ofek Shilon's code and blog post:
<http://ofekshilon.com/2014/06/19/reading-specific-monitor-dimensions/>
See: function 'NewtEDID_GetMonitorSizeFromEDIDByModelName'
In contrast to Ofek's code, function 'NewtEDID_GetMonitorSizeFromEDIDByDevice'
uses the proper link from
DISPLAY_DEVICE.DeviceID -> SP_DEVICE_INTERFACE_DETAIL_DATA.DevicePath,
where DISPLAY_DEVICE.DeviceID is the monitor's enumeration via:
EnumDisplayDevices(adapterName, monitor_idx, &ddMon, EDD_GET_DEVICE_INTERFACE_NAME);
Hence the path to the registry-entry is well determined instead of just comparing
the monitor's model name.
|
|
|
|
|
|
|
|
|
| |
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/**
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Use float[2] for pixel-scale.
Utilize simple integer rounding:
int-pixel-units = (int) ( int-window-units * pixel-scale + 0.5f )
- Provide minimum and maximum allowed pixel-scale values
to be set by platform, supporting generic pixel-scale validation.
- Remove 'OSXUtil.GetPixelScale(final RectangleImmutable r, final int[] screenIndexOut)',
implementation for all platforms would cause huge redundancy of
Screen and MonitorDevice code (duplication of NEWT).
- instead, add 'float[2] pixelScale' to NEWT's MonitorDevice
- Detect change of pixel-scale and propagate accordingly.
This allows GLCanvas, GLJPanel and NewtCanvasAWT instances
to be dragged between monitor devices w/ different pixel-scale.
- OSX: Handle native triggered reshape events off-thread to avoid EDT congestion
due to locked window when consuming deferred events on EDT.
|
|
|
|
| |
kTISPropertyUnicodeKeyLayoutData), avoiding crash
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
surface DPI ; Add NEWT Window.getPixelsPerMM(..) to query surface DPI
With HiDPI and surface scale, we need knowledge of the native surface's pixel-scale
matching the monitor's pixel-per-millimeter value.
Preserving the queried native pixel-scale and exposing it via
ScalableSurface.getNativeSurfaceScale(..) to compute surface DPI.
Add NEWT Window.getPixelsPerMM(..) to query surface DPI.
Surface DPI is demonstrated in GraphUI's GPUUISceneGLListener0A .. and TestRulerNEWT01, etc ..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSX impl.
Add ScalableSurface interface
- To set pixelScale before and after realization
- To get pixelScale
- Implemented on:
- NEWT Window
- Generic impl. in WindowImpl
- OSX WindowDriver impl.
- Also propagetes pixelScale to parent JAWTWindow if offscreen (NewtCanvasAWT)
- AWT WindowDriver impl.
- JAWTWindow / OSXCalayer
- AWT GLCanvas
- AWT GLJPanel
- NEWTCanvasAWT:
- Propagates NEWT Window's pixelScale to underlying JAWTWindow
- WrappedSurface for pixelScale propagation
using offscreen drawables, i.e. GLJPanel
- Generic helper in SurfaceScaleUtils (nativewindow package)
- Fully implemented on OSX
- Capable to switch pixelScale before realization,
i.e. native-creation, as well as on-the-fly.
- Impl. uses int[2] for pixelScale to support
non-uniform scale.
Test cases:
- com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
- com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT
- com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2GLJPanelAWT
- com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NewtCanvasAWT
- Press 'x' to toggle HiDPI
- Commandline '-pixelScale <value>'
- Added basic auto unit test (setting pre-realization)
|
|
|
|
|
|
|
|
|
|
|
| |
NEWT
To properly convert Top-Left (TL) from/to Bottom-Left (BL) coordinates
we need to utilize the given CGDisplay viewport (TL)
and NSScreen (BL) to perform the y-flip.
This is especially true for the case of having multiple monitors
covering different viewports (mixed resolution).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NEWT Support / Fix JAWT getPixelScale deadlock
- NativeWindow/Surface/NEWT API DOC: Define Coordinate System of Window and Screen
- OSXUtil: Add getPixelScale(..) via Screen index and 'windowOrView'
- JAWTWindow/JAWTUtil.getPixelScale(..): Use pre-fetched AWT GraphicsConfiguration to solve AWT-TreeLock (deadlock)
- [Virtual] Viewport of MonitorDevice and Screen:
- Properly calculate and expose [virtual] viewport in window and pixel units
- OSX Monitor viewports in pixel units are 'reconstructed'
- Window/Viewport to Monitor selection shall be perfomed via window units (unique)
- OSX NEWT Window create/init (native): Use given size and coordinates even in fullscreen mode
Don't override by quering NSScreen coordinates, trust given values.
- Fix test cases, i.e. usage of pixel- and window-units
|
|
|
|
|
|
|
| |
appropriately
Instead of using [mWin orderBack: mWin] for child windows,
utilize [mWin orderWindow: NSWindowOut relativeTo: [pWin windowNumber]]
|
|
|
|
|
|
|
|
|
|
|
| |
*Common_GetJNIEnv()/_ReleaseJNIEnv() Methods and Usage / Check arguments ..
Since we still don't use inter-module native code sharing, align the JNIEnv get/release methods and usage.
Most beneficary here is OSX and the GLDebugMessageHandle,
both managed the JVM handle on their own - removed now.
Also ensuring that *Common_init(..) is called for all modules on all platforms.
|
|
|
|
| |
missing XFree(..) calls and argument checks.
|
| |
|
|
|
|
|
|
|
|
| |
Impl. manages up-to 32 windows (BCM layer elements) - dunno whether this is a proper value.
Note: Layer 2000 is reserved for out PointerIcon.
Removed 'dead code'.
|
| |
|