JDK-8090569 : Support global coordinate scaling with DPI-based default
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 7u25
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-08-25
  • Updated: 2016-10-19
  • Resolved: 2016-10-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Suggested all-platform solution for "Support for Hi-DPI displays"

JavaFX 2.2 assumes that coordinates are specified in physical screen pixels. Given the broad variety of existing display resolutions, this necessitates laborious manual scaling of layout coordinates, based on DPI or default font size. Otherwise, applications that should run on more than one system risk appearing too large or too small, or even with defective layout when some parts are scaled while others are not. This is what currently happens on Windows, as I've demonstrated with some Oracle tutorials: http://news.kynosarges.org/2013/08/09/javafx-dpi-scaling/

JavaFX 8 introduces automatic coordinate scaling for Mac "Retina" HiDPI mode, but we really need this feature on all platforms. For example, a call such as Screen.setScale could set a scale of Screen.getDpi()/96 by default, and perhaps accept an argument for custom scaling. All coordinates subsequently specified in code, CSS, or FXML should be scaled accordingly, unless the program explicitly disables scaling at some point, e.g. to precisely draw bitmaps.

JavaFX 2.2 on Windows correctly picks up the DPI-scaled default font, correctly scales built-in controls around that font size, and also correctly reports the Screen.getDPI() value. What remains to be done is automatically scaling any explicitly specified coordinates, too, so as to avoid the clash between scaled and unscaled layout parts demonstrated in my linked post.

Note that Windows has supported DPI scaling in this fashion since Windows XP. I'm mentioning this because e.g. https://javafx-jira.kenai.com/browse/RT-27960 seems to assume that DPI scaling is new to Windows 8, but that's merely when this feature gained greater public awareness due to MS Surface Pro defaulting to 144 DPI.

Also note that Windows 8.1 will introduce a new relevant API, namely per-monitor DPI scaling. A global scaling solution for JavaFX should probably this into account and likewise maintain distinct DPI scaling for each screen, if supported by the OS.
This was resolved under JDK-8091832.

Eclipse and LibreOffice seems to respect the Xft.dpi setting, as do Gnome apps. Firefox requires a custom setting. Pidgin seems to trust the inherent X "96 dpi" lie, with no way to adjust it. So it's a bit of a mixed bag, but seeing now that both Eclipse and LibreOffice work, I'm optimistic that following them would be the right path.

Are we doing anything differently than any other application? For example, on Mac with a retina screen all applications show up similarly sized/scaled and some make better use of the resolution (due to internally recognizing the pixel scale and adopting it rather than letting the system employ pixel scaling on their output). If I write a Mac-native app that displays a bunch of text in the default size and I write an FX app to do the same thing, then they generally look the same (scale-wise at least). Before our retina fixes ours looked fuzzier, but dimensionally similar. After our retina work ours looks both crisp and similarly sized. On Windows, our fonts look about the same size as other applications and track the system font size setting. If you run Win7 or Win8 on a retina mac then everything is very tiny in both standard Windows apps and in FX. We are the same there. We could offer a mechanism to make just our apps look larger, but there is no precedent on Win7 for that so we'd be breaking new ground there. On Windows 8 we haven't done as much testing, but many apps also appear tiny there too and so do we. Metro apps are the main ones that might try to scale, but we are not Metro-like. So, on you Linux box, does everything else look nice and normal sized and we are the odd-ball where everything is tiny? If so, then we need to figure out what is driving native apps to scale on that screen and adopt the same conventions. If everything is very tiny including us, then we are breaking new ground here (not that that is bad, but we shouldn't lock ourselves out of tracking the Linux mechanisms for recognizing HiDPI).

I just noticed you asked about my screen size too...it is 13.3". My actual DPI is about 277. There is a Gnome/Unity (not sure which) setting (Display/Scale for menu and title bars), which I have set to 1.62. It seem that adjusting it affects a dpi variable inside X. Here is what happened when I changed that value from 1.62 to 1.5: kevins@940X3G:/etc/X11/xinit$ xrdb -query | grep dpi Xft.dpi: 156 kevins@940X3G:/etc/X11/xinit$ xrdb -query | grep dpi Xft.dpi: 144 Running xrandr shows that the system has everything it needs to compute a "true" DPI: kevins@940X3G:/etc/X11/xinit$ xrandr Screen 0: minimum 320 x 200, current 3200 x 1800, maximum 32767 x 32767 eDP1 connected primary 3200x1800+0+0 (normal left inverted right x axis y axis) 293mm x 165mm ... However, X policy is generally to claim 96 dpi in all cases, so for example I'm seeing this: kevins@940X3G:/etc/X11/xinit$ xdpyinfo | grep resolution resolution: 96x96 dots per inch I hope that helps. Let me know if you want me to run any tests.

I guess what I'm asking is if there is a system setting that says "all windows should be scaled by X". On MacOS, there is a value that can be obtained from the system for "retina-aware" apps so that we are scaling everything the same as other retina-aware apps and by the same amount that a "retina-unaware" app would be pixel-scaled by the system. Windows has a similar convention that we haven't tapped into yet - we do honor the windows font scale setting to modify our CSS concepts of font-based measurements, but we don't do a global graphics scale like the retina "2x" (yet)...

My screen is 3200x1800 ("QHD+"). And I'm on Ubuntu 14.04 (soon to upgrade to 14.10). I am just now starting to learn about DPI issues, having purchased this new laptop a couple days ago. So at this point I don't know enough to help guide you toward a good solution. If it helps, as one example, in Firefox I had to set the layout.css.devPixelsPerPx setting to 2, to get a reasonable size.

Hi Kevin, What resolutions/size is your screen? And, does Linux perform any global scaling already that we should tie into and emulate?

I just wanted to note that this is a Linux issue too (as implied by the "all platforms", but just to make it explicit). I just got a high-res laptop, and would love to see a clean solution for my JavaFX work under Linux. I would be happy to help test.

Note that we used to report a non-1.0 scale on Windows previously (see RT-28260). However, that didn't work quite well, so currently we always report 1.0 scale factor on Windows. Assigning this issue to an expert in HiDPI rendering for evaluation.