On Wed, 5 Feb 2025 18:27:20 GMT, Jeremy <d...@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
