Bug 1373 - Support High-DPI across Platforms and Modules
Summary: Support High-DPI across Platforms and Modules
Status: IN_PROGRESS
Alias: None
Product: General
Classification: JogAmp
Component: generic (show other bugs)
Version: 2.5.0
Hardware: All all
: P4 major
Assignee: Sven Gothel
URL:
Depends on: 1322 1374 741 1120 1130 1351 1358 1421 1422
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-04 21:00 CEST by Sven Gothel
Modified: 2023-02-02 23:48 CET (History)
0 users

See Also:
Type: FEATURE
SCM Refs:
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 21:00:49 CEST

    
Comment 1 Sven Gothel 2019-04-04 23:45:24 CEST
It shall be noted that the overall High-DPI problem only exists
due to applications using fixed dimensions in pixel-space
instead of using normalized vectors, millimeters and actual DPI.

With the availability of high resolution monitors beyond 
the historical ~80 dpi capability, 
High-DPI screens of 160 dpi and higher became available.

Hence pixel sized artifacts and whole windows were 'shrunk' 
when based on ~80 dpi screens by: 160/80 on both dimensions.
Meaning the content was cut to quarter size roughly in total.

Hence Apple introduced their 'pixelScale' to their OSX with the 
advent of their first High-DPI screen Retina.
They simply set 'pixelScale' to 2 to multiply the window dimensions
and even created a mode to scale the pixel framebuffer content 
to the actual double sized framebuffer target. 
The latter soothed the GPU requirements as their performance was lagging
the boosted DPI. GPU's would need to cover 4x more pixels.

Today this should not matter really anymore
and users are advised to use a 'good' screen layout based 
on the monitor size and DPI.
The content should be rendered at native full resolution of course,
which also helps with natural anti-aliasing.

However, many OS and toolkit API's are using a fixed 90 DPI pixel based 
layout optionally or by default.

Hence our NativeWindow specification uses 'window units':
  /**
   * Returns the width of the client area excluding insets (window decorations) in window units.
   * @return width of the client area in window units
   * @see NativeSurface#getSurfaceWidth()
   */
  public int getWidth();

and our NativeSurface is using actual 'pixel units'
  /**
   * Returns the width of the client area excluding insets (window decorations) in pixel units.
   * @return width of the client area in pixel units
   * @see NativeWindow#getWidth()
   * @see #convertToWindowUnits(int[])
   */
  public int getSurfaceWidth();

+++

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.

+++

See also: AWT Java 9+ related: 'JEP 263: HiDPI Graphics on Windows and Linux' 
https://bugs.openjdk.java.net/browse/JDK-8055212
Comment 2 Sven Gothel 2023-02-02 23:46:48 CET
We have added support for Windows and X11,
reading the respective UI 'soft' scale factor of the respective 
OS setting as explained in Bug 1374 Comment 7.

Remaining task would be the following,
noted in Bug 1374 Comment 12:

+++

Requirement of mapping window-units  <-> pixel-units
taking the monitor viewport layout into account.

X11/Windows: A simple scaling of the window-units position is not suitable due to multiple monitors,
i.e. a window-units gap will be created and fullscreen/spanning coordinates will be wrong.

TODO: Implement seamless conversion of units incl. monitor viewport mapping
- X11, Windows: Recalculate monitor window-units viewport (native is pixels)
- MacOS Recalculate monitor pixel-units viewport (native is 'points', aka window-units)

Impact will be to have the ability to use either pixel- or window-units
for positioning and size and hence be fully platform independent.