On Tue, 16 May 2023 19:26:57 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>> Actually I literally didn't mean 1 physical pixel, it was more figurative to >> say that when the width calculation on Java side is reduced by 1 we see a >> big difference in final scaling. > > Perhaps, this needs additional details. The size of checkbox and radio button > is 13 as reported by Theme API for the standard DPI of 96. Being a prime > number, 13 doesn't scale well, there's always fractional part unless the > scale is whole. Thus, the scaled size never matches. > > As the result, `CachedPainter` seems to apply a scale to compensate for that > — whether we choose ceil or floor. The above formula gives better results. > > The entire thing should have been simpler: a `MultiResolutionImage` which > paints the background according to the scale requested. Yet it proved to be > not as simple. We're planning to look further into simplifying it if possible > and, alternatively or in addition to, considering [dynamic layout based on > graphics > configuration](https://github.com/openjdk/jdk/pull/13701#discussion_r1187985627) > as you suggested above. > > The current solution may be not perfect but it provides better rendering > compared to what we have now: *the controls look crisp only on the main > display*. But still why the size on the components are so different? is it really caused by one "pixel/unit" we requested from the native? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1198378292
