| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
FPSCounterImpl accuracy by maintaining timestamps in [ns]
Idea: Perhaps we want to use [ns] for FPSCounter's method types by now?
|
|
|
|
| |
eglSwapBuffers(..) already performs this task (TODO: More Tests!)
|
|
|
|
|
|
|
|
| |
newt.ws.mmwidth and newt.ws.mmheight property
This is essential on bare-metal devices where the screen DRM/GBM driver does not provide the screen-size (in mm).
Otherwise we would have resolution/(size_mm=0) infinity density and none of our graph font demos would work,
as we compute pixel-em-size based using dpi and pixel-pt-size.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
original font-units (FU) to have them scaled later ( fu * pixelScale / unitsPerEM )
Scaling from font-units (funits, or FU) is now performed by the renderer itself,
i.e. applying the scale-factor 'fontPixelSize / font.getMetrics().getUnitsPerEM()'
to the PMV matrix to render the whole graph GLRegion.
This finally provides proper device and resolution independent font utilization.
Further, preliminary kerning has been added.
+++
Also ...
TypecastFont:
- getGlyphID(..) getGlyph(..) enforce symbol mapping to Glyph.ID_SPACE Glyph.ID_CR,
as some fonts ave an erroneous cmap (FreeSerif-Regular)
- add getKerning(..)
TODO: Add binary search
- Set TypecastFont.USE_PRESCALED_ADVANCE := false,
i.e. dropping all prescaled pixel-sized advance values mapped to font pixel-size
as we utilize font-units only for later uniform scaling.
- Drop virtual getPixelSize() and add static FontScale.toPixels(..)
- Add fullString() for debugging purposed, including some font tables
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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"
|
|
|
|
|
|
| |
to the root window (global screen) ..
.. otherwise, we might end up receiving a client position of 0/0, while being positioned in a different absolute place within root.
|
|
|
|
| |
object
|
| |
|
|
|
|
| |
for X11 and Windows for now.
|
| |
|
|
|
|
|
|
|
|
| |
WindowDriver, used to call the super class method.
Regression of commit cfc35549810d3a0fb5eeb866c9450417e48cd8a1
Note to myself: You can't enforce a 'this' method call overridden with a virtual from a subclass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
|
|
|
| |
general usage
See MonitorDevice.getOrientationTo(MonitorDevice, int[]) to setup the move_diff
as added in commit 43dc472c4797f34e4079028a5eb04bc420c11c2a
|
|
|
|
|
|
| |
set a custom position additionally to size
This added functionality is desired when adjusting the window position and size when changing the soft-pixel-scale
|
|
|
|
|
|
| |
positionModified[] return value, allowing to not wait for the previous custom position
This is required if createNativeImpl(..) modifies the target position, i.e. due to soft-pixel-scale.
|
|
|
|
|
|
|
|
|
|
|
|
| |
determine the orientation of this monitor to the other incl. the 'move_diff'
move_diff int[2] to store the move delta for each axis from this-monitor to the other
This will be utilized when a NEWT window moved across monitors to signal the move_diff,
which helps to properly adjust the new position.
Tested: All 4 monitor crossings right_of, left_of, above and below.
TODO: Test and support a 'diagonal' move, i.e. move_diff on both axis.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Add 64-bit nativeHandle (Windows HMONITOR), add PixelScale for Windows
|
|
|
|
| |
callbacks ..
|
|
|
|
| |
deadlock)
|
|
|
|
| |
null com.jogamp.newt.swt.NewtCanvasSWT.access$200(com.jogamp.newt.swt.NewtCanvasSWT)
|
|
|
|
| |
Cannot invoke "com.jogamp.newt.Window.getDelegatedWindow()" because the return value of "com.jogamp.newt.swt.NewtCanvasSWT.access$200(com.jogamp.newt.swt.NewtCanvasSWT)" is null
|
| |
|
|
|
|
|
|
|
| |
TSMGetInputSourceProperty(), crashing on MacOS >= 13
Perhaps we want a replacement?
Fallback code uses keyCode, i.e. dropping the current keyboard layout (-> US).
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native DPI toolkit aware platforms (Linux, Windows)
NEWT + NewtCanvasAWT:
Maybe create "interface ScalableSurface.Upstream {
void pixelScaleChangeNotify(final float[] curPixelScale, final float[] minPixelScale, final float[] maxPixelScale); }"
to allow downstream to notify upstream ScalableSurface implementations like NEWT's Window to act accordingly.
+++
AWT GLCanvas: Add remark where to add the potential pixel scale.
|
|
|
|
|
|
| |
fullscreen mode
WindowDriver OSX: useParent(..) -> useParentLocation(..) and add !isFullscreen() as a criteria to use the parent derived location.
|
|
|
|
| |
input if not visible.
|
|
|
|
|
|
|
|
| |
NewtCanvasSWT.SWTNativeWindow's surfaceSize in pixel units
shall only return scaled-up windowUnits using SWTAccessor.deviceZoomScaleUp(..) for !OSX
and potentially auto scaled-up pixelUnits to passthrough (OSX).
See detailed API doc to NewtCanvasSWT.newtScaleUp(..)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
| |
toString(..), added toSimpleString(..)
This also revised commit f56adf14deadd4ee8f434ea1293e27bcafdf2a90 Window API addition of 'append(StringBuilder)',
which has been renamed to 'toString(StringBuilder)' as aligned to out other classes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);'
|
|
|
|
|
|
|
| |
off-viewport position
Ensure it stays out of sight by moving it to 2x width/height of viewport.
Otherwise one could see the child window moving from lower-right to upper-left ;-)
|
|
|
|
|
|
| |
remove all SWT listener on dispose.
Additionally print more details about the newtChild's state in DEBUG mode.
|
|
|
|
| |
building custom efficient presentations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'Fake invisible child window' is implemented by simply moving the window out of sight (viewport).
- orderOut0 needs to use '[mWin orderWindow: NSWindowBelow relativeTo:..' parentWindow
instead of '[mWin orderBack:..', otherwise the whole parent application gets invisible w/ SWT ;-)
- NewtNSWindow may also needs to use parent's Screen instance if moved offscreen,
as the own Screen is invalid (zero size) in this case.
- WindowDriver: Adding special treatment for 'Fake invisible child window' (tagged as such):
-- reconfigureWindowImpl: setWindowClientTopLeftPointAndSize0(..) will be called
using the viewport's max position -> out of sight.
-- screenPositionChanged: ignore the 'new' position
-- sizeChanged: ignore the 'new' size
This sensitive NEWT change set shall benefit other toolkits being used as parentWindow
besides SWT, as this behavior is the same across MacOS.
|
|
|
|
|
|
|
|
|
|
| |
d92dc518eb891f2d125a8136efd6ed603d74a6e9
We also cannot use 'mWin orderWindow: NSWindowOut relativeTo:..]' as it also removes the child-NSWindow from its parent like 'orderOut'.
Hence only use 'orderBack' to keep the relationship inplace.
Fake invisible child window is in progress,
i.e. moving it out of the overal viewport (all screens).
|
| |
|
|
|
|
| |
reconfig: Only orderOut w/ valid window-handle
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commenting on child-window orderOut
Actual small change is to have child-NSWindow to use '[myWindow orderWindow: NSWindowAbove relativeTo:..'
instead of 'orderFront' in creation and use the simple 'orderFront' to set a top-level NSWindow visible.
Adding comment why we can't use 'orderOut' on child-NSWindow setting it invisible,
this is due to OSX 10.7 changes and testing detaching the child-window from its parent
causes havoc w/ SWT at least.
Hence we only issue 'mWin orderWindow: NSWindowOut relativeTo:..]' and the result is
having the child-NSWindow below the application.
This in turn will make it visible again when moving the application around,
as this child-NSWindow will no more follow the position.
Suggestion is to have this 'fake invisible' child-NSWindow to be moved
out of the overal viewport (all screens).
|
|
|
|
|
| |
Show and Hide handling resolves TabFolder layout,
i.e. hiding the 'hidden' and showing the current tab.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
b91c680fb93a03720ff9fcb39cf052cfe8d40e76
See commit b91c680fb93a03720ff9fcb39cf052cfe8d40e76
To support static libraries JEP 178, we have to provide JNI_OnLoad_<libname> etc.
Hence change and add function entries accordingly.
|
|
|
|
|
|
| |
This also demonstrates that on non MacOS, SWT's scale-factor is artificially imposed
on the actual pixel-units, as SWT's getClientArea() is simply returning:
DPIUtil.autoScaleDown(getClientAreaInPixels())
|