There were two different problems with this test's stability and HiDPI and both were fixed with this change.
The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. ------------- Commit messages: - RobotTest: Stabilize testScreenCapture - Reactivate RobotTest.testScreenCapture Changes: https://git.openjdk.org/jfx/pull/1403/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8207379 Stats: 25 lines in 1 file changed: 15 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1403.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1403/head:pull/1403 PR: https://git.openjdk.org/jfx/pull/1403
