> 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.
Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Fix cast formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1403/files - new: https://git.openjdk.org/jfx/pull/1403/files/da7c97e4..6c14114b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1403&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1403&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 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
