forceUploadingPainter is only necessary on Windows to fix the alpha
channel issue. I would generally say that the stated reason in
https://bugs.openjdk.org/browse/JDK-8154847 about why this isn't
necessary to fix is outdated. On Windows 10, you could have made the
point that there is no real reason to have the Unified style anymore as
the window styling back then was very minimalistic. But on Windows 11
and its improved theming options, there's definitely a use for Unified
today.
If you want to try out some stuff on Windows, feel free to try out my
project. It already comes with all the native stuff hooked up, so you
can easily just switch out the Windows enumeration in
https://github.com/xpipe-io/kickstartfx/blob/master/app/src/main/java/io/abc_def/kickstart_fx/core/window/AppModifiedStage.java#L114
On macOS, I more thought of the enumeration consisting out of 3
NSAppearance types with Aqua, Vibrant, and Liquid Glass + Tint. I use
NSVisualEffectMaterialSidebar for the material, I think that is what is
intended for a background material that merges into the app itself.
This enumeration assumes that the Scene Preferences PR is merged with
the support to set the dark theme of the scene/window from JavaFX, so
you don't have to differentiate between light and dark enumeration versions.
On 13/11/2025 18:58, Martin Fox wrote:
What platforms do you use “forceUploadingPainter” on?
I would like to prototype backdrop effects for all stage styles but,
yeah, it’s complicated. The Windows 11 enumeration is short and based
on the type of window (main, transient, tabbed) but the macOS
enumeration is based on content (menu, tooltip, document, sidebar,
etc.) and provides about 14 variants. Not sure how to reconcile those
differences.
On Nov 13, 2025, at 9:22 AM, Christopher Schnick <[email protected]>
wrote:
I think I stumbled upon this UNIFIED issue a while ago but the
workaround by setting -Dprism.forceUploadingPainter=true fixes it.
And these applications have been tested by many users no one ever
mentioned issues, so I'm reasonably sure that everything works fine here.
On macOS, it adds a NSGlassEffectView subview behind the default
JavaFX NSView, yes. Any transparency is handled correctly with this
approach when the stage style is UNIFIED. It would be great if
EXTENDED could support this as well.
In general, it would be desirable for EXTENDED to have all the
properties of UNIFIED, otherwise I don't see much use for it.
Furthermore, an API to apply these window background themes without
any custom native calls would be cool as well, but here the challenge
is whether it would be accepted to have a platform-specific list of
available materials/themes in the API, plus a few customization
options. Because I don't see the possibility of a generic API that
works well on all platforms as they all work so differently.
On 13/11/2025 18:09, Martin Fox wrote:
Christopher,
It will only work with UNIFIED. With the exception of UNIFIED and
TRANSPARENT the core Java code will draw an opaque background fill
behind the scene.
On macOS the glass platform code will remove the layer’s alpha
channel unless the stage style is UNIFIED. I think that’s a
workaround for a bug that has long since been fixed (don’t have the
bug number handy). That logic wasn’t carried over to the Metal
branch and I would like to remove it for OpenGL as well.
UNIFIED doesn’t work reliably on Windows since the rendering
pipeline isn’t guaranteed to add an alpha channel (see
https://bugs.openjdk.org/browse/JDK-8154847). Are you doing
something to kick the HWND so you always get an alpha channel?
On macOS you must be adding a visual effect view to what is known as
the host view. It’s vestigial these days but I always figured it
would come in handy as a container for a visual effect view. Looks
like you’ve discovered that also.
Martin
On Nov 13, 2025, at 8:22 AM, Christopher Schnick
<[email protected]> wrote:
Haha yeah I thought the MonkeyTester would make a good demo content
page for a sample application. And it does!
On 13/11/2025 17:20, Andy Goryachev wrote:
What Kickstart FX? :-)
Joking, joking, I am glad you found it helping.
-andy
*
Confidential- Oracle Internal
From: *openjfx-dev <[email protected]> on behalf of
Christopher Schnick <[email protected]>
*Date: *Thursday, November 13, 2025 at 06:27
*To: *Michael Strauß <[email protected]>
*Cc: *OpenJFX <[email protected]>
*Subject: *Re: StageStyle.EXTENDED with transparent background
We run our applications with native materials for some time now
without any issues.
On Windows 11, it uses the Mica material for the Stage. It
automatically adjusts based on the system theme, so you will
always have a good look and contrast for all theme configurations.
The mica material can also be swtiched to the acrylic one, however
the acrylic theme was primarily intended for Windows 10 and is
being replaced by Mica for Windows 11.
On macOS, it uses the new Liquid Glass material in macOS 26 and
the Vibrant material for older versions. With Liquid Glass you can
also configure the tint if needed.
This can all be achieved via a few native calls with the existing
Stages, at least with the older stage styles like Unified.
Isn't the original issue just about the extended stage style using
a white background? I'm no expert on the implementation, but the
other types of Stages like Unified show their background if you
set the Scene and root node background to be transparent. Normally
that window fill was always white anyway as JavaFX did not support
window theming before, but if the window theme is set to something
different, then that sticks out. Is there something fundamentally
limiting so that the Extended stage is forced to draw a white
background?
Unified:
<aBRzaHD5w0KvUgrJ.png>
Extended, even with DWMWA_USE_IMMERSIVE_DARK_MODE set to true:
<HRrOi0IB1NCsFlHW.png>
On 13/11/2025 00:33, Michael Strauß wrote:
I finally got around to looking into this. I see two
requests here, one to add per-pixel window transparency to
EXTENDED stages and another to support backdrop materials
like Windows’ Mica and Acrylic. On the Mac adding
per-pixel transparency to all stage styles is easy. On
Windows it would take a lot more work and as far as I know
can’t be done with the existing DX9 back end (the
necessary DirectComposition API’s are tied to DX11). We
would also need to reconcile platform differences related
to hit testing and drop shadows. So it’s a big ask.
I think we can probably get there by using a WS_EX_LAYERED
window like we do for StageStyle.TRANSPARENT, if we accept the
significant performance impact. With DirectComposition, we can
directly interface with the DWM composition engine and skip
the GDI window surface completely. This requires a fair bit of
integration with JavaFX that goes beyond changes in the Glass
toolkit. However, it doesn't require a D3D11 rendering
pipeline. It works with the existing D3D9 pipeline by having
D3D9 render into a shared off-screen surface, which is then
accessed by DirectComposition with
ID3D11Device::OpenSharedResource.
(I know there’s a DX12 version of JavaFX in the works but
it’s hard for me to get enthused. I run Windows in a VM
and it’s likely to be stuck on DX11 for a long time.)
Supporting translucent backdrop materials is simpler since
we can ask the OS to draw the effect and then composite
the JavaFX content over it all within an opaque window.
This is how the UNIFIED stage style works so we can
leverage that logic. On Mac this is easy to set up. On
Windows 11 22H2 and beyond we can easily access a couple
of materials. For earlier Windows versions or for a more
extensive list of materials we would need to roll our own
using DirectComposition.
That's correct, it's reasonably simple to support
platform-provided backdrop materials. Anything custom is a lot
more difficult. I have a prototype of JavaFX with
DirectComposition, along with a custom acrylic implementation.
It's very old, and looks like this (running on Windows 10):
https://github.com/user-attachments/assets/cd702a74-603a-4d7e-9078-52f915a4448a
In the end, there doesn't seem to be much common ground
between the various OS platforms for any reasonably powerful
cross-platform API. Maybe we could have the supporting
infrastructure in JavaFX, but only exposing API in a
platform-specific module (either as part of OpenJFX or 3rd
party)? This certainly requires quite a bit of work.
I know nothing about DirectComposition but I’m pretty sure
someone on this list has used it to prototype an Acrylic
effect for JavaFX. I’ll see if I can find that e-mail. I’m
particularly interested in whether this can easily be
turned on and off on-the-fly and how dark mode would be
handled (the platform-provided materials respond to dark
mode).
I've never heard of any previous effort, and it couldn't have
been me beacuse I haven't talked about this up util now. I'd
be interested to learn about other attempts at solving this.
