On Thu, 14 Mar 2024 16:06:55 GMT, Lukasz Kostyra <lkost...@openjdk.org> wrote:
> 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. This pull request has now been integrated. Changeset: c3396bf0 Author: Lukasz Kostyra <lkost...@openjdk.org> URL: https://git.openjdk.org/jfx/commit/c3396bf0c3c436458d523119227023fb957cc279 Stats: 25 lines in 1 file changed: 15 ins; 4 del; 6 mod 8207379: Robot screen capture test fails with HiDPI at some screen locations Reviewed-by: kpk, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1403
