On Tue, 7 Jul 2026 22:53:45 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 16 commits: > > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - Remove duplicate Mac backdrop styles, add HUD on Mac > - Removing unused imports, duplicate comments and code > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - Distinguishing between the backdrop style and the actual stage-specific > backdrop. > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - Merge remote-tracking branch 'upstream/master' into osbackdrop > - New version of StageBackdrop API, separated into standard and platform > variants > > commit dee190390d147e9032a734ab0abaab752e308c76 > Author: Martin Fox <[email protected]> > Date: Wed May 20 06:18:23 2026 -0700 > > More minor cleanup > > commit 457c7eb99affd42f67dedb2c760fa639a88943b9 > Author: Martin Fox <[email protected]> > Date: Tue May 19 19:33:15 2026 -0700 > > Cleaning up imports, comments, etc. > > commit 947a5e3598fd0e1b8f69747314405519a8a8794d > Author: Martin Fox <[email protected]> > Date: Tue May 19 16:16:23 2026 -0700 > > Disabling macOS 26 Liquid Glass effect > > commit 9c3d0389f3687504411fc840ecb878ebe9608e36 > Author: Martin Fox <[email protected]> > Date: Tue May 19 16:14:19 2026 -0700 > > Backdrop options are now dynamic and set on the stage. > > commit 7d61c2b9bc15a7bdc7c79b0ddde651678404f065 > Author: Martin Fox <[email protected]> > Date: Tue May 19 11:15:09 2026 -0700 > > Added options query and simplified Windows implementation > > commit c1514f348f9e1d9d3761aec9786dda25e12fa588 > Author: Martin Fox <[email protected]> > Date: Mon May 18 12:07:40 2026 -0700 > > Revamped StageBackdrop API, splitting standard and platform backdrops > and adding options > > commit 608cfa631967470bdbfc02a5b30e55ab3c932d32 > Merge: 551c9ec336 7110a0940d > Author: Martin Fox <[email protected]> > Date: Thu May 14 07:08:44 2026 -0700 > > Merge branch 'osbackdrop' into osbackdrop_dev > > commit 551c9ec336d9e6d3f90e37b278dc17df9a9bca03 > Author: Martin Fox <[email protected]> > Date: Wed Apr 8 08:51:49 2026 -0700 > > Cleanup. > > commit c2e8ec8afc4df2dbd529470761b500e4d670bbeb > Author: Martin Fox <[email protected]... > > I don't see anything mutable in an `ImagePattern` that references an > > animated `Image`. > > My main point is that `StageBackdrop` is quite closely related to `Paint`, > which are shareable configuration objects created by users, and should > therefore have a similar API. And Paints are immutable by design. > You're again trying to ground the API shape in terms of implementation > concerns: that by allowing backdrops to be shared across stages we'll > increase the cost (which cost?) without adding benefit. But a backdrop is > essentially an observable map, where is the cost in allowing it to be shared? And you're again arguing based on your notion of API consistency and not utility. With your proposed API this call: stage.getBackdrop().setOption("TintColor", Color.RED); could change the tint color for multiple stages. Now that, that is unusual in the JavaFX API. And I think unexpected. Will developers consider this useful or behavior that they have to work around? > But a backdrop is essentially an observable map, where is the cost in > allowing it to be shared? I will update this PR or create a new PR with your proposed API. Currently the backdrop maintains a Map, not an ObservableMap, and that will need to change since we'll need to engineer this object to be shared. We'll be adding a constraint to the implementation. In theory there's a testing burden with this but since I have no idea how to write automated tests for this feature that point may be moot. > Preferences are the user's choice (compared to the developer's choice when > building the app), and should ideally be respected out of the box, without > requiring developers to "opt in" by branching over preferences (setting a > backdrop when reducedTransparency=false, and not setting a backdrop > otherwise). Again, I'm not that familiar with this API. The OS level setting for "reducedTransparency" is clearly the user's choice. I'm less clear on what it means to override the OS setting at the Scene level. The OS backdrop selects a background color based on the window's state and various preferences and draws that beneath the Scene's fill color. This is the behavior that developers will have to design for and test against. For example, clients of the backdrop API will automatically be exposed to the to high and low contrast mode settings. To honor a reduced transparency override we'll need to disable the OS backdrop which will also throw away its drawing of a background color. That will need to be replaced. I've given this some thought. I was considering making backdrops "cross-platform" by emulating the background color drawing behavior on platforms that don't support backdrops natively. Because, again, the translucency is really beside the point in terms of development and testing. Win11 barely has any translucency. So it's not just a question of reduced transparency. What does it mean for a client to override the system's background color in the Scene settings? In theory this should also mean disabling the OS backdrop since it can't honor that setting. It's not a question of how to choose a background color, it's a question of when we want to disable the OS backdrop. Whenever the client has overriding reducedTransparency? Whenever the client has overridden the Scene's background color? Whenever the window's color scheme doesn't match the platform's color scheme (at which point the OS will draw a background color that doesn't match the global background color preference)? Under these conditions either JavaFX needs to figure out the background color or we need to provide guidance to developers on what to do. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-4971011354
