| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
blocking native change by monitor-pixelScale (Windows, X11)
|
|\
| |
| | |
Fix for AWT GLCcanvas DPI scaling. Forum thread https://forum.jogamp…
|
| |
| |
| |
| | |
https://forum.jogamp.org/DPI-scaling-not-working-td4042206.html
|
|/
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
createOffscreenDrawable() prefer createSurfacelessImpl() over createDummySurfaceImpl() to reduce resources (no actual window)
This enhances the 'dummy drawable' use-case implementation, i.e. for shared context.
|
| |
|
|
|
|
| |
variant
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
union(List<Rectangle*>) public; Fix union/intersection 'off-by-1' for pos2.
|
|
|
|
| |
Add 64-bit nativeHandle (Windows HMONITOR), add PixelScale for Windows
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
operations and zero source references upfront.
Have user being aware of disposal then triggered and not later when performed on MacOS main-thread
|
|
|
|
| |
complete null checks in detachSurfaceLayerImpl(), setSurfaceScale()
|
|
|
|
| |
OSXUtil.FixCALayerLayout() on main thread and hence fetch and validate getAttachedSurfaceLayer() when needed
|
| |
|
|
|
|
| |
offscreenSurfaceLayer for pending off-thread operation and immediately zero reference marking its future destruction.
|
|
|
|
| |
names when in use, make Android d8 (Dex'ing) happy
|
|
|
|
| |
supported (MacOS only)
|
| |
|
|
|
|
| |
to avoid "cannot register existing type 'GdkDisplayManager'" and subsequent SIGSEGV
|
| |
|
|\
| |
| | |
Add new class location of SWT's gtk_widget_get_window
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
comparison result
|
|/ |
|
|
|
|
| |
This prepares proper release of the acquired NativeSurface lock to cure the missing CGLContext lock, see followup commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
variant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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);'
|
|
|
|
|
|
| |
new Rectangle instance (mutable)
Also return 'this' for setter methods for chaining.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
position
|
|
|
|
|
|
| |
gets realized on MacOS
This fixes GLCanvas's High-DPI scaled size issue on MacOS of Bug 1358.
|
|
|
|
| |
get[Location|Size]InPixels(..) and getLocationOnScreen()
|
|
|
|
|
| |
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)
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Broadcom VC IV can be used from
both console and from inside X11
When used from inside X11
rendering is done on an DispmanX overlay surface
while keeping an X11 nativewindow under as input.
When Broadcom VC IV is guessed
only the Broadcom DispmanX EGL driver is loaded.
Therefore standard TYPE_X11 EGL can not be used.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is the desired one)
First issue was that the proper DRM file had to be queries,
as Raspberry 4 may have two of them:
<--
/dev/dri/dri0
/dev/dri/dri0
/dev/dri/by-path/platform-fec00000.v3d-card -> ../card0
/dev/dri/by-path/platform-soc:gpu-card -> ../card1
-->
This patch attempts to probe all /dev/dri/card[0..99]
using this arbitrary range.
The test loop ends if:
- drmOpenFile succeeds and drmModeGetResources delivers non-null value
- the iterated probed file doesn't even exist
- 100 files has been tested ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding new classes DRMLib (gluegen of drm + gbm), DRMUtil and DRMMode GBMDummyUpstreamSurfaceHook
to new package jogamp.nativewindow.drm, allowing full awareness of DRM + GBM within NativeWindow for JOGL + NEWT.
DRMMode replaces the previous native code of collecting drmMode* attributes: active connector, used mode, encoder etc
and also supports multiple active connectors.
DRMUtil handles the global static drmFd (file descriptor), currently only the GNU/Linux DRM device is supported.
GBMDummyUpstreamSurfaceHook provides a simple dummy GBM surface.
NativeWindow provides the new nativewindow_drm.so and nativewindow-os-drm.jar,
which are included in most 'all' jar packages.
build property: setup.addNativeEGLGBM -> setup.addNativeDRMGBM
Changes NativeWindowFactory:
- TYPE_EGL_GBM -> TYPE_DRM_GBM while keeping the package ID of '.egl.gbm' for NEWT (using EGL)
- Initializing DRMUtil at initialization
Changes EGLDrawableFactory:
- Using native GBM device for the default EGL display creation instead of EGL_DEFAULT_DISPLAY.
This resolves issues as seen in Bug 1402, as well in cases w/o surfaceless support.
- GL profile mapping uses surfaceless when available for GBM,
otherwise uses createDummySurfaceImpl (dummy GBM surface via GBMDummyUpstreamSurfaceHook)
- createDummySurfaceImpl uses a dummy GBM surface via GBMDummyUpstreamSurfaceHook
- DesktopGL not available with GBM, see Bug 1401
NEWT's DRM + GBM + EGL Driver
- Using DRMLib, DRMUtil and DRMMode, removed most native code but WindowDriver swapBuffer
- ScreenDriver uses DRMMode, however currently only first connected CRT.
- WindowDriver aligns position and size to screen, positions other than 0/0 causes DRM failure
- WindowDriver reconfigure n/a
NEWT TODO:
- DRM Cursor support (mouse pointer)
- Pointer event handling
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- EGLSurface: Factor out 'eglCreate[Platform]WindowSurface'
NEWT egl.gbm.WindowDriver
-- Properly use GBM fourcc format and use as visualID
for GBM surface creation and EGL config selection
-- Create eglSurface within this class
-- Hook up GBM/DRM page flip (not working yet, no visible artifacts - no swap)
- ProxySurfaceImpl.surfaceSwap() call upstreamSurface's implementation if available
TODO: 'Permission denied' calling:
- drmSetMaster (optional)
- drmModeSetCrtc
- drmModePageFlip
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
according to Bug 1156
- Special files like '/dev/dri/card0' can't be tested via isFile(), use exists()
Order for GNU/Linux (and other unices) IMHO is
1) Display Server (Vendor neutral)
1.1) running X11 display server (DISPLAY check enough?)
1.2) running WAYLAND display server (WAYLAND_DISPLAY check enough?)
2) Console Mode Vendor Neutral
2.1) GBM (how to check?)
3) Console Mode Vendor Specific
3.1) VCIV (how to check)
|