Bug 1374 - Support High-DPI for JRE>8 AWT on Windows, MacOSX and Linux
: Support High-DPI for JRE>8 AWT on Windows, MacOSX and Linux
Status: IN_PROGRESS
: None
: Jogl
: JogAmp
: awt (show other bugs)
: 2.4.0
: All all
: P4 major
: Sven Gothel
:
:
: 1373 1404
  Show dependency treegraph
 
Reported: 2019-04-04 23:47 CEST by Sven Gothel
Modified: 2020-01-22 10:03 CET (History)
5 users (show)

:
Type: DEFECT
SCM Refs:
c7858dc766cb9f76ac8f543796b1587a0f8f9279 24b75b2e91ec5f101b19fa24aa3804adb3819ebf 7ec068e0c95a230101450cc80031f76770a0cd49 ba83a59363023ba0cc314746d7864ccf2cdd4d7a
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2019-04-04 23:47:25 CEST
See Bug 1373 Comment 1

+++

See AWT Java 9+ related: 'JEP 263: HiDPI Graphics on Windows and Linux' 
https://bugs.openjdk.java.net/browse/JDK-8055212

+++

OSX uses a monitor related 'float[2] pixelScale', 
which we have adopted in bug 1120 and OSX High-DPI fix in bug 741.

Our groundwork for High-DPI support indeed has been done for bug 741.

AWT on OSX should work appropriately based on fixed for bug 741 and bug 1120.

+++

AWT on Linux may use the environment variable GDK_SCALE for both dimensions.

+++

AWT on Windows may use the DPI override.
Comment 2 Sven Gothel 2019-11-30 19:05:48 CET
c7858dc766cb9f76ac8f543796b1587a0f8f9279
    Bug 1363: Java 11: Don't use GraphicsDevice.getScaleFactor() on Java9+ [illegal reflective access]
    
    Use non-reflective method to get the pixel scale on Java9+
    
    It's now possible to use GraphicsConfiguration.getDefaultTransform()
    instead of using reflection to get the pixel scale, which eliminates an
    illegal reflective access warning.
    
    Orig patch by Wade Walker

24b75b2e91ec5f101b19fa24aa3804adb3819ebf
    Bug 1363: Java 11: Use getPixelScale standard method even on Mac under Java9+
    
    Changed getPixelScale to use standard method, even on Mac
    
    Previously it used a Mac-specific method, but the new standard method of
    device.getDefaultConfiguration().getDefaultTransform() seems to work on
    Mac, so use it instead to avoid illegal reflective access warnings.
    
    Orig patch by Wade Walker.

7ec068e0c95a230101450cc80031f76770a0cd49
    Bug 1363: Java 11: Resolve unsupported JAWTUtil.getMonitorDisplayID(..)
    
    Previous commits removed access to OSX's GraphicsDevice.getCGDisplayID()
    on Java9+, avoiding illegal reflective access.
    
    Here we JAWTUtil.getMonitorDisplayID(..) simply returns null
    if Java9 or !OSX, so the sole NewtFactory caller falls back
    to the alternative working solution.
    
    Orig patch Wade Walker:
        This was used on Mac OS only to create a MonitorDevice in
        NewtFactoryAWT. But there was a fallback method for creating
        MonitorDevice, and testing with TestGearsES2GLJPanelAWT shows that the
        fallback method seems to give identical results on Mac, so changed to
        just use the fallback method (which is now the only method) everywhere.
        This gets rid of an illegal reflective access.
Comment 3 Sven Gothel 2020-01-22 09:57:09 CET
While working on the whole tree of Bug 674, in particular Bug 1421, Bug 1422, Bug 1423 and Bug 1424 - I finally 'gave in' to this group of issues.

+++

NEWT itself does not utilize a low level API for 'High-DPI' on certain platforms, namely Windows (GDI) and X11 (Xlib) on GNU/Linux and others.
Let's call these 'non native dpi scaling platforms', see Bug 1422.

Currently only on OSX, NEWT does handle its low level pixelScale from window-units to pixel-units.

+++

In case a higher API tookit imposes some sort of 'dpi scale' 
on said 'non native dpi scaling platforms', both units gets scaled up:
- window units
- pixel units
(See Bug 1422)

In such cases using NEWT, we keep the imposed 'dpi scale'
agnostic to NEWT's native pixel-scale. Here the toolkit wrapper
like NewtCanvasAWT/SWT etc simply scale both units (window- and pixel)
while leaving NEWT's pixel-scale at 1f.

+++

Therefor, we should not only handle such case for SWT (Bug 1422),
but also for the AWT and Swing toolkit in concert with using NEWT 
or plain using our direct AWT/Swing components.

+++

I made some annotations earlier:

commit ba83a59363023ba0cc314746d7864ccf2cdd4d7a

    Bug 1374: NEWT/AWT: Annotation regarding general High-DPI for even non 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.
Comment 4 Sven Gothel 2020-01-22 10:03:24 CET
(In reply to Sven Gothel from comment #3)

In particular, the following finding by Wade allows us to 
react on AWT's detected 'dpi scale' on the non native dpi scaling platforms:

24b75b2e91ec5f101b19fa24aa3804adb3819ebf
    Bug 1363: Java 11: Use getPixelScale standard method even on Mac under Java9+
    
    Changed getPixelScale to use standard method, even on Mac
    
    Previously it used a Mac-specific method, but the new standard method of
    device.getDefaultConfiguration().getDefaultTransform() seems to work on
    Mac, so use it instead to avoid illegal reflective access warnings.
    
    Orig patch by Wade Walker.