On Thu, 24 Feb 2022 14:32:39 GMT, Maxim Kartashev <d...@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
