On Fri, 11 Feb 2022 14:05:39 GMT, Maxim Kartashev <d...@openjdk.java.net> wrote:
>> The primary API for image capture on modern Linuxes is >> `gdk_pixbuf_get_from_window()` that expects both coordinates and the size >> unscaled (i.e. not multiplied by the current desktop scale). At the same >> time, `gtk3_interface.c:gtk3_get_drawable_data()` gets the coordinates from >> `Robot` that pre-scales them (multiplying by the scale known to Java, >> however, not necessarily the current desktop scale). The problem with the >> size had been partly taken care of in >> [JDK-8225118](https://bugs.openjdk.java.net/browse/JDK-8225118), but >> coordinates are still passed to `gdk_pixbuf_get_from_window()` pre-scaled. >> >> The idea of the fix is to capture a possibly larger area that is guaranteed >> to contain the one that is interesting to the caller and then only copy the >> interesting pixels to the output image. As a positive side effect, the size >> of the captured area cannot be less than 1x1 (provided the correct input, of >> course). This solves the problem of zero size passed to >> `(*fp_gdk_pixbuf_get_from_drawable)` when the desktop scale is 3 and we're >> asked to capture just one pixel. In that case, the previous formula (`width >> / (float) win_scale + 0.5`) would have yielded `0`. >> >> A related issue would be that tests written specifically for this general >> area (`java/awt/Robot`) didn't catch this problem and only somewhat >> unrelated tests (`javax/swing/...`) were affected. >> >> This one is solved by adding pixel-sized areas to the test image in >> `HiDPIRobotScreenCaptureTest.java`, which precise colors are then verified >> to match the expected ones. In addition to that, instead of verifying just >> the color of the center of a large area, 4 more pixels close to the area's >> border are checked. This helps to make sure that captured area coordinates >> aren't way off. >> >> The tests under `javax/swing/...` that originally helped to identify this >> problem were modified to provide more screen space for painting their >> components as extreme desktop scaling (300%) on Ubuntu doesn't leave much >> room due to a humongous title bar. >> >> The fix was tested by running all the modified tests on Ubuntu with desktop >> scaling set to 100%, 200%, and 300%. The `Robot` tests were also executed on >> Windows (300% scaling) and MacOS. > > Maxim Kartashev has updated the pull request incrementally with one > additional commit since the last revision: > > Updated copyright date in TestJProgressBarHighlightColor.java src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 2867: > 2865: > 2866: inline static int scale_down_to_plus_inf(int what, int scale) { > 2867: return (int)ceilf(what / (float)scale); I find the name of this and the companion function confusing. what is "inf" short for ? I see that and I think plus_infinity. scaled_ceiling and scaled_floor might be better names based on what I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/7425
