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 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'
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.