Bug ID: JDK-8166856 OS X: dual screen rendering issue

Type: Bug
Component: javafx
Sub-Component: graphics
Affected Version: 9

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2016-09-28
Updated: 2020-08-18
Resolved: 2016-10-28

JDK 9
9Fixed

OS X 10.11, Build-in Retina, 2nd ViewSonic 1080p display, JDK9 b136

Please run the attached test sample and move it from the 2nd display slowly to the 1st (buit-in) => nok.png

the issue isn't reproducible with JDK8 b132

http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4981c573fd92
28-10-2016
+1. I was able to reproduce this bug on my dual screen setup using the attached test program. I can confirm that your proposed fix resolved the reported issue.
28-10-2016
Testing confirms that this does not affect JDK8 and so no backport is needed.
25-10-2016
Note that the sequence of notifications has evolved like this: JDK8 (no scales exported to FX code): - user drags window to new location - platform sends new bounds - FX code records bounds, does not mark them dirty - platform sends screen change - screen change noted at Prism level - MacWindow.setScreen() override sets new scale in Prism code only - platform sends scale change - scale change not even sent to Java code JDK9 prior to fix: - user drags window to new location - platform sends new bounds - FX code records bounds, does not mark window info dirty - platform sends screen change - screen change noted at Prism level - MacWindow.setScreen() override sends scale up the chain - FX code notes new scale and marks render scale dirty - platform sends scale change - scale change not even sent to Java code - next pulse notes window info is dirty - FX code sends down new scale AND NOP bounds - Prism code forwards the NOP bounds to native code even though they aren't dirty - native code now confused about whether window position is due to drag or due to program request JDK8 now with fix: - user drags window to new location - platform sends new bounds - FX code records bounds, does not mark window info dirty - platform sends screen change - screen change noted at Prism level (no override any more) - platform sends scale change - Prism records and forwards output scale factors - FX code records output scales and marks render scale dirty - next pulse notes window info is dirty - FX code sends down new scale AND NOP bounds - Prism code notices that bounds are NOP and does not send them down - platform code no longer confused about why the window is where it is
25-10-2016
No issues were discovered testing on Win10, Linux, and "Win10 running with Win8 scaling modes". The only change that should apply to the other platforms would be the change where we don't send down NOP "changes" to the windows bounds when only the scaling changed. We used to not echo the window bounds changes before any of the scaling work was done because the only reason that platformWindow.setBounds() was ever called was when the bounds were indeed different. Now that the call is made when the scale changes we need to double check for a NOP update and this fix adds that check. Long ago, the only change that would go down through PlatformWindow.setBounds() was when a program changed the x,y,w,h properties of a window from FX code. After the scaling work, the bounds would also get sent down if a scale change occured, even if the bounds were identical to their previous values. Now, the bounds will be intercepted and not sent down if just the scaling factor changed.
25-10-2016
This webrev fixes this issue for Mac: http://cr.openjdk.java.net/~flar/JDK-8166856/webrev.00/ Some caveats, though: - I haven't tested on Windows and Linux yet (that is next) - There is a similar issue that plagues Windows (see JDK-8146920). This fix may help with that case, and/or the fix may be complicated by the needs of that case, so further investigation on Windows to see how this fix helps/worsens/is related to the Windows fix is needed before this should be pushed. If the Windows issues are no worse under this fix, then I may push this fix by itself and then do some additional Windows follow-on work under the other bugid. - I eliminated an override of MacWindows.setScreen() here which had an obscure comment. I believe that comment no longer applies. Here is the history of that override being created and modified: It was originally created under RT-27960 with a different order of setting scales and calling the super method: http://cr.openjdk.java.net/~flar/RT-27960/webrev.final1.rt/modules/graphics/src/main/java/com/sun/glass/ui/mac/MacWindow.java.sdiff.html It was then modified to its current form under JDK-8091832, a new order for setting the scales was put in place and the comment was left intact even though I don't think it applied any more with the complete rework of the scaling system that was introduced at this point: http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.07/modules/graphics/src/main/java/com/sun/glass/ui/mac/MacWindow.java.sdiff.html I believe the override can be removed now that we have separate specific notification from the system of the new scales. (At least it works fine this way.)
24-10-2016
Similar problems are seen while investigating JDK-8146920...
24-10-2016
With a better description of the issue I was able to reproduce it on 10.11. To reproduce it you need to move the window slowly across the border until you can see the icon change scale. From an @1x monitor to an @2x monitor the icon will first double in size and be clipped against the window boundaries. You can then drag it completely onto the new screen and it will then change again. In the same @1x=>@2x case the oversized icon clipped to the window will shrink back to its regular size, but still be clipped to the same proportion it was clipped by the window earlier. It appears that the notifications to change rendering scale and to change the buffer sizes are getting fired at different times and confusing the internal machinery until we repaint based on a subsequent mouse event. If you move the window more quickly the notifications occur close enough together not to cause confusion.
20-10-2016
the issue is reproducible with b140 on macOS 10.12 Sierra
20-10-2016
Please reopen with further information if you can still reproduce it...
15-10-2016
I can't reproduce this under my current repo, nor under b136. I am using MacOS 10.11.6 on a Mid-2012 retina MacBook Pro. The nok.png image resembles bad output that we used to display when a window was created on a secondary screen (due to misinformation about the scale of the screen it is created on and the scale of the default screen), but would clear up if you moved the window back and forth between screens. Those issues were fixed under 2 separate bugids: JDK-8087565 Scaling problem on OSX Retina (fixed in JDK9 and 8u122 end of August 2016) JDK-8145516 Scene content shows too large on Retina display, when a regular screen attached (fixed in JDK9 and 8u112 in June 2016) Is it possible an older build was being used instead of b136? Is the issue still reproducible?
14-10-2016
Yes, my apologies, the wrong test case was uploaded. Please find the correct sample attached (re-assigning the issue back).
29-09-2016
The test case was using Swing and AWT's MRI so it was misfiled under javafx. I refiled it under Java2D for further investigation...
28-09-2016

Relates :	JDK-8087565 - Scaling problem on OSX Retina
Relates :	JDK-8247839 - Wrong position of GUI elements using multiple HiDPI displays in JavaFX 8
Relates :	JDK-8146920 - [hidpi] Multi-Monitor issue with HiDpi scaling and undecorated stages
Relates :	JDK-8145516 - Scene content shows too large on Retina display, when a regular screen attached