On Tue, 4 Feb 2025 10:13:57 GMT, anass baya <d...@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
