RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations

[Karthik P K]

On Thu, 14 Mar 2024 16:06:55 GMT, Lukasz Kostyra <lkostyra at 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.

Tested the changes in Mac, Windows and Linux. The changes fixes the issues in Mac and Windows.
I ran the test in Linux VM and it failed with and without the fix with error:

RobotTest > testScreenCapture FAILED
    junit.framework.AssertionFailedError: expected: rgba(255,0,255,255) but was: rgba(0,0,0,255)
        at test.robot.javafx.scene.RobotTest.assertColorEquals(RobotTest.java:848)
        at test.robot.javafx.scene.RobotTest.testScreenCapture(RobotTest.java:774)


Changing the scale also did not make any difference. Not sure if it is related to anything in VM.
It is a Ubuntu 22.04 VM

Added a minor comment inline.

tests/system/src/test/java/test/robot/javafx/scene/RobotTest.java line 758:

> 756:         // Below calculations follow how getScreenCapture should calculate screen capture dimensions. This
> 757:         // is to make this code consistent and stable on HiDPI systems.
> 758:         int stageX = (int)stage.getX();

Minor: Do you think space should be added after `(int)` similar to `(double)`?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1403#pullrequestreview-1938661604
PR Review Comment: https://git.openjdk.org/jfx/pull/1403#discussion_r1526104191