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