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
