aboutsummaryrefslogtreecommitdiffstats
path: root/src/newt/native
Commit message (Collapse)AuthorAgeFilesLines
* NEWT iOS / MacOS: Simplify setJavaWindowObjectSven Gothel2019-07-082-15/+17
|
* iOS / MacOS: PixelScale UpdateSven Gothel2019-07-081-23/+27
| | | | | | | | | | - IOSUtil/OSXUtil: Return float value and refine name to GetScreenPixelScale* - WindowDriver's updateMaxScreenPixelScaleByDisplayID(..) and updateMaxScreenPixelScaleByWindowHandle(..) will only update the maxPixelScale, as actual user pixelSize change should not be triggered here. A user pixelSize adaption to the changed underlying scale capabilities (e.g. switch monitor) should be supported by the implemented WindowDriver's: updatePixelScale(..) called by native code.
* Copyright: Add missing Copyright tagSven Gothel2019-07-085-2/+57
| | | | | | | | | Adding the missing JogAmp copyright tag on certain files. Currently in debate whether 'JogAmp Community' is a legal Copyright tag in the first place, we might need to add (or replace it with) my authorship. However, as authorship is well documented via the git repository, this should be no real world issue.
* NEWT WindowImpl.doPointerEvent: Use native short[] for pNamesSven Gothel2019-07-082-13/+13
| | | | | | and not int[], this avoid copying in case given pNames are normalized. This is benecifical for X11, Windows and the upcoming iOS touch/pointer support.
* NEWT: Align native MacOS / IOS file- and classnamesSven Gothel2019-06-264-102/+102
|
* iOS: Initial working commit supporting iOS (ipad pro 11)Sven Gothel2019-06-234-0/+2138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | using our OpenJFK 9 x86_64 and arm64 build. Test demo class is 'com.jogamp.opengl.demos.ios.Hello', residing in the new demo folder 'src/demos/com/jogamp/opengl/demos/ios/Hello.java'. This commit does not yet include a working NEWT specialization for iOS, but it shall followup soon. Instead this commit demonstrates JOGL operating on native UIWindow, UIView and CAEAGLLayer as provided by Nativewindow's IOSUtil. Test Video https://www.youtube.com/watch?v=Z4lUQNFTGMI +++ Notable bug: The FBO used and sharing the COLORBUFFER RENDERBUFFER memory resources with CAEAGLLayer to be displayed in the UIView seemingly cannot handle GL_DEPTH_COMPONENT16, GL_DEPTH_COMPONENT24 or GL_DEPTH_COMPONENT32 depth buffer - none at all (Device + Simulation). Therefor the default demo GLEventListener chosen here don't require a depth buffer ;-) This issue can hopefully be mitigated with other means than using a flat FBO sink similar to FBO multisampling.
* Bug 1348: Fix X11 XI MultitouchSven Gothel2019-03-273-95/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1348: X11 XI Multitouch: Refine commit ↵Sven Gothel2019-03-272-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Bug 1348: X11 XI Multitouch: Fixes of previous commit ↵Sven Gothel2019-03-273-143/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* add touch event support for x11 serverDanny Koernig2016-11-173-3/+199
|
* Bug 1267 - OSX El Capitan: Animated NEWT GLWindow flickers at resizeSven Gothel2015-11-152-3/+33
| | | | | | | | | | | | 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.
* Bug 1249: NEWT/X11 Visibility: Listening to more events for updated state; ↵Sven Gothel2015-10-102-7/+43
| | | | | | | | | | | | | | | | | 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.
* Bug 1249 - NEWT X11: setVisible(false) IconicState/_NET_WM_STATE_HIDDEN: ↵Sven Gothel2015-10-091-4/+6
| | | | | | | | | | | 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.
* Bug 1249 - NEWT X11: setVisible(*) _NET_WM_STATE_HIDDEN update not received ↵Sven Gothel2015-10-093-42/+64
| | | | | | | | | | | | | | | | | | | | | | 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
* Bug 1249 - NEWT X11: setVisible(false) IconicState not listening to ↵Sven Gothel2015-10-084-108/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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 1205: Revert clear background to support fix for Bug 1232: NEWT ↵Sven Gothel2015-10-011-7/+24
| | | | | | | | | | 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).
* Bug 1232 - NEWT Translucent Decorated Windows Not Working On Windows >= 8 ↵Sven Gothel2015-10-011-58/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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!
* Bug 1205 - NEWT Security: Clear framebuffer after creation and before ↵Sven Gothel2015-09-291-45/+125
| | | | | | | | | | | | | | | | | | | 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.
* Bug 1222 - NEWT OSX: setAlwaysOnTop() and setAlwaysOnBottom() not workingSven Gothel2015-09-263-51/+20
| | | | | | | | | | | | - 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.
* Bug 1214: Fix Deadlock in screenPositionChanged(..); Use ↵Sven Gothel2015-09-262-43/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1214 - NEWT MacOSX: Detect auto-resize of Window when it is larger than ↵Sven Gothel2015-09-253-10/+52
| | | | | | | | | | | 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
* Bug 1205 - NEWT Security: Clear framebuffer after creation and before ↵Sven Gothel2015-08-311-10/+9
| | | | | | | | | | | | | | | | 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.
* Bug 1188: NEWT WindowsWindow.c: Better support for 'isOnBottom' on Windows ↵Sven Gothel2015-08-261-14/+68
| | | | | | | | | | | | | | | | | | | | | | (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.
* NEWT WindowsWindow.c: Fix return value; Add tracking of inOn[Bottom|Top]Sven Gothel2015-08-251-4/+24
|
* Bug 1188: Introduce getSupportedStateMask() implemented via WindowDriver's ↵Sven Gothel2015-08-211-2/+30
| | | | | | | | | | | | | 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.
* Bug 1196: Fix Unresolved strncpy_s (MSVCRT) on WinXPSven Gothel2015-08-201-2/+8
| | | | | | | | | | 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)
* Bug 1188: Cleanup public/private[reconfig, non-reconfig] state bitsSven Gothel2015-08-191-1/+3
| | | | | | | | | - 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.
* Merge branch 'Bug1183' of https://github.com/xranby/joglSven Gothel2015-08-181-0/+8
|\
| * Bug 1183: X11RandR13 XRRGetScreenResourcesCurrent _occasionally_ reports ↵Xerxes Rånby2015-08-161-0/+8
| | | | | | | | empty data
* | Bug 1192: NEWT native/X11Display.c Cleanup JNI signatures in commentsXerxes Rånby2015-08-131-6/+6
|/
* Bug 1188: Windows: Implement unresizable using appropriate windows stylesSven Gothel2015-08-121-104/+51
| | | | | | | - 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.
* Bug 1188: Refine Maximized on X11 / Impl. Maximized and Iconify on WindowsSven Gothel2015-08-124-102/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1188: Fix regression on X11 setVisible: in-visibility never reached on ↵Sven Gothel2015-08-111-5/+8
| | | | | | | | | 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.
* Bug 1183: Cleanup x11/RandR javadoc and native/X11RandR13 signature commentsXerxes Rånby2015-08-101-2/+2
|
* Bug 1188, Bug 1186: NEWT Window: Support non-resizable, minimize, maximize, ↵Sven Gothel2015-08-109-399/+914
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1176: BCM VC IV: Refine clamping of window position and size at native ↵Sven Gothel2015-07-171-2/+0
| | | | | | | | | | | | | | | 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.
* Bug 1176: Clamp window position and size to 0/0 and screen-size, avoiding ↵Sven Gothel2015-07-171-1/+3
| | | | | | | | | | | | | 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.
* Bug 1148 - OSX MonitorDevice: Use unique and native deviceID instead of indexSven Gothel2015-03-212-46/+80
| | | | | | | | | | | | | 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.
* Bug 1147 - Fix XRandR13 Usage: Rotate / Change-Mode, use unique CRTC/Mode ↵Sven Gothel2015-03-207-133/+591
| | | | | | | | | | | | | | | | | | | | | 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.
* Bug 1142 - NEWT: Add support to retrieve the primary MonitorDeviceSven Gothel2015-03-094-33/+77
| | | | | | | | | | | | | | | | | 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.
* Bug 1135 - Cleanup: Fix native code WarningSven Gothel2015-03-064-5/+5
|
* NEWT MonitorDevice: Identify cloned devices (fully covered) ; Windows: ↵Sven Gothel2015-02-174-47/+44
| | | | | | | | | | | | | | | | | | | 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
* Bug 1129 - NEWT MonitorDevice's physical size on Windows must be read via EDIDSven Gothel2015-02-163-37/+580
| | | | | | | | | | | | | | | | | | | 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.
* Bug 682 - Relocating javax.media.opengl.* -> com.jogamp.opengl.* (Part 1)Sven Gothel2015-02-021-2/+2
| | | | | | | | | 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/**
* Bug 1120 - Refine HiDPI Support ( Part-2 ) (API CHANGE)Sven Gothel2015-01-272-7/+17
| | | | | | | | | | | | | | | | | | | | | | - 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.
* Bug 1065: Handle NULL result of TISGetInputSourceProperty(keyboard, ↵v2.2.1Sven Gothel2014-09-081-2/+7
| | | | kTISPropertyUnicodeKeyLayoutData), avoiding crash
* Bug 741 HiDPI: Add ScalableSurface.getNativeSurfaceScale(..) to compute ↵Sven Gothel2014-06-091-5/+5
| | | | | | | | | | | | | | 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 ..
* Bug 741 HiDPI: Add ScalableSurface interface to get/set pixelScale w/ full ↵Sven Gothel2014-06-082-18/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Bug 1012: Fix erroneous handling of multiple monitor coordinates on OSX with ↵Sven Gothel2014-05-261-19/+52
| | | | | | | | | | | 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).
* Bug 741 HiDPI: Refine Monitor/Screen [virtual] Viewport Definition / Add ↵Sven Gothel2014-05-266-63/+141
| | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 01:51:19 +0000