RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering

[anass baya]

On Tue, 4 Feb 2025 07:32:07 GMT, Jeremy <duke at 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