On Mon, 12 Jun 2023 20:38:40 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:

> > 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_.
> 
> Are you sure? Currently the code for image 
> [creation](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L155)
>  and the image 
> [requests](https://github.com/openjdk/jdk/blob/79a4ac791c826656b3e984fe54dc472c62efd028/src/java.desktop/share/classes/sun/swing/CachedPainter.java#L317)
>  use the same "ceil" logic.

Yes, I am. The base width and height are 13×13, in 125% the parameters to 
`getResolutionVariant` are 16.25 and 16.25 — so the image created was 17×17.

Yet, as you can see, it doesn't match the destination width and height, so a 
scale to compensate for it is applied in `CachedPainter`.

With the updated formula, the image created is 16×16 which is closer to the 
requested size. The scale to compensate for the difference is still applied but 
it results in less distortion, which eventually looks better.

> > > 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.
> 
> Since we cannot guarantee that the Windows always return exact size we should 
> have a backup code to rescale the image.

No, we should not have a backup code to rescale the image: we request Windows 
to paint the image in the resolution appropriate for the DPI set for a display 
we're rendering for. If, for whatever reason, Windows returns an image that is 
too small for this DPI, you will notice it in all Windows native controls and 
apps, Java apps will not be different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1227235963

Reply via email to