RFR: 8282270: java/awt/Robot Screen Capture tests fail after 8280861 [v3]

[Alexey Ivanov]

On Wed, 9 Mar 2022 13:35:44 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> The two tests `ScreenCaptureGtkTest.java` and `HiDPIRobotScreenCaptureTest.java` under `java/awt/Robot/HiDPIScreenCapture` started to intermittently fail under Windows and Linux after the [recent changes](https://github.com/openjdk/jdk/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a) made exclusively for the Linux `Robot` implementation.
>> 
>> `HiDPIRobotScreenCaptureTest.java`
>> Since the Windows failures cannot possibly have their origin in the fix made - the latter being Linux-only - the test apparently either exposes an existing bug in the Windows `Robot` or is bumping against a peculiarity of that platform. The test is reverted back to its original form that didn't fail.
>> 
>> `ScreenCaptureGtkTest.java`
>> The coordinates in the log `(83, 78)` of a failure are higher up than the test suggests `(83, 97)`. I've seen similar failures on Ubuntu 20.04 when the coordinates were set to `(0, 0)`. The color then picked matched the color of the bar drawn at the top of the screen. I believe it's best to place the test pixels towards the center of the window to avoid desktop elements interference.
>> 
>> The other possible reason for intermittent failures are window coordinates. Suppose that the test is executing with `sun.java2d.uiScale` set to 2. This effectively means that it can only pick colors of pixels at even coordinates (in the absolute desktop space). So if the window is placed at, say, `(201, 201)`, `Robot` can only pick the color at either `(200, 200)` or `(202, 202)`. Since the test only makes sense if it is pixel-accurate, I removed all `@run`s with `sun.java2d.uiScale` other than 1. This way window placement will not cause a failure.
>> 
>> This was tested on Ubuntu 20.04 and 18.04 with desktop scaling set to 100%, 200%, and 300%.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HiDPIRobotScreenCaptureTest.java: smaller frame size such that it fits on a 1200x600 screen.
>   
>   ScreenCaptureGtkTest.java: smaller frame size; added code to save
>   the image on failure.

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 42:

> 40:  * @key headful
> 41:  * @bug 8073320
> 42:  * @summary  Windows HiDPI support

The test is run on Linux, so it makes sense to keep Linux in the summary.

Why do you remove 8280861 from the list of bugs?

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 49:

> 47:  *                    HiDPIRobotScreenCaptureTest
> 48:  * @run main/othervm -Dsun.java2d.uiScale=1 HiDPIRobotScreenCaptureTest
> 49:  * @run main/othervm -Dsun.java2d.uiScale=2 HiDPIRobotScreenCaptureTest

I propose keeping these added variants if they add value. However, the test will need rerunning.

It proved that the test failed on the first variant with uiScale set to 3×2.

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 66:

> 64: 
> 65:         Frame frame = new Frame();
> 66:         frame.setBounds(83, 97, 100, 100);

Does it make sense to preserve the comment? It explain the rationale for using the prime numbers as coordinates. The location remains unchanged, so the comment applies.

test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java line 111:

> 109:         checkRectColor(image, 3 * w / 4, h / 4, COLORS[1]);
> 110:         checkRectColor(image, w / 4, 3 * h / 4, COLORS[2]);
> 111:         checkRectColor(image, 3 * w / 4, 3 * h / 4, COLORS[3]);

As my testing showed, this test was stable enough with the changes introduced by [JDK-8282270](https://bugs.openjdk.java.net/browse/JDK-8282270), #7425, with the reduced size of the frame.

test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 68:

> 66:         // by the system because that area's occupied by the global
> 67:         // menu bar and such.
> 68:         frame.setBounds(89, 99, 100, 100);

99 is not a prime number. Is it intentional?

test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 84:

> 82:                 for (int i = 1; i < 4; i++) {
> 83:                     g.setColor(COLORS[i]);
> 84:                     g.fillRect(leftOffset + i, topOffset, 1, 1);

May I suggest using `COLORS.length` instead of 4 in the for-loops for painting and checking?

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

PR: https://git.openjdk.java.net/jdk/pull/7613