On Tue, 4 Feb 2025 07:32:07 GMT, Jeremy <d...@openjdk.org> wrote: >> The PR includes two fix : >> 1 - The first fix targets proper rendering of the transparent image. >> 2 - The second fix ensures the image is painted at the correct resolution to >> avoid pixelation. > > src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line > 246: > >> 244: int fullResWidth = Math.round( scaleFactor * width); >> 245: int fullResHeight = Math.round( scaleFactor * height); >> 246: WritableRaster wr = >> model.createCompatibleWritableRaster(fullResWidth, fullResHeight); > > Thanks for working on this. :) > > I have a couple of questions: > > 1. This math looks great for the simple case of a 200% high-res monitor; is > the rounding safe for non-integer resolutions? > > For ex if width is 33 and scaleFactor is 1.25, then we'll call > `round(41.25)`, so `fullResWidth = 41`. > > Will the native windowing system allocate 41px for our Window? (Because if > so: great. We have a perfect fit.) Or could it allocate 42px? (In which case > we may have a thin border on the right/bottom that becomes unpaintable...) > > 2. I'm assuming if `fullResWidth`/`fullResHeight` is ever zero we'll get a > RTE. I don't think it's stated, but the preexisting code suggests `width` and > `height` were never zero. Is it possible `scaleFactor` can ever be less than > .5? (I've never observed that in my day-to-day life, but I'm just thinking > about edge cases and RTE's...)
Hello @mickleness , Thank you for your review. It is well known that we can lose a fraction of a pixel. For example in https://github.com/openjdk/jdk/pull/23183 we allowed a 1-pixel margin of error to compensate for that as the rounding error could accumulate ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940876427
