On Mon, 27 Mar 2023 21:45:08 GMT, Jeremy <[email protected]> wrote: > The original write-up contains two complaints: > 1. The window is opaque, so pixels that should be transparent are black. > 2. The window is the wrong resolution. On a 200% resolution monitor it > renders as if it were 100% (so it looks pixelated). > > I recommend splitting this up into separate tickets. > > This PR addresses the first (probably most offensive) issue: the window is > now transparent. > > I experimented with a change that resolves the second issue (image > resolution) here: > https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002 > > ... that works, but IMO that looks riskier and should be part of a separate > discussion. > > I only have a Mac configured right now to test against, so I've confirmed the > MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig > changes are identical, but I haven't confirmed that this new test passes in > those environments. (I did confirm that those GraphicsConfig files appear to > support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be > OK.
Alan, I may be confused. Does VAqua rely on turning off volatile buffering? Or your comment might (?) make more sense if it's for my other PR ([for 8303950](https://github.com/openjdk/jdk/pull/12993)) that relates to this method: https://github.com/openjdk/jdk/blob/a8871f5d26e5cb42c031c7b736ec30b1b147a2bc/src/java.desktop/share/classes/java/awt/Window.java#L3946-L3960 (Also: thanks for mentioning VAqua! I'll check it out. I was a big fan of Werner's Quaqua work a decade ago at another job.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13196#issuecomment-1500695845
