On Sat, 10 Jun 2023 01:20:36 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> II am not sure that is correct way to calculate the dpi based on the "adhoc" > change of the image size. That will add the mismatch between the code where > we create the image, and the code where we request the image. There's always a mismatch (at this time). We already discussed it [above](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571). For example, for 125% scale, Windows returns 13×13 like for 100%; yet Swing expects 16.25. This is handled by rendering the 13×13-sized theme background into 16×16-sized bitmap — *to avoid any scale transformations being applied* to keep the image *crisp*. > We probably should change them both, or calculate the dpi in some other way. The DPI is calculated based on the scale set on the Graphics. Rajat provided the relevant excerpt: https://github.com/openjdk/jdk/blob/727836ea85394b8baacd19a834f2993f06084c44/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java#L708-L711 This scale is calculated based on the size of the image. So, we probably should… change. As [I already said](https://github.com/openjdk/jdk/pull/13701#discussion_r1195604571), this fix should've been as simple as a `MultiResolutionImage` where [`getResolutionVariant`](https://github.com/openjdk/jdk/blob/a780bf0dda4c2c3dce4337ccea37bcdce52045de/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L316) returns the image of the correct size if it's already stored or retrieves it from the system. But it's not the case, and `CachedPainter` seems to be a hindrance rather than a helper. That being said, we're planning to look further into simplifying it. Perhaps, `XPStyle.SkinPainter` shouldn't extend `CachedPainter`… > Also the fact that on the image above one component is rendered twice smaller > that another make me think that we did not rescale the image if the Windows > return the image of the different size(You probably can prove that by always > returning the wrong size from the native and check how it will look on HiDPI > screen) The point of the this fix is to *avoid rescaling* what Windows returns. And it *succeeds*: check boxes and radio buttons look much better — sharper and crisper — when you drag Swing UI frame from a display with one DPI to that with another; they even look better on the main display if its DPI is 120 or 168, that is 125% and 175% correspondingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1227173718
