On Sat, 5 Mar 2022 08:27:10 GMT, Maxim Kartashev <d...@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
