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

[Sergey Bylokhov]

On Sat, 5 Mar 2022 08:27:10 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

>> test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 44:
>> 
>>> 42:  * @run main/othervm -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest
>>> 43:  * @run main/othervm -Djdk.gtk.version=3 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest
>>> 44:  */
>> 
>> So having removed all of these, it isn't testing hi-dpi any more, is it ? Even if running on a hi-dpi screen.
>> Would it be better to let it just use whatever it wants for default ? Meaning if it happens to run on a hi-dpi
>> screen we want to know if that works don't we ?
>
>> So having removed all of these, it isn't testing hi-dpi any more, is it ?
> 
> True. But there still is `ScreenCaptureTest.java` that will continue testing hi-dpi. 
> 
> Keeping `ScreenCaptureGtkTest.java` still makes sense because it verifies that `getPixelColor()` works precisely when neighboring pixels are of a different color; also, it shuffles the GTK versions.
> 
> Unfortunately, I see no way to fully and reliably test the changes for 8280861 with scaling above 1. I am forced to choose between two evils: 
> 1. either I set the scale above 1 and pick color inside a large area to be sure that I don't pick neighboring pixels because of an unfortunate window placement
> 1. or I set the scale to 1 and test colors of pixels sitting next to one another.
> 
> (1) was tested by the existing tests, (2) is tested by `ScreenCaptureGtkTest.java`.

you can check both cases, if the scale=1 then use high precision.
if the scale > 1 then you can use low precision -> if the scale is equal to 2 then shift by two/four pixels or something like that?

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

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