RFR: JDK-8266245: AWT Test FullScreenInsets.java fails due to incorrect pixel color and wrong window bounds [v2]

[Alexey Ivanov]

On Mon, 5 Dec 2022 22:10:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms.
>> 
>> The following changes have been made:
>> - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices).
>> - Color tolerance has been added for color check
>> - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected.
>> 
>> CI testing passes on all platforms (tested 50 times per platform).
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame changed back to decorated and exclude on linux

Why can't we scan all the pixels? It was the purpose of the test to ensure each window has the exact color. Does it take very long time?

Why is color tolerance needed? Is it to account for High DPI display? Can we use [`Robot.createMultiResolutionScreenCapture`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Robot.html#createMultiResolutionScreenCapture(java.awt.Rectangle)) to ensure the `BufferedImage` contains the actual pixels rather a scaled down version?

test/jdk/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java line 109:

> 107:         if (!exp.equals(actual)) {
> 108:             System.out.println(" Wrong window size:" +
> 109:                                " Expected: " + exp + " Actual: " + actual);

I'd rather leave `err` — it's supposed for printing error messages.

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

PR: https://git.openjdk.org/jdk/pull/11462