aboutsummaryrefslogtreecommitdiffstats
path: root/src/nativewindow
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1430 - Fix Background erase not disabled with AWT GLCanvas and NewtCanvasAWTSven Gothel2023-09-291-8/+95
| | | | | | | | | | Commit c5431f46b7bf64f109315ec78461859dd88f202a reduced the disableBackgroundErase(..) to SunToolkit's variation which doesn't work on Windows as it does not act upon the java.awt.Canvas peer post addNotify(). This re-introduces the java.awt.Canvas method via class JAWTUtil.BackgroundEraseControl and its called only after addNotify() on Windows and ASAP for everyone else. Method also calles the SunTookit variation just to be sure.
* Adopt to GlueGen Struct API Change get/set array argumentsSven Gothel2023-06-161-2/+3
|
* HiDPI: Revise AWT GLCanvas/GLJPanel ScalableSurface: No setSurfaceScale(), ↵Sven Gothel2023-05-154-52/+74
| | | | | | | | | | | have AWT toolkit define pixelScale only (simplification) This aligns with Glenn's initial AWT patch commit e5e7514d649cd7dd28bbb8e04b72338dc09c2c83, i.e. removing redundancies... Tested on Linux, Windows and MacOS w/ GLCanvas, GLJPanel and GLWindow using pixelScale values: - Linux: 1, 2 - Windows: 1, 1.25, 2 - MacOS: 1, 2
* SurfaceScaleUtils: Remove unused isZero(..)Sven Gothel2023-05-141-9/+0
|
* HiDPI AWT/NEWT: Propagate AWT enforced pixelScale via setSurfaceScale() ↵Sven Gothel2023-05-142-5/+26
| | | | blocking native change by monitor-pixelScale (Windows, X11)
* Nativewindow OSXmisc.m: Minor cleanupSven Gothel2023-05-061-18/+19
|
* Merge pull request #110 from gbburkhardt/masterGöthel Software2023-03-081-0/+1
|\ | | | | Fix for AWT GLCcanvas DPI scaling. Forum thread https://forum.jogamp…
| * Fix for AWT GLCcanvas DPI scaling. Forum thread ↵Glenn Burkhardt2023-03-061-0/+1
| | | | | | | | https://forum.jogamp.org/DPI-scaling-not-working-td4042206.html
* | [GL]Capabilities*: Enhance identity-check in root Capabilities.equals(..), ↵Sven Gothel2023-03-085-6/+85
|/ | | | | | | | | | comparing the VisualID first; Added VisualIDHolder.isVisualIDSupported(VIDType) We cannot accept 2 capabilities with different VisualID but same attributes otherwise accepted as equal, since the underlying windowing system uniquely identifies them via their VisualID. Such comparison is used in certail GLAutoDrawable implementations like AWT GLCanvas to determine a configuration change etc.
* GLDrawableFactoryImpl:createDummyDrawable(): Similar to ↵Sven Gothel2023-03-041-8/+1
| | | | | | createOffscreenDrawable() prefer createSurfacelessImpl() over createDummySurfaceImpl() to reduce resources (no actual window) This enhances the 'dummy drawable' use-case implementation, i.e. for shared context.
* EGLGraphicsDevice: Cleanup and enhance API doc for clarity ...Sven Gothel2023-03-043-25/+131
|
* Drop redundant NativeWindowFactory.getDefaultToolkitLock(type, deviceHandle) ↵Sven Gothel2023-03-023-22/+5
| | | | variant
* NEWT Soft-PixelScale (p7): get{Global->}PixelScaleEnv(..): Support per ↵v2.4.0Sven Gothel2023-01-311-18/+82
| | | | | | | | | | | | | | | | | monitor values w/ QT_SCREEN_SCALE_FACTORS syntax, use for X11 Per-monitor values are parsed if value is not a float and stored in a given Map<String,float[2]>, parallel to a detected global_pixel_scale_xy. The per-monitor value syntax matches QT_SCREEN_SCALE_FACTORS, i.e. the regular expression '(<string>=<float>;)+', e.g. QT_SCREEN_SCALE_FACTORS='DP-1=1.25;DP-2=1.25;HDMI-1=1.25;' The per-monitor value is preferred and on X11 stored within the MonitorDevice, matching the MonitorDevice's name. The following env-var names are searched on X11: "QT_SCREEN_SCALE_FACTORS", "QT_SCALE_FACTOR", "GDK_SCALE", "SOFT_SCALE"
* NEWT Soft-PixelScale (p6): Implement Soft-PixelScale for X11 and Windows ... ↵Sven Gothel2023-01-311-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (working state) Both: - Using Soft-PixelScale mode, i.e. converting all given window-units to pixel-units for native GDI/X11 ops - Using scaled pixel-sized surface - Adjusting NEWT's Monitor's window-unit viewport value to pixel-scale For X11: - Using global scale factor from environment variable, either: "GDK_SCALE", "QT_SCALE_FACTOR" or "SOFT_SCALE". The latter is for testing only. See https://wiki.archlinux.org/title/HiDPI For Windows: - Using actual monitor's pixel-scale via native SHC API (Shellscaling API, shcore.dll) Misc: - SurfaceScaleUtils.getGlobalPixelScaleEnv() reads a float value from given env names, first come, first serve - MonitorModeProps.streamInMonitorDevice(..): Add `invscale_wuviewport` argument to scale wuvieport for soft-pixel-scale - TestGearsNEWT: Enhance GL2 demo to be suitable for manual tests, this since my Windows KVM machine doesn't support ES2 - TestGLContextDrawableSwitch10NEWT: Add a few more test constraints .. working Tested: - Manually on a Windows virtual machine (KVM) using - 2 virtualized 'Video QXL' cards and - and 'remote-viewer' to see the 2 monitors since `Virtual Machine Manager` build-in doesn't support - remote-viewer spice://localhost:5917 - Manually on a Linux machine w/ SOFT_SCALE - Both, X11 and Windows - Place window on each monitor - Move window across monitors w/ pixel-scale change (or not) - TODO: Test and fix utilization with AWT, i.e. NewtCanvasAWT
* NEWT Soft-PixelScale (p1): WindowImpl: Separate window and pixel units for ↵Sven Gothel2023-01-311-0/+30
| | | | | | | | | | | | | | | size and position via atomic-replacable int arrays NEWT's Soft-PixelScale supports software pixel-scale by multiplying the underlying surface pixel-size with the scale-factor and dividing the window position and size by same scale-factor. Hence the window position and size space is kept virtually steady at virtually assumed DPI 96 at higher actual screen DPI and the surface size is adjusted. +++ This window- and pixel-unit separation also includes all callbacks for the native driver implementations, hence the changes native code - allowing to determine whether window- or pixel-units were given.
* Fix NewtFactoryAWT: screen.getMonitor(..) -> screen.getMonitorById(..); Misc ↵Sven Gothel2023-01-312-6/+2
| | | | | | | | | | left-over changes .. GDIUtil: Remove uncommented GetMonitorPixelScale(..) point variant JAWTUtil: Clarify Java version comment w/ spacing NEWT Display.getThreadName(): Return 'Thread[0x<hash-value>, <name>]' NEWT Screen: Add getFullyEnteredMonitor(..) NewtCanvasAWT: @SuppressWarnings for determineIfApplet() and use FQN within method
* NativeWindow: Add getBounds() (moved from NEWT Window) and getSurfaceBounds()Sven Gothel2023-01-315-26/+68
|
* Nativewindow Rectangle*: Add contains, scale*(float..) and make ↵Sven Gothel2023-01-312-17/+71
| | | | union(List<Rectangle*>) public; Fix union/intersection 'off-by-1' for pos2.
* GDIUtil: Add GetMonitor*() variants incl. PixelScale (Part-2, adding missing ↵Sven Gothel2023-01-312-0/+106
| | | | | | native header and code files) Part-1 in commit e96aeb6e9acd2b1435f5fad244a1488e74a3a6d6
* GDIUtil: Add GetMonitor*() variants incl. PixelScale; NEWT MonitorDevice: ↵Sven Gothel2023-01-291-0/+22
| | | | Add 64-bit nativeHandle (Windows HMONITOR), add PixelScale for Windows
* SWTAccessor.invokeOnOSTKThread(): Fix comment ..Sven Gothel2023-01-221-2/+1
|
* MacOS: JAWTWindow: Complete MacOS 12+ SIGSEGV JAW Crash Fix; This: Destroy ↵Sven Gothel2023-01-221-5/+12
| | | | | | | | | | | | | | | NSWindow on MacOS main-thread Destroy NSWindow on MacOS main-thread, avoiding spurious more rare SIGSEGV on MacOS 13/aarch64 This closes the MacOS 12+ SIGSEGV JAWT (CALayer) crash fix, see commits: - 4009198e34b50bba9582be24f33eaf83b94a2cb8 - 3c4cf1f37dc27d8d527804d195361a2287575147 - d969f473fdc72c6ca95f1796ff5af3f0c8bd51b6 - 81f395975c06a66183ad36cc43e8dc9bc7f4545b - b8977465b2fb8452c2560a5d2561b2561472edf0 - 470a0ff3a2efbe43404d5f80a403efb38005598a - 9829550f5bcb586f94f98f6d3c39f4d78fd78f3b
* MacOS: JAWTWindow.invalidateNative(): Use copied references in off-thread ↵Sven Gothel2023-01-221-10/+12
| | | | | | operations and zero source references upfront. Have user being aware of disposal then triggered and not later when performed on MacOS main-thread
* MacOS: JAWTWindow's OffscreeLayer: Show semantics in argument names and ↵Sven Gothel2023-01-222-17/+19
| | | | complete null checks in detachSurfaceLayerImpl(), setSurfaceScale()
* MacOS: JAWTWindow.layoutSurfaceLayerImpl(): Perform ↵Sven Gothel2023-01-222-6/+14
| | | | OSXUtil.FixCALayerLayout() on main thread and hence fetch and validate getAttachedSurfaceLayer() when needed
* OSXMisc.m: Show semantics: caLayer -> rootCALayerSven Gothel2023-01-221-15/+14
|
* JAWTWindow.ctor: Initialize offscreenSurfaceLayer before useSven Gothel2023-01-211-1/+1
|
* JAWTWindow.invalidateNative() and .detachSurfaceLayerImpl(): Pass copy of ↵Sven Gothel2023-01-214-15/+17
| | | | offscreenSurfaceLayer for pending off-thread operation and immediately zero reference marking its future destruction.
* Don't import conditional platform specific 'static' code but fully qualify ↵Sven Gothel2023-01-201-32/+18
| | | | names when in use, make Android d8 (Dex'ing) happy
* JAWTWindow: Constrain AppContextInfo creation where offscreen layer is ↵Sven Gothel2023-01-182-2/+13
| | | | supported (MacOS only)
* JAWTWindow: Remove java.applet.Applet detection .. it's gone :-(Sven Gothel2023-01-181-8/+12
|
* SWT+AWT: Ensure SWTAccessor gets called before AWT initialization on GTK/X11 ↵Sven Gothel2023-01-161-0/+12
| | | | to avoid "cannot register existing type 'GdkDisplayManager'" and subsequent SIGSEGV
* SWTAccessor: Adopt to SWT 4.26Sven Gothel2023-01-161-32/+27
|
* Merge pull request #108 from PeterC-DLS/swt-420-fixSven Gothel2023-01-161-1/+9
|\ | | | | Add new class location of SWT's gtk_widget_get_window
| * Add new class location of SWT's gtk_widget_get_windowPeter Chang2022-04-141-1/+9
| | | | | | | | | | | | | | In SWT version 4.20, some gtk methods moved to a new gtk3 subpackage so add check and find it in there. Note, this new package was not exported until SWT 4.23 (aka 3.119.0 or v4950) so intervening versions will not work when using OSGi class loading.
* | JAWTUtil: Cleanup MacOS JVM and OS version flags: Private and store ↵Sven Gothel2023-01-151-14/+16
| | | | | | | | comparison result
* | Replace AccessController.doPrivileged() w/ SecurityUtil.doPrivileged()Sven Gothel2023-01-1413-28/+30
|/
* Bug 1398: Expose NativeSurface implementation's RecursiveLock if utilizedSven Gothel2020-03-052-0/+24
| | | | This prepares proper release of the acquired NativeSurface lock to cure the missing CGLContext lock, see followup commit.
* OSX/SWT Testing: Drop using 'com.jogamp.newt.util.MainThread' enforcing ↵Sven Gothel2020-03-041-13/+21
| | | | | | | | | | | | | | | | | | | default test behavior SWT and OSX's UI TK have their strict threading policy we require to comply with, e.g. see Bug 1398 lately. It doesn't help using our own MainThread vehicle to move the unit test on the OS main thread, as this removes potential causes of deadlocks - which we intend to find and resolve. This patch removed using MainThread altogether from our ant unit testing recipe as well from our manual test scripts. Unit tests are no more executed on the 'main thread'. SWT tests are patched to comply with SWT's UI threading policy. We also catch violations within NewtCanvasSWT and our SWT GLCanvas to provide same behavior on all platforms.
* IOSUtil.IsMainThread(): Utilize caching ThreadLocal<Boolean> like OSXUtil's ↵Sven Gothel2020-02-241-1/+17
| | | | variant.
* Bug 1422: Use own deviceZoomScaleUp(..) disregarding higher-toolkit's ↵Sven Gothel2020-01-161-10/+144
| | | | | | | | | | | | | | | | | | | compensation like 'DPIUtil.useCairoAutoScale()' We can't use DPIUtil's 'autoScaleUp(..)' method on non-native DPI scaling platforms as it uses a scale-factor of 1f if the higher toolkit compensates, i.e. 'DPIUtil.useCairoAutoScale()'. Since NEWT uses X11 and GDI directly, which are not DPI scale-aware, we have to drop the semnatics of 'DPIUtil.useCairoAutoScale()' and merely use the actual 'deviceZoom'. This was proposed by Marcel Au in the first place. At least I understand these semantics by now. +++ Additionally NewtCanvasSWT.SWTNativeWindow needs to return the 'deviceZoomScaleUp(..)' values for returning its size in window- and pixel-units (surface).
* Bug 1422: Emulate DPI Scaling on non-native DPI autoscale platforms (!MacOS)Sven Gothel2020-01-151-5/+43
| | | | | | | | | | | | | | | | | | | | | | | | Bug 1422 shows that it seems to be desired to emulate DPI scaling where the native toolkit does not implmement the same. On GTK, DPIUtil.mapDPIToZoom (int dpi) reads: double zoom = (double) dpi * 100 / 96; int roundedZoom = (int) Math.round (zoom); return roundedZoom; While having dpi calculated as: dpi = 96 * GDK.gdk_monitor_get_scale_factor(monitor); Well, this seems to exist to allow 96 dpi fixed layout to 'look' OK on high-dpi screens. However, you get in trouble if you layout high-dpi aware, i.e. using percentages etc. There is one exception: If DPIUtil.useCairoAutoScale() is true, scalingFactor is 1f and hence the scaling emulation dropped. 'DPIUtil.setUseCairoAutoScale((sx[0]*100) == scaleFactor || OS.isGNOME);'
* Nativewindow Rectangle*: Cleanup up union(..), intersection(..): Return a ↵Sven Gothel2020-01-152-26/+21
| | | | | | new Rectangle instance (mutable) Also return 'this' for setter methods for chaining.
* Bug 1421, Bug 1358, Bug 969, Bug 672: Fix NEWT's coordinate conversion on ↵Sven Gothel2020-01-133-74/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | MacOS (fixes NewtCanvasSWT on SWT positioning) Newt's OSX Window consist out of NSView wrapped up within its own NSWindow. It's position is being set via its NSWindow's client-area position on screen (frame), which we derive from NSView's client-area position. When NEWT reparents into a new 'window', on OSX it uses the parent's NSView and its NSWindow to attach its own NSView and NSWindow as a subview and childwindow. SWT's OSX implementation uses NSView's for each Compositor, but an individual NSWindow is only established for the Shell (Window). An oversight in Nativewindow and NEWT's coordinate translation: 'top-left view <-> top-left screen' by missing the 'view <-> window' translation caused this whole issue. The oversight occured as NEWT's 'view <-> window' translation had no impact due to its 1-view to 1-window mapping. Fixing the coordinate translation resolves the mess for SWT and for potential other toolkits on OSX. NewtCanvasSWT behaves same on OSX as on X11 etc finally.
* NativeWindow Point.set*(..): Return instance for scaling (chaining)Sven Gothel2020-01-121-3/+19
|
* Bug 1421: OSXUtil: Add GetLocation(..), simply returning the view's frame ↵Sven Gothel2020-01-062-0/+44
| | | | position
* Bug 1358: GLCanvas: Call new OSXUtil.SetWindowPixelScale(..) when GLCanvas ↵Sven Gothel2020-01-052-3/+43
| | | | | | gets realized on MacOS This fixes GLCanvas's High-DPI scaled size issue on MacOS of Bug 1358.
* Bug 1421, Bug 1358, Bug 969, Bug 672: SWTAccessor: Add ↵Sven Gothel2020-01-051-1/+74
| | | | get[Location|Size]InPixels(..) and getLocationOnScreen()
* Bug 1358: Add OSXUtil.GetWindowPixelScale(..)Sven Gothel2020-01-042-1/+52
| | | | | It is now possible to retrieve the pixel scale [NSWindow backingScaleFactor] after native creation by NEWT - as we have changed the lifecycly (all-in-one native method on AppKit)
* Merge remote-tracking branch 'xranby/master'Sven Gothel2019-12-041-4/+14
|\
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 07:50:06 +0000