Bug ID: JDK-8098184 Support the Windows 8 APIs that indicate proper scaling for HiDPI screens

JDK 8	JDK 9
8u60Fixed	9Fixed

And pushed to the 9-dev repo with the following changeset: changeset: 9051:0de17b57c2f8 date: Fri May 22 17:20:37 2015 -0700 summary: Fix RT-27960: Support HiDPI scaling on Windows http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/0de17b57c2f8
23-05-2015
Can this be marked as resolved/fixed?
23-05-2015
Fixed in the 8u60 repo with the following changeset: changeset: 8900:d6a40bc8dc9e date: Fri May 22 17:20:37 2015 -0700 summary: Fix RT-27960: Support HiDPI scaling on Windows http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d6a40bc8dc9e
23-05-2015
+1
23-05-2015
new final webrev: http://cr.openjdk.java.net/~flar/RT-27960/webrev.final1.rt/ - WinWindow NOP block removed - GlassAppletWindow uses AtomicReference<Float> now - SceneState reverted
22-05-2015
> Many of the 125% quality issues you saw have been resolved so I'm feeling more confident about leaving the default minimum scaling at 100%. As am I.
22-05-2015
WinWindow NOP block - removed. In GlassAppletWindow I went to try to use an AtomicFloat, but there is no such thing (or at least not that autocomplete could find). I can see what you mean now about a barrier. I could always use an AtomicInteger with floatToIntBits() or something...? SceneState.java - reverted copyright change, no longer part of diff WinApplication awareness default - it actually does not matter at all due to the manifest changes, but if we ever remove the manifest then this will automatically upgrade to Per_Monitor. I did a bit of testing with the manifest removed and this is ready to go. On the other hand, the proposed JDK change for Win HiDPI is changing the manifest to true/PM rather than removing the property so we'll be hardcoded to Per_Monitor. That change isn't final yet, so that could change, but this default may never have effect unless we decide to delete the manifest in the JDK for 9... JFXPanel font scaling would be fixed as a consequence of fixing the system font scaling when HiDPI is disabled. I'll file a follow-on bug when I'm done here. Many of the 125% quality issues you saw have been resolved so I'm feeling more confident about leaving the default minimum scaling at 100%.
22-05-2015
+1 OK to get this into 9 and 8u60. Minor (non-blocking) comments below, some of which you pointed out above as follow-on efforts. * WinWindow.java : + AccessController.doPrivileged(new PrivilegedAction<Void>() { + public Void run() { + return null; + } + }); The above block is a no-op and can be removed. * GlassAppletWindow.java + float ret[] = new float[1]; + Application.invokeAndWait(() -> ret[0] = glassWindow.getPlatformScale()); + return ret[0]; + } Would AtomicFloat be better? I guess in this case it should be OK since invokeAndWait provides a barrier. * modules/graphics/src/main/java/com/sun/javafx/tk/quantum/SceneState.java No actual changes (just copyright date), so can be reverted. * WinApplication.java The default for getDesiredAwarenesslevel() is Process_Per_Monitor_DPI_Aware. Given that this will never be effective in JDK 8u would Process_System_DPI_Aware be a better default? Behavioral comments: * On Windows, the scaling of the system font is now disabled even when hiDPI scaling is disabled (e.g., with -Dprism.allowhidpi=false or -Dglass.win.uiScale="100%" or if the scaling is below the minHiDPI threshold). We may want to consider restoring the existing behavior in these cases * Ditto for JFXPanel case on Windows, although you could make a good argument that in this case it will be more problematic (and inconsistent with Swing) to continue to do the font scaling for JFXPanel apps, especially on a very high DPI monitor. * We may want to consider whether the default threshold should be changed to 1.5 (or even 2.0) for 8u60 depending on feedback (and as a hedge against possible regressions for Windows 7 users with 125% scaling). Leaving it at 1.0 for now seems best and will maximize feedback.
22-05-2015
Issues that will be fixed in follow-on efforts: - Robot has a GetPixels(HiDPI) method that Windows does not implement - Try to fix the region fill tests so that they can run on a variety of resolutions (and remove the hardcoded 1:1 setting on them) - JFXPanel forces 1:1 scaling on windows - SwingNode forces 1:1 scaling on Swing (this requires JDK support for Windows HiDPI)
22-05-2015
(Hopefully) Final webrev: http://cr.openjdk.java.net/~flar/RT-27960/webrev.final0.rt/ Includes fixes for: - Force Region fill tests to run at 1:1 scaling to avoid failures until the tests can be fixed - Typo, unused variables in event handling code Remaining issues: - mesh test failures on Windows to be fixed by Chien under another bug id
22-05-2015
Fix for sizing issue in JFXPanel on Mac: http://cr.openjdk.java.net/~flar/RT-27960/webrev.12.rt/
22-05-2015
All of the Linux issues are fixed with webrev.11. The Windows issues also appear to be fixed. The removal of scaling in SwingNode seems to be working OK as near as I can tell. It does mean that FX and Swing will have different ideas of how big the content area will be. This is probably fine, but is something to be aware of. On Mac I still see the regression in JFXPanel where the size of the scene is 1/2 as big as it should be. I will attach a picture.
22-05-2015
Latest fixes: http://cr.openjdk.java.net/~flar/RT-27960/webrev.11/ Fixes in this revision: - Various NPE issues Kevin saw on Linux (I don't have Linux to test with so I just applied the obvious fixes) - Swing in FX no longer scales on Windows (but it still scales on Mac). We cannot support scaled Swing until the JDK supports HiDPI on Windows Known issues: - 10 or so Mesh test failures (will be fixed by Chien separately) - a number of RegionBG tests fail on Windows at non-integer UI scales (125% for instance)
22-05-2015
Latest webrev: http://cr.openjdk.java.net/~flar/RT-27960/webrev.09/ (Edit: Plus a separate webrev for the internal deploy code is needed.) Fixes in this version: - Applets should now scale, and match the size that the browser was expecting them to be - FX in Swing will not scale on Windows (not until JDK supports Windows HiDPI) - no more grainy rendering for non-integer scalings using UploadingPainter - @2x images will now appear the correct size on non-integer scale factors > 1.9 Known issues remaining: - Swing in FX still broken (mainly popups in the wrong location, but haven't fully tested it yet) - many Region background tests fail because they depend on anomalies of 1:1 rendering of thin (and curved) features
21-05-2015
New webrev: rt: http://cr.openjdk.java.net/~flar/RT-27960/webrev.10/ Swing in FX works. AWT popups are in the right location, but lightweight menus/popups in old metal theme are off -Dglass.win.minHiDPI is now a scale value in the NNN%/NNNdpi/<float> format instead of the old dpi value Known issues remaining: - Swing in FX lightweight popups - Region background tests
21-05-2015
I did some additional testing this morning, and the only additional things I noticed are: * On Mac there is a regression in JFXPanel where the size of the scene is 1/2 as big as it should be. The content is scaled correctly, though. * On Windows the JFXPanel app renders correctly and the scene size is also correct, but the default system font is being returned unscaled, so anything that is sized in ems will be too small as a result.
21-05-2015
Drag and drop changes look ok. +1
20-05-2015
A minor update to the previous webrev - the only change is a fix to StubToolkit to allow the automated tests to run: http://cr.openjdk.java.net/~flar/RT-27960/webrev.08/
20-05-2015
New patch: http://cr.openjdk.java.net/~flar/RT-27960/webrev.07/ This fixes a couple of issues: - Live resize problem for non-integer UI Scales identified by Chien - Various modules asking screens for the wrong scale (UI scale vs Render scale) - new command line properties to control HiDPI scaling on windows: -Dglass.win.uiScale=[NNN%\|NNNdpi\|N.NNN] -Dglass.win.renderScale=[NNN%\|NNNdpi\|N.NNN] -Dglass.win.minHiDPI=NNN (A Windows DPI value) -Dglass.win.forceIntegerRenderScale=[true\|false]
20-05-2015
Here is a new patch that allows you to play with the UI and rendering scales directly: http://cr.openjdk.java.net/~flar/RT-27960/webrev.06/ The available controls are shown here in this excerpt from WinWIndow.java: 68 forceIntegerRenderScale = getBoolean("glass.win.forceIntegerRenderScale", true, "forcing integer rendering scale"); 69 overrideUIScale = getFloat("glass.win.overrideUIScalePercent", null, "Forcing UI scaling percent: "); 70 overrideRenderScale = getFloat("glass.win.overrideRenderScalePercent", null, "Forcing Rendering scaling percent: "); 71 maxDownscale = getFloat("glass.win.maxRenderDownScale", 0.0f, "Maximum rendering downscale percent: ") 72 % 1.0f; // Allows them to specify 25% or 125% to mean the same thing You can override the UI scale factor which should affect how big/small to make the windows. It will also affect the default choice of a rendering scale. You can also override the rendering scale factor independently from the UI scale factor. If you manually specify the renderScalePercent then that will be taken verbatim. If you do not explicitly set renderScalePercent, then the other 2 properties can be used to control how the default rendering scale is chosen. "forceInteger" causes it to snap the rendering scale to the next highest integer. "maxDownScale" causes it to have a cutoff where scales of less than "N+maxfraction" will be rendered at N and beyond that they will be rendered at N+1. If you turn off forced integer scaling then maxDownScale still comes into play with the choices being a scale of "N" or "N+fraction" depending on how large the fraction is.
18-05-2015
Here is an updated webrev with fixes for Robot: http://cr.openjdk.java.net/~flar/RT-27960/webrev.05/ Remaining known issues: - The "Swing/embedded/robot" test for RT-32750 still fails because the Swing popup does not appear in the right location. This is due to the LightWeight Frame used to encapsulate the embedded Swing component being fed the "FX values" for window positioning rather than the pixel coordinates that the JDK still expects. The SwingNode code also does not retrieve the correct rendering scale. A few modifications to the SwingNode code will be necessary to fix that test. - A number (~10) of the mesh rendering tests fail but since those also fail on a retina Mac, this may be an issue with RT-39418 for which Chien has a pending fix.
18-05-2015
Here is a proposed fix: http://cr.openjdk.java.net/~flar/RT-27960/webrev.04/ Known issues remaining: - testing on embedded - internal Robot (used for internal testing purposes) fails on Windows if any DPI scale is present I am targeting this to 8u60.
15-05-2015
This is targeted for 9 but we might consider a backport to 8u60.
15-05-2015
Hello, I know this report is a bit old, but I like to add something. I have the same issue like yours: JavaFX's HiDpi scaling is very bad. I have a Dell XPS 15 9530 with a 3200x1800 screen and NetBeans and JavaFX programs in general sometimes have very tiny controls and fonts. On Mac this doesn't seem to be a problem. I don't want to be rude to the developers, but I think it isn't that hard to make use of the Windows 8 API in order to render JavaFX GUIs properly. Right now, it can be a pain to work with JavaFX because I don't know if my programmes will display well on other resolutions.
11-03-2015

Blocks :	JDK-8088096 - RegionFill tests were hard-coded to run at 1:1 scaling
Blocks :	JDK-8089321 - JFXPanel forces 1:1 scaling on Windows
Blocks :	JDK-8101788 - Support for Hi-DPI displays
Blocks :	JDK-8090025 - Support HiDPI version of Robot.getPixels on Windows
Blocks :	JDK-8087793 - Windows scaling override also disables font scaling on HiDPI displays
Blocks :	JDK-8089829 - SwingNode forces Swing into 1:1 scaling
Duplicate :	JDK-8094697 - ColorPicker color boxes lack DPI scaling
Relates :	JDK-8089358 - [Linux] Initial drawing artifacts on some systems when window is first shown
Relates :	JDK-8094825 - [Mac,Retina,3D] Lighting is wrong (too dark, incorrect highlight) with pixel scaling
Relates :	JDK-8199204 - Scene set after stage shown is not sized correctly with HiDPI scaling
Relates :	JDK-8129862 - Windows Hi-DPI scaling leads to blurry text at 125% (120 dpi)