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

[Alexey Ivanov]

On Thu, 24 Feb 2022 14:32:39 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%.

I submitted a job for testing the changes.

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

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