Windows support for HiDPI displays, call for feedback and testing

[Jim Graham]

https://jdk8.java.net/download.html

The 8u60 b17 build should now contain changes recently made to support 
HiDPI displays on Windows.  This will probably be most visible on 
laptops where the advertised DPI has been climbing in recent years.

The main thing you might notice is that your windows and controls may 
(often) be larger than previously.  Since we were already scaling the 
default font by the DPI, then any control whose sizing was based on CSS 
"em" measurements will already have been as large as it should have been 
and if your window and set of controls were all 100% sized that way then 
you will not see much difference.

But, other size measurements and any other rendering not based on the 
default font or its "em" size will now be scaled to match.  One common 
way for applications to be affected is when they had their Scene/Stage 
sized using raw numbers.  We had been interpreting those sizes as pixels 
in Windows even if you had a 192DPI or higher display.  If anything, 
this new support might fix a number of layout issues you may have been 
experiencing - in particular a number of tabs in Ensemble8 now have much 
more sensible layouts on Windows with a 192DPI or higher display.  Now 
that all graphics are scaled the same as font-size-based graphics, there 
should be greater consistency all around.

It would be great to get a lot of testing by various developers, not 
just for the obvious reason of making sure there are no regressions 
(we've already identified a minor regression on Linux where the first 
repaint looks wrong, but quickly fixes itself), but so that you can see 
if the sudden resizing of controls under various user environments with 
various DPI settings might create surprising sizing or layout issues for 
your application.  We actually expect and hope that the opposite is true 
- that layouts and sizes will become more sane - but since Windows 
allows the user to control the default "user interface DPI" that is 
reported to applications, we need to be sure that our output remains 
sensible under the wide variety of settings we will encounter "in the 
wild".  Hopefully your application will look great under the default 
settings you have on your machine, and should look great as well even if 
you've customized the DPI settings.

If you are curious and want to test under a variety of "DPI"s, you can 
use one of two methods:

1. Windows provides control panels to change your DPI

https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#setting_dpi_by_using_control_panel

* Note that we are currently in the class "System DPI aware" which means 
when you change the DPI setting in that control panel, you will have to 
reboot or log out/log in to make it take effect, even on the latest 
versions of Windows.  We hope to become "Per Monitor DPI aware" in JDK9, 
but we need changes to AWT/Java2D and the java.exe manifest before we 
can embrace that feature in Windows 8.1.

2. We provide a command line property for overriding the DPI scaling:

-Dglass.win.uiScale=<scale spec>
<scale spec> = [NNN%] | [NNNdpi] | [N.NNNN]

The standard scaling on windows assumes 96DPI as a target, so each of 
the following is identical:
-Dglass.win.uiScale=200% (in cygwin shell)
-Dglass.win.uiScale=200%% (in cmd.exe since it eats single '%' chars)
-Dglass.win.uiScale=192dpi
-Dglass.win.uiScale=2.00

The command line setting is much easier to use than the Control Panel 
because you do not have to log out and back in to test under a variety 
of settings, and you can even compare the application under different 
DPI settings side by side - just remember to double that %% sign in 
cmd.exe or your request for 150% scaling will be delivered to us as a 
request for 150x scaling.  ;)  (And, for the record, I viewed a number 
of test programs under that extreme scale factor before I learned to 
remember this idiosyncrasy of cmd.exe, and they looked fine, if not 
absurdly large...)

MSDN also provides some suggestions for things to do to test your HiDPI 
application.  Even though you've (hopefully) made no program changes to 
your application to get this support as we've (hopefully) done all of 
the leg work for you, some of these testing suggestions may help you 
make sure there are no bugs creeping in from our end:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd464659(v=vs.85).aspx
(Scroll to the bottom for the "Testing Guidance" section)

Finally, we provide 2 additional properties for debugging or overriding 
our default heuristics so that you can test various strategies:

-Dglass.win.forceIntegerRenderScale=[true | false]
(default is true so a 144dpi display is rendered at 2x and then 
downscaled for the proper 1.5x size on the screen - this strategy is 
very similar to how Mac OS deals with retina displays)

-Dglass.win.renderScale=<scale spec>
<scale spec> = [NNN%] | [NNNdpi] | [N.NNNN]
(this can be completely independent of uiScale and controls the scale at 
which we render before we resize the buffer to match the uiScale as we 
blit to the screen.  It also overrides the setting of the previous 
forceIntegerRenderScale property.)

We hope the new HiDPI support improves the look and feel of your 
application on Windows and look forward to hearing any feedback or 
suggestions!

			...jim