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: tbd
Hardware: All all
: P4 major
Assignee: Sven Gothel
URL:
Depends on: 1322 1351 1374 741 1120 1130 1358
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-04 21:00 CEST by Sven Gothel
Modified: 2019-04-04 23:47 CEST (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