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

[Jeremy]

On Tue, 4 Feb 2025 10:13:57 GMT, anass baya <duke at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 260:
>> 
>>> 258:             }
>>> 259:         };
>>> 260:     }
>> 
>> This may be outside the scope of this ticket, but I'm seeing similar code in Win32GraphicsConfig#createAcceleratedImage(..), X11GraphicsConfig#createAcceleratedImage(..), and GLXGraphicsConfig#createAcceleratedImage(..) .
>> 
>> Should those be looked at, or is there another ticket to explore those? (That is: are they also going to be opaque and the wrong resolution?)
>
> 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.)

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

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