On Wed, 19 Aug 2026 17:30:54 GMT, Martin Fox <[email protected]> wrote:
>> This PR enables translucent window backdrops for JavaFX stages on macOS and >> Windows 11. Since we’re reliant on the operating system for these effects >> (they typically require real-time blurring of the desktop) I needed to flesh >> out a fairly complete prototype to sort out the API. I will start a >> discussion about the API on the mailing list. >> >> There’s a crude manual test for trying out the different backdrop materials. >> >> java @build/run.args -Djavafx.enablePreview=true >> tests/manual/stage/BackdropTest.java >> >> You’ll want to drag the windows around to avoid having them overlap each >> other since they’re all created in the center of the screen. For windows >> without title bars you can click anywhere on the background to drag the >> window except for TRANSPARENT stages on Windows which are a bit tricker to >> get a hold of; try to click on a text label. >> >> If you create an UNDECORATED stage on Windows the backdrop won’t be >> translucent initially. This can be corrected by changing the stage’s color >> scheme. This is an OS bug that I haven’t found a workaround for. >> >> The changes on Windows 11 are minimal since we’re just invoking an OS >> feature by calling DwmSetWindowAttribute. I did need to make two small >> changes to the D3D9 Prism code to ensure that the swap chain and back buffer >> support an alpha channel so JavaFX can composite its content on top of the >> backdrop. This is the same way the old UNIFIED stage style worked before it >> became unreliable (see >> [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). >> >> On macOS I moved the GlassHostView so it’s now a permanent part of the >> NSWindow. For some time the host view has been a remnant left over from an >> older approach to implementing fullscreen. Now it serves as a common parent >> for the NSVisualEffectView that provides the backdrop and the GlassView3D >> that contains the JavaFX content. Making it the permanent contentView of the >> NSWindow simplifies some code. >> >> To validate the API I did prototype this for Windows 10 (thanks @mstr2!). >> Well, I prototyped this using DirectComposition so it should work on Win10 >> but I can't test Win10 myself. Using DirectComposition is much more involved >> so I shelved that implementation for now but it does inform the API. It’s >> the reason the backdrop needs to be specified before the Java window is >> shown and the platform window created. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Martin Fox has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 24 commits: > > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - Other non-opaque scene fills can now draw over backdrops > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - Remove debug code, fix initial setting of options > - Clients now initialize a stage with a StageBackdrop instead of > StageBackdropStyle > - Using emulated backdrops on Linux > - Windows disables the backdrop with high contrast on > - Windows can now emulate a backdrop color fills > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - Remove duplicate Mac backdrop styles, add HUD on Mac > - ... and 14 more: https://git.openjdk.org/jfx/compare/5e7a4d60...41804987 I find this new version of the API to be significantly cleaner and more intuitive. However, I still don't understand the stringly-typed roundtrip when you call `StageBackdropStyle.getPlatformStyleNames()`, from which you then choose a name, and pass it back into `StageBackdropStyle.style(String)`. This seems like an unnecessary detour, because `StageBackdropStyle` instances are just immutable identifiers. You could directly return a list of all supported instances, from which users can choose one and then directly pass it into `new StageBackdrop(StageBackdropStyle)`. In most cases, however, applications probably won't enumerate the available styles and pick one, but instead directly specify the one they want to use. For this purpose, I recommend to have `StageBackdropStyle.style(String)` not fail silently by returning `null`. Instead, returning an `Optional<StageBackdropStyle>` would make the API easier to use: var style = StageBackdropStyle.style("Windows.Transient") .or(() -> StageBackdropStyle.style("macOS.ClearGlass")) .orElse(StageBackdropStyle.WINDOW); stage.initBackdrop(style); ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-5443249124
