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

[anass baya]

On Wed, 5 Feb 2025 18:27:20 GMT, Jeremy <duke at openjdk.org> wrote:

>> Hello @mickleness,
>> The problem is not reproduced on windows !! I can see it only on mac
>
> tldr: Wow / huh. You're right. Thanks for checking.
> 
> That code looks so suspicious that I did some digging:
> 
> (A. On Windows the TransparentWindowTest *says* it fails because Image.getTransparency() is OPAQUE, but the test is wrong: the window looks fine.)
> B. It works because on Windows we end up using the TranslucentWindowPainter. We never invoke `Win32GraphicsConfig#createAcceleratedImage(..)` at all (unless the TransparentWindowTest invokes it directly).
> 
> I tested:
> A. repainting on a timer (so we'd explicitly go through the RepaintManager), and 
> B. an ellipse fill instead of a rectangle fill (to double-check that transparent pixels really were transparent).
> C. using Window.setShape(..) instead of changing the window's background color to transparent (to make sure it followed the same path)
> 
> (... and I don't have access to any other platforms to make sure Linux is doing the right thing.)

Hello @mickleness,
Yes, on Windows we use TranslucentWindowPainter.
I moved the PR to draft since I'm trying to simplify the scaling handler logic. I'll come back to you once I'm done with that.
This test is only for macOS. On Windows, it will fail because we don’t explicitly set the Translucent flag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1943473614