Bug 1373

Summary: Support High-DPI across Platforms and Modules
Product: [JogAmp] General Reporter: Sven Gothel <sgothel>
Component: genericAssignee: Sven Gothel <sgothel>
Status: IN_PROGRESS ---    
Severity: major    
Priority: P4    
Version: tbd   
Hardware: All   
OS: all   
Workaround: ---
Bug Depends on: 1322, 1374, 741, 1120, 1130, 1351, 1358, 1421, 1422    
Bug Blocks:    

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'