From arapte at openjdk.org  Sun Feb  1 01:41:22 2026
From: arapte at openjdk.org (Ambarish Rapte)
Date: Sun, 1 Feb 2026 01:41:22 GMT
Subject: Integrated: 8373091: Make Metal the default JavaFX rendering pipeline
 for macOS
In-Reply-To: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com>
References: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com>
Message-ID: <Qmnw7yqWQaIEGql4vly9G8pT9_5djcamcZxDH4Yv1JQ=.3b1357c7-39ec-46cd-8417-a5e48e192002@github.com>

On Fri, 23 Jan 2026 01:58:07 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The metal rendering pipeline was integrated in PR #1824, It has been well tested and ready for to be default pipeline on MacOS. 
> During JavaFX 26 it was temporarily set as default for 6 weeks, during which we did not see any issues.
> Changing the pipeline to default early in jfx27 would offer more testing.
> 
> If required one can always use es2 pipeline by passing `-Dprism.order=es2`

This pull request has now been integrated.

Changeset: 5ac1620a
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5ac1620ac0ba20170ae9758e20893feba5ebc58b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8373091: Make Metal the default JavaFX rendering pipeline for macOS

Reviewed-by: kcr, aghaisas, jdv

-------------

PR: https://git.openjdk.org/jfx/pull/2050

From lukasz.kostyra at oracle.com  Mon Feb  2 11:36:39 2026
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Mon, 2 Feb 2026 11:36:39 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io>
 <IA3PR10MB868298C18CF5080852E3DCE3FED9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <e9d69da3-e2e9-4e8a-80ff-84430983872a@xpipe.io>
 <DM3PPF3367D7B9B6FC6AF955C783A9EA92AFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B9292A1E528D3FB529977FEA3A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io>
 <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B024908A4D6D3DFACDF4DFE89A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
Message-ID: <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

This should be the final attempt at resolving this topic once and for all :)

I pushed https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34 just now which in my testing makes KickstartFX work properly even on UploadingPainter. After quite a bit of testing and scrolling it seems to me the corrupted font issues are now resolved. Please give it a go and let me know if it works on your end.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 29 January 2026 14:38
To: Christopher Schnick <crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today?

Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Thursday, 29 January 2026 13:31
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking?

The good news is that  https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged.
On 29/01/2026 12:02, Lukasz Kostyra wrote:
I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled?

That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis.

As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed.

For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line.

I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter.

Let me know if KickstartFX runs properly with PresentingPainter.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Wednesday, 21 January 2026 13:54
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu)

On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations.

You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install<https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
On 21/01/2026 13:48, Lukasz Kostyra wrote:
Thanks for checking.

I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine.

I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :)

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Tuesday, 20 January 2026 16:24
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


In our main application I am getting the following error spammed in the logs:

16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture>(BaseGraphics.java:464)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture>(BaseShaderGraphics.java:159)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent>(NGImageView.java:123)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender>(NGImageView.java:103)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint>(ViewPainter.java:481)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl>(ViewPainter.java:329)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run>(UploadingPainter.java:143)
16:18:08:572 - error:     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)

In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues.
On 20/01/2026 15:40, Lukasz Kostyra wrote:
Hi Christopher,

After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$> and according to my local testing everything seems to be fine now.

When you have a moment, could you check out the changes above and let me know if everything works correctly in your app?

If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$> you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app.

Regards,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Wednesday, 10 December 2025 13:29
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

It should work fine without the property. Thanks for your help, I?ll keep searching.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Tuesday, 9 December 2025 17:10
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works.

Or should I still pass the property in this commit as well?
On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
Hi Christopher,

I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$> . Let me know how it works and if the problem has been resolved.

Thanks,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 4 December 2025 11:52
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Wednesday, 3 December 2025 18:53
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false
On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
Hi Christopher,

I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$> to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead.

When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line?

If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down.

Thanks,
-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Friday, 28 November 2025 13:25
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I did not encounter the vanishing issue anymore with that build, so at least it is usable.

However, the font rendering issue still exists for some nodes:

[cid:image001.png at 01DC9440.9140C0B0]

It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly.

Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit.
On 28/11/2025 12:41, Lukasz Kostyra wrote:
Hi Christopher,

I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$> . If you find a moment, could you build JFX from that branch and check if your app works correctly?

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 17 November 2025 15:14
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen.

To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it.

On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Saturday, 15 November 2025 17:39
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Forgot to add, there is nothing out of the ordinary printed in the verbose logs.

If I find the time, I can look into compiling a debug build.

But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me.
On 15/11/2025 17:34, Christopher Schnick wrote:

Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering:

[cid:image002.png at 01DC9440.9140C0B0]

Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay.

After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc.
On 13/11/2025 16:30, Lukasz Kostyra wrote:
Thanks for checking.

It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that.

The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information.

If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks.

If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?.

I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there.

Good luck!
- Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Thursday, 13 November 2025 16:11
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time.

There is no exception thrown as far as I can see, so not sure what you need for debugging.

For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm<https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$> . It is built from these sources: https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
On 13/11/2025 14:40, Lukasz Kostyra wrote:
Hello openjfx-dev,

The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com<https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>

This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread).

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 25 or later.
4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo  - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions.
5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx<https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]

We look forward to your feedback.

Regards,
Lukasz


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/960d57c3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 18275 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/960d57c3/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 57114 bytes
Desc: image002.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/960d57c3/image002-0001.png>

From arapte at openjdk.org  Mon Feb  2 13:35:44 2026
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 2 Feb 2026 13:35:44 GMT
Subject: RFR: 8375466: Metal rendering pipeline crashes on virtualized OS
Message-ID: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>

Issue:
As described in the bug, a crash occurs on macOS VM created using Parallels.
The crash occurs when trying to create a [MTLArgumentEncoder](https://github.com/openjdk/jfx/blob/5ac1620ac0ba20170ae9758e20893feba5ebc58b/modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m#L76C49-L76C82), which is required for creating Shaders(Both Prism and Decora)
This crash is not observed on macOS VM created using Apple Virtualization Framework.

Fix:
Support for MTLArgumentEncoder is mandatory for Prism Metal Rendering pipeline. Without support for MTLArgumentEncoder the Shaders cannot be created.
In this scenario Prism should gracefully fallback to Software rendering.
Added a check to verify if the minimum [MTLGPUFamilyMac2](https://developer.apple.com/documentation/metal/mtlgpufamily/mac2?language=objc) GPU family is supported by the platform. If not supported then Metal Pipeline cannot be used, and rendering falls back to software pipeline.

-------------

Commit messages:
 - check mtl lib support

Changes: https://git.openjdk.org/jfx/pull/2061/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2061&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375466
  Stats: 25 lines in 2 files changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/2061.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2061/head:pull/2061

PR: https://git.openjdk.org/jfx/pull/2061

From kcr at openjdk.org  Mon Feb  2 14:43:41 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 2 Feb 2026 14:43:41 GMT
Subject: RFR: 8375466: Metal rendering pipeline crashes on virtualized OS
In-Reply-To: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
References: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
Message-ID: <PVIxSO4AT7NBhkEfpoZACBfl2gsqut5iXTvyR3QHRXo=.e9ee0a59-759d-4ab5-9210-72624a1250f4@github.com>

On Mon, 2 Feb 2026 13:30:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> As described in the bug, a crash occurs on macOS VM created using Parallels.
> The crash occurs when trying to create a [MTLArgumentEncoder](https://github.com/openjdk/jfx/blob/5ac1620ac0ba20170ae9758e20893feba5ebc58b/modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m#L76C49-L76C82), which is required for creating Shaders(Both Prism and Decora)
> This crash is not observed on macOS VM created using Apple Virtualization Framework.
> 
> Fix:
> Support for MTLArgumentEncoder is mandatory for Prism Metal Rendering pipeline. Without support for MTLArgumentEncoder the Shaders cannot be created.
> In this scenario Prism should gracefully fallback to Software rendering.
> Added a check to verify if the minimum [MTLGPUFamilyMac2](https://developer.apple.com/documentation/metal/mtlgpufamily/mac2?language=objc) GPU family is supported by the platform. If not supported then Metal Pipeline cannot be used, and rendering falls back to software pipeline.

Reviewers: @kevinrushforth @jayathirthrao

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2061#issuecomment-3835540036

From crschnick at xpipe.io  Mon Feb  2 14:59:36 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Mon, 2 Feb 2026 15:59:36 +0100
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B6FC6AF955C783A9EA92AFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B9292A1E528D3FB529977FEA3A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io>
 <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B024908A4D6D3DFACDF4DFE89A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
Message-ID: <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>

Looks good, the font looks correct now.

I went through most of the application to see if there's anything else. 
In the MonkeyTester page, I found this issue with popup windows in the 
menu bar and shadows I guess? In the d3d9 build, this does not occur. 
Video is attached.

If you get around to reviewing https://github.com/openjdk/jfx/pull/2058, 
you can use the same testing system to also run kickstartfx with d3d12 
as that is also broken in various ways on there.

With our main application, I am getting render corruption issues as 
shown in the video. I can also give instructions on how to run that 
application, it is very similar to kickstartfx. Just needs a bit more setup.

Other than that, as mentioned by Martin I think, the translucent 
background fill for the UNIFIED stage style does not show correctly in 
kickstartfx if you compare it to the normal build. The left sidebar 
frame should have the proper window theme color when the performance 
mode is disabled, however it is only white or black, depending on the 
system theme:


On 02/02/2026 12:36, Lukasz Kostyra wrote:
>
> This should be the final attempt at resolving this topic once and for 
> all :)
>
> I pushed 
> https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34 
> just now which in my testing makes KickstartFX work properly even on 
> UploadingPainter. After quite a bit of testing and scrolling it seems 
> to me the corrupted font issues are now resolved. Please give it a go 
> and let me know if it works on your end.
>
> -Lukasz
>
> *From:*openjfx-dev <openjfx-dev-retn at openjdk.org> *On Behalf Of 
> *Lukasz Kostyra
> *Sent:* Thursday, 29 January 2026 14:38
> *To:* Christopher Schnick <crschnick at xpipe.io>
> *Cc:* OpenJFX <openjfx-dev at openjdk.org>
> *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release
>
> Indeed it is still there, although on my machine it happens less with 
> Presenting Painter. I tried it a couple of times before sending the 
> email and it worked fine, so seems like I should also go buy a lottery 
> ticket today?
>
> Well, good news to me is that this happens on PresentingPainter, so I 
> now have some more possibilities in terms of debugging it in-place. 
> I?ll get back to you when it?s fixed.
>
> -Lukasz
>
> *From:*Christopher Schnick <crschnick at xpipe.io>
> *Sent:* Thursday, 29 January 2026 13:31
> *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
> *Cc:* OpenJFX <openjfx-dev at openjdk.org>
> *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
> I commented out the uploading painter line and still see the same 
> issue. As you say, it shouldn't make a difference. Maybe you hit the 
> one time where the issue just didn't occur statistically speaking?
>
> The good news is that 
> https://bugs.openjdk.org/browse/JDK-8154847?should be finally fixed by 
> the new translucent backdrop PR, so it shouldn't need this property 
> anymore in the future when it is merged.
>
> On 29/01/2026 12:02, Lukasz Kostyra wrote:
>
>     I looked through KickstartFX and I noticed there?s a point where
>     KickstartFX forces the use of Uploading Painter -
>     PlatformState.java @ 112. UploadingPainter was designed to work
>     with software pipeline as a fallback mechanism (SW does not have
>     the SwapChain/Presentation mechanisms that HW pipelines use) so
>     using it with hardware-accelerated pipelines is not officially
>     supported. When I set prism.forceUploadingPainter to false text
>     and buttons rendered correctly with D3D12 on my machine. Could you
>     check if everything works fine on your end with UploadingPainter
>     disabled?
>
>     That being said, I do agree there should technically be no visual
>     difference between PresentingPainter and UploadingPainter. I have
>     some theories as to why that would be the case, but because
>     UploadingPainter with hardware pipelines is not officially
>     supported I?ll have to push this issue towards a later point in
>     time. UploadingPainter makes this a bit extra difficult to debug
>     because graphics debuggers rely on applications calling Present()
>     to determine when the application progresses to the next frame -
>     with UploadingPainter no Present() is called and debuggers can?t
>     capture the frame properly for analysis.
>
>     As for Hyper-V problems - I didn?t get a chance to test these yet
>     but we also did not try running JavaFX with D3D12 backend on
>     virtualized platforms. I will take a look at that use case also at
>     a later point in time, once the performance improvements are
>     completed.
>
>     For both of these (UploadingPainter issues and Hyper-V issues)
>     I?ll add separate bugs to my backlog and tackle them later down
>     the line.
>
>     I also checked why UploadingPainter was preferred in KickstartFX
>     and this seems to be the issue -
>     https://bugs.openjdk.org/browse/JDK-8154847. If what Martin
>     mentioned in comment history is correct, there?s a possibility
>     that with D3D12 there should be no transparency issues, as D3D12
>     defaults to alpha-supported SwapChain buffer (BGRX format exists
>     but presents some technical issues and limitations, BGRA is more
>     convenient). However I had no way of verifying this theory, on my
>     Intel Iris Xe laptop the reproducer works as expected on both D3D
>     and D3D12, with or without UploadingPainter.
>
>     Let me know if KickstartFX runs properly with PresentingPainter.
>
>     -Lukasz
>
>     *From:*Christopher Schnick <crschnick at xpipe.io>
>     <mailto:crschnick at xpipe.io>
>     *Sent:* Wednesday, 21 January 2026 13:54
>     *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>     <mailto:lukasz.kostyra at oracle.com>
>     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>     Alright, that is good to know. I also ran the d3d12 build in a
>     Hyper-V Windows 11 VM, which are known to cause issues. For
>     example, this issue happens in those VMs with StageStyle.UNIFIED:
>     https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the
>     unified stage style unless you turn on performance mode in the
>     settings menu)
>
>     On that system, the app sometimes froze completely, sometimes, the
>     rendered image got stuck. Changing the performance mode setting
>     and the property?-Dprism.forceUploadingPainter=true changed the
>     behavior, but it was broken in some way in all configurations.
>
>     You should be able to reproduce these issues easily with the
>     Windows Sandbox feature:
>     https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install
>     <https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
>
>     On 21/01/2026 13:48, Lukasz Kostyra wrote:
>
>         Thanks for checking.
>
>         I ran the KickstartFX build one more time, it failed but I
>         found some leftover global gradle.properties file which
>         defined older JDK which broke the build. Changing JDK to
>         25.0.1 everything built and works fine.
>
>         I also found a way to build KickstartFX using custom JFX
>         (customJavaFxLibsPath in build.gradle) and can reproduce your
>         font issues locally on D3D12. I?ll report back when I solve
>         them on my end. :)
>
>         -Lukasz
>
>         *From:*Christopher Schnick <crschnick at xpipe.io>
>         <mailto:crschnick at xpipe.io>
>         *Sent:* Tuesday, 20 January 2026 16:24
>         *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>         <mailto:lukasz.kostyra at oracle.com>
>         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>         <mailto:openjfx-dev at openjdk.org>
>         *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>         In our main application I am getting the following error
>         spammed in the logs:
>
>         16:18:08:571 - error: java.lang.NullPointerException: Cannot
>         invoke "com.sun.prism.Texture.getPixelFormat()" because "tex"
>         is null
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:571 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329)
>         16:18:08:572 - error:? ? ?at
>         javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143)
>         16:18:08:572 - error:? ? ?at
>         java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
>         16:18:08:572 - error:? ? ?at
>         java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
>         16:18:08:572 - error:? ? ?at
>         java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
>
>         In kickstartfx, I still get the font rendering issues. Can you
>         share the problems you encountered? I tried to build it on a
>         blank VM with git clone, setting a JDK25 in the PATH, and
>         running gradlew.bat run without issues.
>
>         On 20/01/2026 15:40, Lukasz Kostyra wrote:
>
>             Hi Christopher,
>
>             After Christmas break I came back to this issue with some
>             new patches. There were some problems I found with the
>             clear optimization, I just submitted
>             https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31
>             <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$>
>             and according to my local testing everything seems to be
>             fine now.
>
>             When you have a moment, could you check out the changes
>             above and let me know if everything works correctly in
>             your app?
>
>             If there are still problems I would like to find a way to
>             build your app and test it locally. I tried doing that
>             earlier via https://github.com/xpipe-io/kickstartfx
>             <https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
>             you linked earlier but encountered some problems when
>             building, so I?m going to need your help or some
>             instructions on how to build the app.
>
>             Regards,
>
>             -Lukasz
>
>             *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>             <mailto:openjfx-dev-retn at openjdk.org> *On Behalf Of
>             *Lukasz Kostyra
>             *Sent:* Wednesday, 10 December 2025 13:29
>             *To:* Christopher Schnick <crschnick at xpipe.io>
>             <mailto:crschnick at xpipe.io>
>             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>             <mailto:openjfx-dev at openjdk.org>
>             *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release
>
>             It should work fine without the property. Thanks for your
>             help, I?ll keep searching.
>
>             -Lukasz
>
>             *From:*Christopher Schnick <crschnick at xpipe.io>
>             *Sent:* Tuesday, 9 December 2025 17:10
>             *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>             *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA
>             release
>
>             I tried this commit, but the problem shows up again. I
>             tested the previous commit with the passed property again,
>             and that one still works.
>
>             Or should I still pass the property in this commit as well?
>
>             On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
>
>                 Hi Christopher,
>
>                 I updated the direct3d12 branch with the fix -
>                 https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8
>                 <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$>
>                 . Let me know how it works and if the problem has been
>                 resolved.
>
>                 Thanks,
>
>                 -Lukasz
>
>                 *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>                 <mailto:openjfx-dev-retn at openjdk.org> *On Behalf Of
>                 *Lukasz Kostyra
>                 *Sent:* Thursday, 4 December 2025 11:52
>                 *To:* Christopher Schnick <crschnick at xpipe.io>
>                 <mailto:crschnick at xpipe.io>
>                 *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                 <mailto:openjfx-dev at openjdk.org>
>                 *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release
>
>                 Thanks for checking. I filed
>                 https://bugs.openjdk.org/browse/JDK-8373088 to track
>                 this since this is unrelated to specifically text,
>                 will probably get to it in a few days.
>
>                 -Lukasz
>
>                 *From:*Christopher Schnick <crschnick at xpipe.io>
>                 *Sent:* Wednesday, 3 December 2025 18:53
>                 *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                 *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                 *Subject:* [External] : Re: JavaFX Direct3D 12 -
>                 Second EA release
>
>                 This commit fixes the problem when the property is set
>                 to false and it shows up again if the property is not
>                 set to false
>
>                 On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
>
>                     Hi Christopher,
>
>                     I did not find the way to reproduce this locally,
>                     but I found a problem with one of the
>                     optimizations that is in the backend. To double
>                     check if that is in fact the issue I pushed
>                     https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89
>                     <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$>
>                     to disable the optimization (it is on by default,
>                     disabling it fixes that specific problem on my
>                     end) and I?d like to double-check if this is the
>                     correct lead.
>
>                     When you have a moment, could you build JFX with
>                     that change and run your app with
>                     ?-Dprism.d3d12.clearOpts=false? added to the
>                     command line?
>
>                     If the problem persists with prism.d3d12.clearOpts
>                     set to false I would need some more information on
>                     how these labels are rendered to track this down.
>
>                     Thanks,
>
>                     -Lukasz
>
>                     *From:*Christopher Schnick <crschnick at xpipe.io>
>                     <mailto:crschnick at xpipe.io>
>                     *Sent:* Friday, 28 November 2025 13:25
>                     *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                     <mailto:lukasz.kostyra at oracle.com>
>                     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                     <mailto:openjfx-dev at openjdk.org>
>                     *Subject:* [External] : Re: JavaFX Direct3D 12 -
>                     Second EA release
>
>                     I did not encounter the vanishing issue anymore
>                     with that build, so at least it is usable.
>
>                     However, the font rendering issue still exists for
>                     some nodes:
>
>                     It is not deterministic, meaning that if I just
>                     scroll the scrollpane forward and back, the same
>                     text might get rendered correctly.
>
>                     Also, did you see the performance results I posted
>                     for my AMD system? Performance was quite bad
>                     there, so this is not in a stage where I can test
>                     this in production a bit.
>
>                     On 28/11/2025 12:41, Lukasz Kostyra wrote:
>
>                         Hi Christopher,
>
>                         I just pushed a fix for JDK-8371995 onto
>                         direct3d12 branch in the sandbox -
>                         https://github.com/openjdk/jfx-sandbox/tree/direct3d12
>                         <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$>
>                         . If you find a moment, could you build JFX
>                         from that branch and check if your app works
>                         correctly?
>
>                         -Lukasz
>
>                         *From:*openjfx-dev
>                         <openjfx-dev-retn at openjdk.org>
>                         <mailto:openjfx-dev-retn at openjdk.org> *On
>                         Behalf Of *Lukasz Kostyra
>                         *Sent:* Monday, 17 November 2025 15:14
>                         *To:* Christopher Schnick <crschnick at xpipe.io>
>                         <mailto:crschnick at xpipe.io>
>                         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                         <mailto:openjfx-dev at openjdk.org>
>                         *Subject:* RE: Re: JavaFX Direct3D 12 - Second
>                         EA release
>
>                         I might?ve found the problem, there is an
>                         assertion that triggers when multiple text
>                         objects using different fonts are drawn. It
>                         could be related (AFAIK Label controls will
>                         eventually end up at the same text rendering
>                         routines as Text nodes). Assertions are
>                         compiled out on Release for performance, so
>                         there is a chance it would corrupt the
>                         rendering without anything meaningful shown on
>                         screen.
>
>                         To track this I just filed
>                         https://bugs.openjdk.org/browse/JDK-8371995 .
>                         I will check it and let you know when I fix it.
>
>                         On your side It might still be handy to build
>                         JFX in DebugNative, to confirm if the
>                         triggered assertion is the same and to later
>                         confirm if the fix is working for you too.
>
>                         -Lukasz
>
>                         *From:*Christopher Schnick <crschnick at xpipe.io>
>                         *Sent:* Saturday, 15 November 2025 17:39
>                         *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                         *Subject:* Re: [External] : Re: JavaFX
>                         Direct3D 12 - Second EA release
>
>                         Forgot to add, there is nothing out of the
>                         ordinary printed in the verbose logs.
>
>                         If I find the time, I can look into compiling
>                         a debug build.
>
>                         But the problem should be reproducible somehow
>                         when just automatically creating a lot of
>                         labels with random styles, sizes, and text.
>                         Some of them should break as they did for me.
>
>                         On 15/11/2025 17:34, Christopher Schnick wrote:
>
>                             Ok, so I had more time to debug it. The
>                             one weird thing I observed when it was
>                             working was that some labels have
>                             corrupted text rendering:
>
>
>                             Not all of them, most are fine. There are
>                             no differences in terms of style classes
>                             etc. between the labels. When scrolling,
>                             the rendering sometimes switches between
>                             this corrupted and normal state after some
>                             delay.
>
>                             After a while I also figured out that text
>                             rendering is responsible for the issue of
>                             the nodes vanishing: Certain label
>                             contents broke the renderer. For example,
>                             in my application, the string "Password
>                             manager" when assigned to a label broke it
>                             and nothing was rendered anymore. I tried
>                             to find an easy reproducer but was not
>                             able to. It's probably very dependent on
>                             all the different style classes that
>                             influence the text shape/size/etc.
>
>                             On 13/11/2025 16:30, Lukasz Kostyra wrote:
>
>                                 Thanks for checking.
>
>                                 It is very possible the D3D12 runtime
>                                 did not like something, could be
>                                 related to your specific hardware.
>                                 D3D12 by now has many extensions which
>                                 differ depending on hardware and can
>                                 lift certain restrictions - we already
>                                 internally had a case where one GPU
>                                 had some restriction that was not
>                                 enforced on another GPU and we had to
>                                 accommodate that.
>
>                                 The first step would be to try running
>                                 D3D12 with ?-Dprism.verbose=true
>                                 -Dprism.debug=true?. These should
>                                 print additional logs that might have
>                                 some extra information.
>
>                                 If there?s nothing useful there, next
>                                 step would be to build JavaFX with
>                                 -PCONF=DebugNative - this will compile
>                                 shaders in Debug, add assertions and
>                                 debug logs to the backend - and then
>                                 run your app with D3D12 debug layers
>                                 and GPU debugging enabled by adding
>                                 ?-Dprsim.d3d12.debugLayers=true
>                                 -Dprism.d3d12.gpuDebug=true?. Those
>                                 will slow down the app significantly,
>                                 but will also tell D3D12 to run
>                                 additional API use and GPU use checks.
>
>                                 If the problem happens during a render
>                                 loop and debug layers catch it, there
>                                 is a chance it will cascade into other
>                                 errors and spam the console output -
>                                 you can tell D3D12 debug layers to
>                                 trigger an assertion on first
>                                 encountered error with
>                                 ?-Dprism.d3d12.breakOnError=true?.
>
>                                 I am running out of time today to
>                                 check this myself, but if you find
>                                 something let me know - I?ll try to
>                                 reproduce the problem myself and we?ll
>                                 see where we go from there.
>
>                                 Good luck!
>
>                                 - Lukasz
>
>                                 *From:*Christopher Schnick
>                                 <crschnick at xpipe.io>
>                                 <mailto:crschnick at xpipe.io>
>                                 *Sent:* Thursday, 13 November 2025 16:11
>                                 *To:* Lukasz Kostyra
>                                 <lukasz.kostyra at oracle.com>
>                                 <mailto:lukasz.kostyra at oracle.com>
>                                 *Cc:* openjfx-dev at openjdk.org
>                                 *Subject:* [External] : Re: JavaFX
>                                 Direct3D 12 - Second EA release
>
>                                 I just tried to run a project with
>                                 provided jmods and at some point,
>                                 certain nodes are just not rendered
>                                 anymore and the window contents
>                                 vanish. But they render for a short
>                                 period of time.
>
>                                 There is no exception thrown as far as
>                                 I can see, so not sure what you need
>                                 for debugging.
>
>                                 For testing, this is the built
>                                 application with the d3d12 jmods that
>                                 you can use to attempt to reproduce
>                                 the problem:
>                                 https://we.tl/t-DJuX0BeqXm
>                                 <https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$>
>                                 . It is built from these sources:
>                                 https://github.com/xpipe-io/kickstartfx
>                                 <https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
>
>                                 On 13/11/2025 14:40, Lukasz Kostyra wrote:
>
>                                     Hello openjfx-dev,
>
>                                     The second Early Access(EA) build
>                                     of JavaFX with the Windows
>                                     Direct3D 12 rendering pipeline is
>                                     now available at:
>                                     https://jdk.java.net/javafxdirect3d12/
>                                     <https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>
>
>                                     Please test this bundle and share
>                                     your feedback by:
>
>                                     - emailing
>                                     openjfx-dev at openjdk.java.net or
>
>                                     - reporting issues via
>                                     JBS[https://bugs.openjdk.org/] or
>                                     at https://bugreport.java.com
>                                     <https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>
>
>                                     This is the second EA release. The
>                                     backend is feature-complete and
>                                     went through a first optimization
>                                     pass, but it still requires some
>                                     more testing on more hardware
>                                     variants before we can consider it
>                                     complete. As such, with this
>                                     release we also would like to call
>                                     for help with performance testing
>                                     the backend (more details on that
>                                     will be sent in a separate email
>                                     thread).
>
>                                     Known issues and pending tasks are
>                                     captured on JBS and can be
>                                     accessed using the filter provided
>                                     on the Direct3D 12 EA page
>                                     [https://jdk.java.net/javafxdirect3d12/
>                                     <https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>].
>                                     Before reporting a new bug, please
>                                     review the existing issues to
>                                     avoid duplicates.
>
>                                     Important Notes:
>
>                                     1. This is a Windows-specific
>                                     feature, so only a
>                                     Windows-specific bundle is provided.
>
>                                     2. The default rendering pipeline
>                                     is set to d3d12. Use
>                                     "-Dprism.order=d3d" or
>                                     "-Dprism.order=sw" to select one
>                                     of the other pipelines for
>                                     comparison testing.
>
>                                     3. It is recommended to use JDK 25
>                                     or later.
>
>                                     4. At this stage D3D12 backend is
>                                     feature-complete and went through
>                                     the first phase of optimization.
>                                     It is worth noting that, while
>                                     generally we noticed performance
>                                     improvements, it might not be on
>                                     par with D3D backend on every
>                                     machine combo? - we already noted
>                                     performance being worse on recent
>                                     NVidia discrete GPUs
>                                     [https://bugs.openjdk.org/browse/JDK-8370486]
>                                     and are looking for solutions.
>
>                                     5. Issue behavior may vary across
>                                     different hardware, so please
>                                     provide detailed information, such
>                                     as the output of "java
>                                     -Dprism.verbose=true" or used
>                                     hardware, when reporting or
>                                     discussing issues.
>
>                                     6. Refer: Run HelloWorld using
>                                     JavaFX SDK
>                                     [https://openjfx.io/openjfx-docs/#install-javafx
>                                     <https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]
>
>                                     We look forward to your feedback.
>
>                                     Regards,
>
>                                     Lukasz
>
>                                     Confidential- Oracle Internal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/9a0d1b62/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wbZNSCRMO1m9sFIV.png
Type: image/png
Size: 26376 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/9a0d1b62/wbZNSCRMO1m9sFIV-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 18275 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/9a0d1b62/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 57114 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/9a0d1b62/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menubar.mp4
Type: video/mp4
Size: 567183 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/9a0d1b62/menubar-0001.mp4>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corruption.mp4
Type: video/mp4
Size: 1597036 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/9a0d1b62/corruption-0001.mp4>

From lukasz.kostyra at oracle.com  Mon Feb  2 15:06:28 2026
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Mon, 2 Feb 2026 15:06:28 +0000
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B6FC6AF955C783A9EA92AFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B9292A1E528D3FB529977FEA3A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io>
 <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B024908A4D6D3DFACDF4DFE89A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
Message-ID: <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Thanks for checking.

I also see the popup windows in MonkeyTester have this glitch, but on my machine it only happens once. R

From: Christopher Schnick <crschnick at xpipe.io>
Sent: Monday, 2 February 2026 16:00
To: Lukasz Kostyra <lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Looks good, the font looks correct now.

I went through most of the application to see if there's anything else. In the MonkeyTester page, I found this issue with popup windows in the menu bar and shadows I guess? In the d3d9 build, this does not occur. Video is attached.

If you get around to reviewing https://github.com/openjdk/jfx/pull/2058<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/2058__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXfZsrqcq$>, you can use the same testing system to also run kickstartfx with d3d12 as that is also broken in various ways on there.

With our main application, I am getting render corruption issues as shown in the video. I can also give instructions on how to run that application, it is very similar to kickstartfx. Just needs a bit more setup.

Other than that, as mentioned by Martin I think, the translucent background fill for the UNIFIED stage style does not show correctly in kickstartfx if you compare it to the normal build. The left sidebar frame should have the proper window theme color when the performance mode is disabled, however it is only white or black, depending on the system theme:

[cid:image001.png at 01DC945D.DFD6FBF0]


On 02/02/2026 12:36, Lukasz Kostyra wrote:
This should be the final attempt at resolving this topic once and for all :)

I pushed https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXdE2KA0-$> just now which in my testing makes KickstartFX work properly even on UploadingPainter. After quite a bit of testing and scrolling it seems to me the corrupted font issues are now resolved. Please give it a go and let me know if it works on your end.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 29 January 2026 14:38
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today?

Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Thursday, 29 January 2026 13:31
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking?

The good news is that  https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged.
On 29/01/2026 12:02, Lukasz Kostyra wrote:
I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled?

That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis.

As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed.

For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line.

I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter.

Let me know if KickstartFX runs properly with PresentingPainter.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Wednesday, 21 January 2026 13:54
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu)

On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations.

You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install<https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
On 21/01/2026 13:48, Lukasz Kostyra wrote:
Thanks for checking.

I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine.

I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :)

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Tuesday, 20 January 2026 16:24
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


In our main application I am getting the following error spammed in the logs:

16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture>(BaseGraphics.java:464)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture>(BaseShaderGraphics.java:159)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent>(NGImageView.java:123)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender>(NGImageView.java:103)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint>(ViewPainter.java:481)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl>(ViewPainter.java:329)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run>(UploadingPainter.java:143)
16:18:08:572 - error:     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)

In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues.
On 20/01/2026 15:40, Lukasz Kostyra wrote:
Hi Christopher,

After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$> and according to my local testing everything seems to be fine now.

When you have a moment, could you check out the changes above and let me know if everything works correctly in your app?

If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$> you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app.

Regards,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Wednesday, 10 December 2025 13:29
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

It should work fine without the property. Thanks for your help, I?ll keep searching.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Tuesday, 9 December 2025 17:10
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works.

Or should I still pass the property in this commit as well?
On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
Hi Christopher,

I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$> . Let me know how it works and if the problem has been resolved.

Thanks,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 4 December 2025 11:52
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Wednesday, 3 December 2025 18:53
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false
On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
Hi Christopher,

I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$> to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead.

When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line?

If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down.

Thanks,
-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Friday, 28 November 2025 13:25
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I did not encounter the vanishing issue anymore with that build, so at least it is usable.

However, the font rendering issue still exists for some nodes:

[cid:image002.png at 01DC945D.DFD6FBF0]

It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly.

Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit.
On 28/11/2025 12:41, Lukasz Kostyra wrote:
Hi Christopher,

I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$> . If you find a moment, could you build JFX from that branch and check if your app works correctly?

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 17 November 2025 15:14
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen.

To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it.

On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Saturday, 15 November 2025 17:39
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Forgot to add, there is nothing out of the ordinary printed in the verbose logs.

If I find the time, I can look into compiling a debug build.

But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me.
On 15/11/2025 17:34, Christopher Schnick wrote:

Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering:

[cid:image003.png at 01DC945D.DFD6FBF0]

Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay.

After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc.
On 13/11/2025 16:30, Lukasz Kostyra wrote:
Thanks for checking.

It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that.

The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information.

If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks.

If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?.

I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there.

Good luck!
- Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Thursday, 13 November 2025 16:11
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time.

There is no exception thrown as far as I can see, so not sure what you need for debugging.

For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm<https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$> . It is built from these sources: https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
On 13/11/2025 14:40, Lukasz Kostyra wrote:
Hello openjfx-dev,

The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com<https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>

This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread).

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 25 or later.
4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo  - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions.
5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx<https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]

We look forward to your feedback.

Regards,
Lukasz


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/f609b7e1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26376 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/f609b7e1/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18275 bytes
Desc: image002.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/f609b7e1/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 57114 bytes
Desc: image003.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/f609b7e1/image003-0001.png>

From lukasz.kostyra at oracle.com  Mon Feb  2 15:09:29 2026
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Mon, 2 Feb 2026 15:09:29 +0000
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B6FC6AF955C783A9EA92AFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B9292A1E528D3FB529977FEA3A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io>
 <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B024908A4D6D3DFACDF4DFE89A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
 <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
Message-ID: <DM3PPF3367D7B9B03B9B31653966CF488F0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Uh, let me finish that email - a random Windows popup appeared while typing which caused my mail client lose focus and interpret typing as shortcuts?

Anyway, I also see the popup windows have this glitch. I will take a closer look at them soon.

As for your other corruption issues, can you check with -Dprism.d3d12.clearOpts=false ? I have a strong suspicion that optimization would be the one to blame again - I was planning to rework it a bit more soon anyway, so it might be a good test candidate for that.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 2 February 2026 16:06
To: Christopher Schnick <crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: RE: [External] : Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking.

I also see the popup windows in MonkeyTester have this glitch, but on my machine it only happens once. R

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Monday, 2 February 2026 16:00
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Looks good, the font looks correct now.

I went through most of the application to see if there's anything else. In the MonkeyTester page, I found this issue with popup windows in the menu bar and shadows I guess? In the d3d9 build, this does not occur. Video is attached.

If you get around to reviewing https://github.com/openjdk/jfx/pull/2058<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/2058__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXfZsrqcq$>, you can use the same testing system to also run kickstartfx with d3d12 as that is also broken in various ways on there.

With our main application, I am getting render corruption issues as shown in the video. I can also give instructions on how to run that application, it is very similar to kickstartfx. Just needs a bit more setup.

Other than that, as mentioned by Martin I think, the translucent background fill for the UNIFIED stage style does not show correctly in kickstartfx if you compare it to the normal build. The left sidebar frame should have the proper window theme color when the performance mode is disabled, however it is only white or black, depending on the system theme:

[cid:image001.png at 01DC945E.4C0FC1D0]


On 02/02/2026 12:36, Lukasz Kostyra wrote:
This should be the final attempt at resolving this topic once and for all :)

I pushed https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXdE2KA0-$> just now which in my testing makes KickstartFX work properly even on UploadingPainter. After quite a bit of testing and scrolling it seems to me the corrupted font issues are now resolved. Please give it a go and let me know if it works on your end.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 29 January 2026 14:38
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today?

Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Thursday, 29 January 2026 13:31
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking?

The good news is that  https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged.
On 29/01/2026 12:02, Lukasz Kostyra wrote:
I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled?

That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis.

As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed.

For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line.

I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter.

Let me know if KickstartFX runs properly with PresentingPainter.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Wednesday, 21 January 2026 13:54
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu)

On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations.

You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install<https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
On 21/01/2026 13:48, Lukasz Kostyra wrote:
Thanks for checking.

I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine.

I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :)

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Tuesday, 20 January 2026 16:24
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


In our main application I am getting the following error spammed in the logs:

16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture>(BaseGraphics.java:464)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture>(BaseShaderGraphics.java:159)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent>(NGImageView.java:123)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender>(NGImageView.java:103)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint>(ViewPainter.java:481)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl>(ViewPainter.java:329)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run>(UploadingPainter.java:143)
16:18:08:572 - error:     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)

In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues.
On 20/01/2026 15:40, Lukasz Kostyra wrote:
Hi Christopher,

After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$> and according to my local testing everything seems to be fine now.

When you have a moment, could you check out the changes above and let me know if everything works correctly in your app?

If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$> you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app.

Regards,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Wednesday, 10 December 2025 13:29
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

It should work fine without the property. Thanks for your help, I?ll keep searching.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Tuesday, 9 December 2025 17:10
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works.

Or should I still pass the property in this commit as well?
On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
Hi Christopher,

I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$> . Let me know how it works and if the problem has been resolved.

Thanks,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 4 December 2025 11:52
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Wednesday, 3 December 2025 18:53
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false
On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
Hi Christopher,

I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$> to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead.

When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line?

If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down.

Thanks,
-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Friday, 28 November 2025 13:25
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I did not encounter the vanishing issue anymore with that build, so at least it is usable.

However, the font rendering issue still exists for some nodes:

[cid:image002.png at 01DC945E.4C0FC1D0]

It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly.

Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit.
On 28/11/2025 12:41, Lukasz Kostyra wrote:
Hi Christopher,

I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$> . If you find a moment, could you build JFX from that branch and check if your app works correctly?

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 17 November 2025 15:14
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen.

To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it.

On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Saturday, 15 November 2025 17:39
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Forgot to add, there is nothing out of the ordinary printed in the verbose logs.

If I find the time, I can look into compiling a debug build.

But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me.
On 15/11/2025 17:34, Christopher Schnick wrote:

Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering:

[cid:image003.png at 01DC945E.4C0FC1D0]

Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay.

After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc.
On 13/11/2025 16:30, Lukasz Kostyra wrote:
Thanks for checking.

It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that.

The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information.

If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks.

If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?.

I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there.

Good luck!
- Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Thursday, 13 November 2025 16:11
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time.

There is no exception thrown as far as I can see, so not sure what you need for debugging.

For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm<https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$> . It is built from these sources: https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
On 13/11/2025 14:40, Lukasz Kostyra wrote:
Hello openjfx-dev,

The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com<https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>

This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread).

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 25 or later.
4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo  - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions.
5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx<https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]

We look forward to your feedback.

Regards,
Lukasz


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/3ba1686f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26376 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/3ba1686f/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18275 bytes
Desc: image002.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/3ba1686f/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 57114 bytes
Desc: image003.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/3ba1686f/image003-0001.png>

From crschnick at xpipe.io  Mon Feb  2 15:13:41 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Mon, 2 Feb 2026 16:13:41 +0100
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9B03B9B31653966CF488F0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B024908A4D6D3DFACDF4DFE89A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
 <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B03B9B31653966CF488F0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
Message-ID: <9fecab86-2b6d-4854-81dd-a55096908ea3@xpipe.io>

Yes, the corruption issues are fixed with that property

On 02/02/2026 16:09, Lukasz Kostyra wrote:
>
> Uh, let me finish that email - a random Windows popup appeared while 
> typing which caused my mail client lose focus and interpret typing as 
> shortcuts?
>
> Anyway, I also see the popup windows have this glitch. I will take a 
> closer look at them soon.
>
> As for your other corruption issues, can you check with 
> -Dprism.d3d12.clearOpts=false ? I have a strong suspicion that 
> optimization would be the one to blame again - I was planning to 
> rework it a bit more soon anyway, so it might be a good test candidate 
> for that.
>
> -Lukasz
>
> *From:*openjfx-dev <openjfx-dev-retn at openjdk.org> *On Behalf Of 
> *Lukasz Kostyra
> *Sent:* Monday, 2 February 2026 16:06
> *To:* Christopher Schnick <crschnick at xpipe.io>
> *Cc:* OpenJFX <openjfx-dev at openjdk.org>
> *Subject:* RE: [External] : Re: JavaFX Direct3D 12 - Second EA release
>
> Thanks for checking.
>
> I also see the popup windows in MonkeyTester have this glitch, but on 
> my machine it only happens once. R
>
> *From:*Christopher Schnick <crschnick at xpipe.io>
> *Sent:* Monday, 2 February 2026 16:00
> *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
> *Cc:* OpenJFX <openjfx-dev at openjdk.org>
> *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
> Looks good, the font looks correct now.
>
> I went through most of the application to see if there's anything 
> else. In the MonkeyTester page, I found this issue with popup windows 
> in the menu bar and shadows I guess? In the d3d9 build, this does not 
> occur. Video is attached.
>
> If you get around to reviewing 
> https://github.com/openjdk/jfx/pull/2058 
> <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/2058__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXfZsrqcq$>, 
> you can use the same testing system to also run kickstartfx with d3d12 
> as that is also broken in various ways on there.
>
> With our main application, I am getting render corruption issues as 
> shown in the video. I can also give instructions on how to run that 
> application, it is very similar to kickstartfx. Just needs a bit more 
> setup.
>
> Other than that, as mentioned by Martin I think, the translucent 
> background fill for the UNIFIED stage style does not show correctly in 
> kickstartfx if you compare it to the normal build. The left sidebar 
> frame should have the proper window theme color when the performance 
> mode is disabled, however it is only white or black, depending on the 
> system theme:
>
> On 02/02/2026 12:36, Lukasz Kostyra wrote:
>
>     This should be the final attempt at resolving this topic once and
>     for all :)
>
>     I pushed
>     https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34
>     <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXdE2KA0-$>
>     just now which in my testing makes KickstartFX work properly even
>     on UploadingPainter. After quite a bit of testing and scrolling it
>     seems to me the corrupted font issues are now resolved. Please
>     give it a go and let me know if it works on your end.
>
>     -Lukasz
>
>     *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> *On Behalf Of *Lukasz Kostyra
>     *Sent:* Thursday, 29 January 2026 14:38
>     *To:* Christopher Schnick <crschnick at xpipe.io>
>     <mailto:crschnick at xpipe.io>
>     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release
>
>     Indeed it is still there, although on my machine it happens less
>     with Presenting Painter. I tried it a couple of times before
>     sending the email and it worked fine, so seems like I should also
>     go buy a lottery ticket today?
>
>     Well, good news to me is that this happens on PresentingPainter,
>     so I now have some more possibilities in terms of debugging it
>     in-place. I?ll get back to you when it?s fixed.
>
>     -Lukasz
>
>     *From:*Christopher Schnick <crschnick at xpipe.io>
>     *Sent:* Thursday, 29 January 2026 13:31
>     *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>     *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>     I commented out the uploading painter line and still see the same
>     issue. As you say, it shouldn't make a difference. Maybe you hit
>     the one time where the issue just didn't occur statistically speaking?
>
>     The good news is that
>     https://bugs.openjdk.org/browse/JDK-8154847?should be finally
>     fixed by the new translucent backdrop PR, so it shouldn't need
>     this property anymore in the future when it is merged.
>
>     On 29/01/2026 12:02, Lukasz Kostyra wrote:
>
>         I looked through KickstartFX and I noticed there?s a point
>         where KickstartFX forces the use of Uploading Painter -
>         PlatformState.java @ 112. UploadingPainter was designed to
>         work with software pipeline as a fallback mechanism (SW does
>         not have the SwapChain/Presentation mechanisms that HW
>         pipelines use) so using it with hardware-accelerated pipelines
>         is not officially supported. When I set
>         prism.forceUploadingPainter to false text and buttons rendered
>         correctly with D3D12 on my machine. Could you check if
>         everything works fine on your end with UploadingPainter disabled?
>
>         That being said, I do agree there should technically be no
>         visual difference between PresentingPainter and
>         UploadingPainter. I have some theories as to why that would be
>         the case, but because UploadingPainter with hardware pipelines
>         is not officially supported I?ll have to push this issue
>         towards a later point in time. UploadingPainter makes this a
>         bit extra difficult to debug because graphics debuggers rely
>         on applications calling Present() to determine when the
>         application progresses to the next frame - with
>         UploadingPainter no Present() is called and debuggers can?t
>         capture the frame properly for analysis.
>
>         As for Hyper-V problems - I didn?t get a chance to test these
>         yet but we also did not try running JavaFX with D3D12 backend
>         on virtualized platforms. I will take a look at that use case
>         also at a later point in time, once the performance
>         improvements are completed.
>
>         For both of these (UploadingPainter issues and Hyper-V issues)
>         I?ll add separate bugs to my backlog and tackle them later
>         down the line.
>
>         I also checked why UploadingPainter was preferred in
>         KickstartFX and this seems to be the issue -
>         https://bugs.openjdk.org/browse/JDK-8154847. If what Martin
>         mentioned in comment history is correct, there?s a possibility
>         that with D3D12 there should be no transparency issues, as
>         D3D12 defaults to alpha-supported SwapChain buffer (BGRX
>         format exists but presents some technical issues and
>         limitations, BGRA is more convenient). However I had no way of
>         verifying this theory, on my Intel Iris Xe laptop the
>         reproducer works as expected on both D3D and D3D12, with or
>         without UploadingPainter.
>
>         Let me know if KickstartFX runs properly with PresentingPainter.
>
>         -Lukasz
>
>         *From:*Christopher Schnick <crschnick at xpipe.io>
>         <mailto:crschnick at xpipe.io>
>         *Sent:* Wednesday, 21 January 2026 13:54
>         *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>         <mailto:lukasz.kostyra at oracle.com>
>         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>         <mailto:openjfx-dev at openjdk.org>
>         *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>         Alright, that is good to know. I also ran the d3d12 build in a
>         Hyper-V Windows 11 VM, which are known to cause issues. For
>         example, this issue happens in those VMs with
>         StageStyle.UNIFIED:
>         https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses
>         the unified stage style unless you turn on performance mode in
>         the settings menu)
>
>         On that system, the app sometimes froze completely, sometimes,
>         the rendered image got stuck. Changing the performance mode
>         setting and the property?-Dprism.forceUploadingPainter=true
>         changed the behavior, but it was broken in some way in all
>         configurations.
>
>         You should be able to reproduce these issues easily with the
>         Windows Sandbox feature:
>         https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install
>         <https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
>
>         On 21/01/2026 13:48, Lukasz Kostyra wrote:
>
>             Thanks for checking.
>
>             I ran the KickstartFX build one more time, it failed but I
>             found some leftover global gradle.properties file which
>             defined older JDK which broke the build. Changing JDK to
>             25.0.1 everything built and works fine.
>
>             I also found a way to build KickstartFX using custom JFX
>             (customJavaFxLibsPath in build.gradle) and can reproduce
>             your font issues locally on D3D12. I?ll report back when I
>             solve them on my end. :)
>
>             -Lukasz
>
>             *From:*Christopher Schnick <crschnick at xpipe.io>
>             <mailto:crschnick at xpipe.io>
>             *Sent:* Tuesday, 20 January 2026 16:24
>             *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>             <mailto:lukasz.kostyra at oracle.com>
>             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>             <mailto:openjfx-dev at openjdk.org>
>             *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA
>             release
>
>             In our main application I am getting the following error
>             spammed in the logs:
>
>             16:18:08:571 - error: java.lang.NullPointerException:
>             Cannot invoke "com.sun.prism.Texture.getPixelFormat()"
>             because "tex" is null
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:571 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329)
>             16:18:08:572 - error:? ? ?at
>             javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143)
>             16:18:08:572 - error:? ? ?at
>             java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
>             16:18:08:572 - error:? ? ?at
>             java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
>             16:18:08:572 - error:? ? ?at
>             java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
>
>             In kickstartfx, I still get the font rendering issues. Can
>             you share the problems you encountered? I tried to build
>             it on a blank VM with git clone, setting a JDK25 in the
>             PATH, and running gradlew.bat run without issues.
>
>             On 20/01/2026 15:40, Lukasz Kostyra wrote:
>
>                 Hi Christopher,
>
>                 After Christmas break I came back to this issue with
>                 some new patches. There were some problems I found
>                 with the clear optimization, I just submitted
>                 https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31
>                 <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$>
>                 and according to my local testing everything seems to
>                 be fine now.
>
>                 When you have a moment, could you check out the
>                 changes above and let me know if everything works
>                 correctly in your app?
>
>                 If there are still problems I would like to find a way
>                 to build your app and test it locally. I tried doing
>                 that earlier via
>                 https://github.com/xpipe-io/kickstartfx
>                 <https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
>                 you linked earlier but encountered some problems when
>                 building, so I?m going to need your help or some
>                 instructions on how to build the app.
>
>                 Regards,
>
>                 -Lukasz
>
>                 *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>                 <mailto:openjfx-dev-retn at openjdk.org> *On Behalf Of
>                 *Lukasz Kostyra
>                 *Sent:* Wednesday, 10 December 2025 13:29
>                 *To:* Christopher Schnick <crschnick at xpipe.io>
>                 <mailto:crschnick at xpipe.io>
>                 *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                 <mailto:openjfx-dev at openjdk.org>
>                 *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release
>
>                 It should work fine without the property. Thanks for
>                 your help, I?ll keep searching.
>
>                 -Lukasz
>
>                 *From:*Christopher Schnick <crschnick at xpipe.io>
>                 *Sent:* Tuesday, 9 December 2025 17:10
>                 *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                 *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                 *Subject:* [External] : Re: JavaFX Direct3D 12 -
>                 Second EA release
>
>                 I tried this commit, but the problem shows up again. I
>                 tested the previous commit with the passed property
>                 again, and that one still works.
>
>                 Or should I still pass the property in this commit as
>                 well?
>
>                 On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
>
>                     Hi Christopher,
>
>                     I updated the direct3d12 branch with the fix -
>                     https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8
>                     <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$>
>                     . Let me know how it works and if the problem has
>                     been resolved.
>
>                     Thanks,
>
>                     -Lukasz
>
>                     *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>                     <mailto:openjfx-dev-retn at openjdk.org> *On Behalf
>                     Of *Lukasz Kostyra
>                     *Sent:* Thursday, 4 December 2025 11:52
>                     *To:* Christopher Schnick <crschnick at xpipe.io>
>                     <mailto:crschnick at xpipe.io>
>                     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                     <mailto:openjfx-dev at openjdk.org>
>                     *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA
>                     release
>
>                     Thanks for checking. I filed
>                     https://bugs.openjdk.org/browse/JDK-8373088 to
>                     track this since this is unrelated to specifically
>                     text, will probably get to it in a few days.
>
>                     -Lukasz
>
>                     *From:*Christopher Schnick <crschnick at xpipe.io>
>                     *Sent:* Wednesday, 3 December 2025 18:53
>                     *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                     *Subject:* [External] : Re: JavaFX Direct3D 12 -
>                     Second EA release
>
>                     This commit fixes the problem when the property is
>                     set to false and it shows up again if the property
>                     is not set to false
>
>                     On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
>
>                         Hi Christopher,
>
>                         I did not find the way to reproduce this
>                         locally, but I found a problem with one of the
>                         optimizations that is in the backend. To
>                         double check if that is in fact the issue I
>                         pushed
>                         https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89
>                         <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$>
>                         to disable the optimization (it is on by
>                         default, disabling it fixes that specific
>                         problem on my end) and I?d like to
>                         double-check if this is the correct lead.
>
>                         When you have a moment, could you build JFX
>                         with that change and run your app with
>                         ?-Dprism.d3d12.clearOpts=false? added to the
>                         command line?
>
>                         If the problem persists with
>                         prism.d3d12.clearOpts set to false I would
>                         need some more information on how these labels
>                         are rendered to track this down.
>
>                         Thanks,
>
>                         -Lukasz
>
>                         *From:*Christopher Schnick
>                         <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>                         *Sent:* Friday, 28 November 2025 13:25
>                         *To:* Lukasz Kostyra
>                         <lukasz.kostyra at oracle.com>
>                         <mailto:lukasz.kostyra at oracle.com>
>                         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                         <mailto:openjfx-dev at openjdk.org>
>                         *Subject:* [External] : Re: JavaFX Direct3D 12
>                         - Second EA release
>
>                         I did not encounter the vanishing issue
>                         anymore with that build, so at least it is usable.
>
>                         However, the font rendering issue still exists
>                         for some nodes:
>
>                         It is not deterministic, meaning that if I
>                         just scroll the scrollpane forward and back,
>                         the same text might get rendered correctly.
>
>                         Also, did you see the performance results I
>                         posted for my AMD system? Performance was
>                         quite bad there, so this is not in a stage
>                         where I can test this in production a bit.
>
>                         On 28/11/2025 12:41, Lukasz Kostyra wrote:
>
>                             Hi Christopher,
>
>                             I just pushed a fix for JDK-8371995 onto
>                             direct3d12 branch in the sandbox -
>                             https://github.com/openjdk/jfx-sandbox/tree/direct3d12
>                             <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$>
>                             . If you find a moment, could you build
>                             JFX from that branch and check if your app
>                             works correctly?
>
>                             -Lukasz
>
>                             *From:*openjfx-dev
>                             <openjfx-dev-retn at openjdk.org>
>                             <mailto:openjfx-dev-retn at openjdk.org> *On
>                             Behalf Of *Lukasz Kostyra
>                             *Sent:* Monday, 17 November 2025 15:14
>                             *To:* Christopher Schnick
>                             <crschnick at xpipe.io>
>                             <mailto:crschnick at xpipe.io>
>                             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                             <mailto:openjfx-dev at openjdk.org>
>                             *Subject:* RE: Re: JavaFX Direct3D 12 -
>                             Second EA release
>
>                             I might?ve found the problem, there is an
>                             assertion that triggers when multiple text
>                             objects using different fonts are drawn.
>                             It could be related (AFAIK Label controls
>                             will eventually end up at the same text
>                             rendering routines as Text nodes).
>                             Assertions are compiled out on Release for
>                             performance, so there is a chance it would
>                             corrupt the rendering without anything
>                             meaningful shown on screen.
>
>                             To track this I just filed
>                             https://bugs.openjdk.org/browse/JDK-8371995
>                             . I will check it and let you know when I
>                             fix it.
>
>                             On your side It might still be handy to
>                             build JFX in DebugNative, to confirm if
>                             the triggered assertion is the same and to
>                             later confirm if the fix is working for
>                             you too.
>
>                             -Lukasz
>
>                             *From:*Christopher Schnick
>                             <crschnick at xpipe.io>
>                             *Sent:* Saturday, 15 November 2025 17:39
>                             *To:* Lukasz Kostyra
>                             <lukasz.kostyra at oracle.com>
>                             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                             *Subject:* Re: [External] : Re: JavaFX
>                             Direct3D 12 - Second EA release
>
>                             Forgot to add, there is nothing out of the
>                             ordinary printed in the verbose logs.
>
>                             If I find the time, I can look into
>                             compiling a debug build.
>
>                             But the problem should be reproducible
>                             somehow when just automatically creating a
>                             lot of labels with random styles, sizes,
>                             and text. Some of them should break as
>                             they did for me.
>
>                             On 15/11/2025 17:34, Christopher Schnick
>                             wrote:
>
>                                 Ok, so I had more time to debug it.
>                                 The one weird thing I observed when it
>                                 was working was that some labels have
>                                 corrupted text rendering:
>
>
>                                 Not all of them, most are fine. There
>                                 are no differences in terms of style
>                                 classes etc. between the labels. When
>                                 scrolling, the rendering sometimes
>                                 switches between this corrupted and
>                                 normal state after some delay.
>
>                                 After a while I also figured out that
>                                 text rendering is responsible for the
>                                 issue of the nodes vanishing: Certain
>                                 label contents broke the renderer. For
>                                 example, in my application, the string
>                                 "Password manager" when assigned to a
>                                 label broke it and nothing was
>                                 rendered anymore. I tried to find an
>                                 easy reproducer but was not able to.
>                                 It's probably very dependent on all
>                                 the different style classes that
>                                 influence the text shape/size/etc.
>
>                                 On 13/11/2025 16:30, Lukasz Kostyra wrote:
>
>                                     Thanks for checking.
>
>                                     It is very possible the D3D12
>                                     runtime did not like something,
>                                     could be related to your specific
>                                     hardware. D3D12 by now has many
>                                     extensions which differ depending
>                                     on hardware and can lift certain
>                                     restrictions - we already
>                                     internally had a case where one
>                                     GPU had some restriction that was
>                                     not enforced on another GPU and we
>                                     had to accommodate that.
>
>                                     The first step would be to try
>                                     running D3D12 with
>                                     ?-Dprism.verbose=true
>                                     -Dprism.debug=true?. These should
>                                     print additional logs that might
>                                     have some extra information.
>
>                                     If there?s nothing useful there,
>                                     next step would be to build JavaFX
>                                     with -PCONF=DebugNative - this
>                                     will compile shaders in Debug, add
>                                     assertions and debug logs to the
>                                     backend - and then run your app
>                                     with D3D12 debug layers and GPU
>                                     debugging enabled by adding
>                                     ?-Dprsim.d3d12.debugLayers=true
>                                     -Dprism.d3d12.gpuDebug=true?.
>                                     Those will slow down the app
>                                     significantly, but will also tell
>                                     D3D12 to run additional API use
>                                     and GPU use checks.
>
>                                     If the problem happens during a
>                                     render loop and debug layers catch
>                                     it, there is a chance it will
>                                     cascade into other errors and spam
>                                     the console output - you can tell
>                                     D3D12 debug layers to trigger an
>                                     assertion on first encountered
>                                     error with
>                                     ?-Dprism.d3d12.breakOnError=true?.
>
>                                     I am running out of time today to
>                                     check this myself, but if you find
>                                     something let me know - I?ll try
>                                     to reproduce the problem myself
>                                     and we?ll see where we go from there.
>
>                                     Good luck!
>
>                                     - Lukasz
>
>                                     *From:*Christopher Schnick
>                                     <crschnick at xpipe.io>
>                                     <mailto:crschnick at xpipe.io>
>                                     *Sent:* Thursday, 13 November 2025
>                                     16:11
>                                     *To:* Lukasz Kostyra
>                                     <lukasz.kostyra at oracle.com>
>                                     <mailto:lukasz.kostyra at oracle.com>
>                                     *Cc:* openjfx-dev at openjdk.org
>                                     *Subject:* [External] : Re: JavaFX
>                                     Direct3D 12 - Second EA release
>
>                                     I just tried to run a project with
>                                     provided jmods and at some point,
>                                     certain nodes are just not
>                                     rendered anymore and the window
>                                     contents vanish. But they render
>                                     for a short period of time.
>
>                                     There is no exception thrown as
>                                     far as I can see, so not sure what
>                                     you need for debugging.
>
>                                     For testing, this is the built
>                                     application with the d3d12 jmods
>                                     that you can use to attempt to
>                                     reproduce the problem:
>                                     https://we.tl/t-DJuX0BeqXm
>                                     <https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$>
>                                     . It is built from these sources:
>                                     https://github.com/xpipe-io/kickstartfx
>                                     <https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
>
>                                     On 13/11/2025 14:40, Lukasz
>                                     Kostyra wrote:
>
>                                         Hello openjfx-dev,
>
>                                         The second Early Access(EA)
>                                         build of JavaFX with the
>                                         Windows Direct3D 12 rendering
>                                         pipeline is now available at:
>                                         https://jdk.java.net/javafxdirect3d12/
>                                         <https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>
>
>                                         Please test this bundle and
>                                         share your feedback by:
>
>                                         - emailing
>                                         openjfx-dev at openjdk.java.net or
>
>                                         - reporting issues via
>                                         JBS[https://bugs.openjdk.org/]
>                                         or at
>                                         https://bugreport.java.com
>                                         <https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>
>
>                                         This is the second EA release.
>                                         The backend is
>                                         feature-complete and went
>                                         through a first optimization
>                                         pass, but it still requires
>                                         some more testing on more
>                                         hardware variants before we
>                                         can consider it complete. As
>                                         such, with this release we
>                                         also would like to call for
>                                         help with performance testing
>                                         the backend (more details on
>                                         that will be sent in a
>                                         separate email thread).
>
>                                         Known issues and pending tasks
>                                         are captured on JBS and can be
>                                         accessed using the filter
>                                         provided on the Direct3D 12 EA
>                                         page
>                                         [https://jdk.java.net/javafxdirect3d12/
>                                         <https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>].
>                                         Before reporting a new bug,
>                                         please review the existing
>                                         issues to avoid duplicates.
>
>                                         Important Notes:
>
>                                         1. This is a Windows-specific
>                                         feature, so only a
>                                         Windows-specific bundle is
>                                         provided.
>
>                                         2. The default rendering
>                                         pipeline is set to d3d12. Use
>                                         "-Dprism.order=d3d" or
>                                         "-Dprism.order=sw" to select
>                                         one of the other pipelines for
>                                         comparison testing.
>
>                                         3. It is recommended to use
>                                         JDK 25 or later.
>
>                                         4. At this stage D3D12 backend
>                                         is feature-complete and went
>                                         through the first phase of
>                                         optimization. It is worth
>                                         noting that, while generally
>                                         we noticed performance
>                                         improvements, it might not be
>                                         on par with D3D backend on
>                                         every machine combo? - we
>                                         already noted performance
>                                         being worse on recent NVidia
>                                         discrete GPUs
>                                         [https://bugs.openjdk.org/browse/JDK-8370486]
>                                         and are looking for solutions.
>
>                                         5. Issue behavior may vary
>                                         across different hardware, so
>                                         please provide detailed
>                                         information, such as the
>                                         output of "java
>                                         -Dprism.verbose=true" or used
>                                         hardware, when reporting or
>                                         discussing issues.
>
>                                         6. Refer: Run HelloWorld using
>                                         JavaFX SDK
>                                         [https://openjfx.io/openjfx-docs/#install-javafx
>                                         <https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]
>
>                                         We look forward to your feedback.
>
>                                         Regards,
>
>                                         Lukasz
>
>                                         Confidential- Oracle Internal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/983e3230/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26376 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/983e3230/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18275 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/983e3230/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 57114 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260202/983e3230/image003-0001.png>

From angorya at openjdk.org  Mon Feb  2 15:32:53 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 2 Feb 2026 15:32:53 GMT
Subject: Integrated: 8376735: Update Eclipse projects to use JDK25
In-Reply-To: <Rchk2CmgG39kFza0IDfKvj-Uplpufrmn_vVIhCdgBKw=.3c8ae9e5-46fa-40e1-a703-1e3557e678aa@github.com>
References: <Rchk2CmgG39kFza0IDfKvj-Uplpufrmn_vVIhCdgBKw=.3c8ae9e5-46fa-40e1-a703-1e3557e678aa@github.com>
Message-ID: <vjh6_1YgSFE15Y1JfJJh-Xj5hHFj20LCXilpjXv5EjQ=.5d53d30f-d0d5-49ee-ade2-5252372da381@github.com>

On Fri, 30 Jan 2026 17:56:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Updates Eclipse configuration files and the monkey tester readme to jdk25 requirement introduced in 
> 
> [JDK-8370883](https://bugs.openjdk.org/browse/JDK-8370883) Update boot JDK to 25.0.1
> [JDK-8376601](https://bugs.openjdk.org/browse/JDK-8376601) Bump minimum JDK version for JavaFX to JDK 25

This pull request has now been integrated.

Changeset: bc5630fe
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bc5630fefe43dbf6e0bd6ef51903b932f086dad4
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8376735: Update Eclipse projects to use JDK25

Reviewed-by: jhendrikx

-------------

PR: https://git.openjdk.org/jfx/pull/2059

From mfox at openjdk.org  Mon Feb  2 18:13:47 2026
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 2 Feb 2026 18:13:47 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v72]
In-Reply-To: <FViE6wu_kLXXMlRQlf35SZaB0iP-UzQaMrxDEDTg2WI=.69a005a9-1660-4d74-a136-384fc5c4f0cb@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <FViE6wu_kLXXMlRQlf35SZaB0iP-UzQaMrxDEDTg2WI=.69a005a9-1660-4d74-a136-384fc5c4f0cb@github.com>
Message-ID: <q_H5-A0PUQfr1ht6sXJrLfrXNjYQjuFnZY_xghwtlV4=.abfcab8c-520d-4715-a407-0ffac1e2816d@github.com>

On Sun, 25 Jan 2026 16:05:56 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:
> 
>  - Review fixes
>  - sync headerbar changes
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	tests/system/src/test/java/test/util/Util.java
>  - Merge branch 'master' into 8354943
>  - Remote assumeTrue for JDK-8364547
>  - Merge branch 'master' into 8354943
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp
>  - Merge branch 'master' into 8354943
>  - Fix copyright header
>  - ... and 78 more: https://git.openjdk.org/jfx/compare/055f827e...01e84817

Marked as reviewed by mfox (Committer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-3741116838

From zelmidaoui at openjdk.org  Mon Feb  2 18:17:38 2026
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 2 Feb 2026 18:17:38 GMT
Subject: RFR: 8325564: ComboBox popup does not correctly resize after
 update when on display [v4]
In-Reply-To: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com>
References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com>
Message-ID: <_fvcqe0kdPpbLLh8c08iyQ_oXm5gJxZrpqHnN6Uem0I=.4063cea3-7a21-490e-b0dc-53c8adc2903d@github.com>

> Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list.
> Tested with the test app in bug and MonkeyTester.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Fix scrollbar issue

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/2052/files
  - new: https://git.openjdk.org/jfx/pull/2052/files/29a4d177..9ed0cee1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=02-03

  Stats: 25 lines in 2 files changed: 20 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/2052.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2052/head:pull/2052

PR: https://git.openjdk.org/jfx/pull/2052

From angorya at openjdk.org  Mon Feb  2 19:40:37 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 2 Feb 2026 19:40:37 GMT
Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character [v2]
In-Reply-To: <yq0p0EaMFA1mQL771JbxWgL3boctfQg7MBEIXikRGWI=.06b8a38d-8ee0-47db-b528-0514b7b077de@github.com>
References: <dMB1OyyvFWHLqYwvZEf1i_3snu7lZ4hKy-q1Zf_lM_U=.a60b9d43-efc9-432d-ad50-64d24b389cd9@github.com>
 <yq0p0EaMFA1mQL771JbxWgL3boctfQg7MBEIXikRGWI=.06b8a38d-8ee0-47db-b528-0514b7b077de@github.com>
Message-ID: <t1GznyZRDQgdjswCTW_tVoeY1EH9POdkOBOu3yJmGoQ=.854361c9-049d-40ed-9fc8-f0feb4849713@github.com>

On Wed, 28 Jan 2026 12:11:36 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added "^" character to JavaFX virtual keyboard.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added character to EmailBoard.txt and UrlBoard.txt

Perhaps we can lower the number of reviewers to 1 given the fact that
- the virtual keyboard is not officially supported and only available via system property
- the fix is fairly simple with no dependencies

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3837207382

From angorya at openjdk.org  Mon Feb  2 23:13:02 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 2 Feb 2026 23:13:02 GMT
Subject: RFR: 8325564: ComboBox popup does not correctly resize after
 update when on display [v4]
In-Reply-To: <_fvcqe0kdPpbLLh8c08iyQ_oXm5gJxZrpqHnN6Uem0I=.4063cea3-7a21-490e-b0dc-53c8adc2903d@github.com>
References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com>
 <_fvcqe0kdPpbLLh8c08iyQ_oXm5gJxZrpqHnN6Uem0I=.4063cea3-7a21-490e-b0dc-53c8adc2903d@github.com>
Message-ID: <y94wUvNIHstLIoLbeUiJwVAL_ozqHmi7c1j6cnQZAcU=.42da79a4-150b-4d1d-90ef-109fe9a2a1a7@github.com>

On Mon, 2 Feb 2026 18:17:38 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list.
>> Tested with the test app in bug and MonkeyTester.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix scrollbar issue

Looks much better!

Two things:
1. please change the copyright year to 2026
2. noticed runLater() in `recomputePopupLayout()`, so I decided to apply CSS to the popup.  You can use
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/ComboBox_PopupSize_8325564.java

On my primary retina display I get the scrollbars first time around.  The scrollbars disappear on second showing:

<img width="310" height="391" alt="Screenshot 2026-02-02 at 15 05 29" src="https://github.com/user-attachments/assets/ae5f149a-c845-4f5f-8ed6-5ffa404aed54" />


.combo-box-popup > .list-view {
    -fx-padding: 100px
}

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2052#issuecomment-3837743037

From zelmidaoui at openjdk.org  Mon Feb  2 23:50:08 2026
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 2 Feb 2026 23:50:08 GMT
Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character [v2]
In-Reply-To: <yq0p0EaMFA1mQL771JbxWgL3boctfQg7MBEIXikRGWI=.06b8a38d-8ee0-47db-b528-0514b7b077de@github.com>
References: <dMB1OyyvFWHLqYwvZEf1i_3snu7lZ4hKy-q1Zf_lM_U=.a60b9d43-efc9-432d-ad50-64d24b389cd9@github.com>
 <yq0p0EaMFA1mQL771JbxWgL3boctfQg7MBEIXikRGWI=.06b8a38d-8ee0-47db-b528-0514b7b077de@github.com>
Message-ID: <jnQDHqUx7o-7j-PpzpN0s5NkOYMUdJllpLqYAbfBoNM=.9c9229e2-19f3-4eea-92ee-2c717fe7a60b@github.com>

On Wed, 28 Jan 2026 12:11:36 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added "^" character to JavaFX virtual keyboard.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added character to EmailBoard.txt and UrlBoard.txt

Thank you for reviewing.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3837864123

From zelmidaoui at openjdk.org  Mon Feb  2 23:50:09 2026
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 2 Feb 2026 23:50:09 GMT
Subject: Integrated: 8274928: JavaFX virtual keyboard missing ^ character
In-Reply-To: <dMB1OyyvFWHLqYwvZEf1i_3snu7lZ4hKy-q1Zf_lM_U=.a60b9d43-efc9-432d-ad50-64d24b389cd9@github.com>
References: <dMB1OyyvFWHLqYwvZEf1i_3snu7lZ4hKy-q1Zf_lM_U=.a60b9d43-efc9-432d-ad50-64d24b389cd9@github.com>
Message-ID: <RUx5Nrcuj-gj8BRtvmKxgxvZAKxE2RokX-_G1NiOPzA=.2ae76318-4d66-417e-ac04-c7d815e75473@github.com>

On Mon, 26 Jan 2026 21:38:50 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added "^" character to JavaFX virtual keyboard.

This pull request has now been integrated.

Changeset: 913f588a
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/913f588ae7b9e7c64142b6a059a1076a850fabf0
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8274928: JavaFX virtual keyboard missing ^ character

Reviewed-by: angorya

-------------

PR: https://git.openjdk.org/jfx/pull/2053

From kcr at openjdk.org  Tue Feb  3 15:25:29 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 3 Feb 2026 15:25:29 GMT
Subject: RFR: 8375466: Metal rendering pipeline crashes on virtualized OS
In-Reply-To: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
References: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
Message-ID: <IqpYsXEmQXSL72tHFqetEXhr626NZVxn_wkpn2-o4fY=.e66f7727-775c-4e19-8caa-07b3807e1683@github.com>

On Mon, 2 Feb 2026 13:30:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> As described in the bug, a crash occurs on macOS VM created using Parallels.
> The crash occurs when trying to create a [MTLArgumentEncoder](https://github.com/openjdk/jfx/blob/5ac1620ac0ba20170ae9758e20893feba5ebc58b/modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m#L76C49-L76C82), which is required for creating Shaders(Both Prism and Decora)
> This crash is not observed on macOS VM created using Apple Virtualization Framework.
> 
> Fix:
> Support for MTLArgumentEncoder is mandatory for Prism Metal Rendering pipeline. Without support for MTLArgumentEncoder the Shaders cannot be created.
> In this scenario Prism should gracefully fallback to Software rendering.
> Added a check to verify if the minimum [MTLGPUFamilyMac2](https://developer.apple.com/documentation/metal/mtlgpufamily/mac2?language=objc) GPU family is supported by the platform. If not supported then Metal Pipeline cannot be used, and rendering falls back to software pipeline.

LGTM

One thing of note is that with the newly-updated default pipeline order of `"mtl,es2,sw"` on macOS, if we fallback to sw (e.g., on a Parallels setup that doesn't support mtl or es2), the sw pipeline will use Metal to blit. I think that should be OK as long as it works (I note we have the same potential issue with OpenGL today, so this is not a new issue).

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/2061#pullrequestreview-3745918871

From snazarki at openjdk.org  Tue Feb  3 15:49:07 2026
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 3 Feb 2026 15:49:07 GMT
Subject: RFR: 8375466: Metal rendering pipeline crashes on virtualized OS
In-Reply-To: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
References: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
Message-ID: <HHr-4u5MMCFtbPO6UliOkq9LwOssjdPJzp_22bUr6bw=.02569a48-e963-4fc4-b3b4-0d8ac5295c40@github.com>

On Mon, 2 Feb 2026 13:30:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> As described in the bug, a crash occurs on macOS VM created using Parallels.
> The crash occurs when trying to create a [MTLArgumentEncoder](https://github.com/openjdk/jfx/blob/5ac1620ac0ba20170ae9758e20893feba5ebc58b/modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m#L76C49-L76C82), which is required for creating Shaders(Both Prism and Decora)
> This crash is not observed on macOS VM created using Apple Virtualization Framework.
> 
> Fix:
> Support for MTLArgumentEncoder is mandatory for Prism Metal Rendering pipeline. Without support for MTLArgumentEncoder the Shaders cannot be created.
> In this scenario Prism should gracefully fallback to Software rendering.
> Added a check to verify if the minimum [MTLGPUFamilyMac2](https://developer.apple.com/documentation/metal/mtlgpufamily/mac2?language=objc) GPU family is supported by the platform. If not supported then Metal Pipeline cannot be used, and rendering falls back to software pipeline.

Tested with Parallels on x86 host: the issue is no longer reproducible.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2061#issuecomment-3842105113

From kcr at openjdk.org  Tue Feb  3 16:21:17 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 3 Feb 2026 16:21:17 GMT
Subject: RFR: 8375466: Metal rendering pipeline crashes on virtualized OS
In-Reply-To: <HHr-4u5MMCFtbPO6UliOkq9LwOssjdPJzp_22bUr6bw=.02569a48-e963-4fc4-b3b4-0d8ac5295c40@github.com>
References: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
 <HHr-4u5MMCFtbPO6UliOkq9LwOssjdPJzp_22bUr6bw=.02569a48-e963-4fc4-b3b4-0d8ac5295c40@github.com>
Message-ID: <uU397TcylJ_UzXKRxnIfIFdsN-BJ1_2LgyH7f4Ox9A0=.142a0286-6d6b-4811-aeef-0dadd5b4dd13@github.com>

On Tue, 3 Feb 2026 15:46:55 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Tested with Parallels on x86 host: the issue is no longer reproducible.

Thanks for reporting this bug and for verifying the fix.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2061#issuecomment-3842283766

From jdv at openjdk.org  Wed Feb  4 03:34:18 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 4 Feb 2026 03:34:18 GMT
Subject: RFR: 8375466: Metal rendering pipeline crashes on virtualized OS
In-Reply-To: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
References: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
Message-ID: <JwzXaFzkmdb0293hh9sicPvgUu2sXFeX9V4BW1Qsftk=.9311adc3-36a1-4fc1-b9d0-0241be155bfc@github.com>

On Mon, 2 Feb 2026 13:30:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> As described in the bug, a crash occurs on macOS VM created using Parallels.
> The crash occurs when trying to create a [MTLArgumentEncoder](https://github.com/openjdk/jfx/blob/5ac1620ac0ba20170ae9758e20893feba5ebc58b/modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m#L76C49-L76C82), which is required for creating Shaders(Both Prism and Decora)
> This crash is not observed on macOS VM created using Apple Virtualization Framework.
> 
> Fix:
> Support for MTLArgumentEncoder is mandatory for Prism Metal Rendering pipeline. Without support for MTLArgumentEncoder the Shaders cannot be created.
> In this scenario Prism should gracefully fallback to Software rendering.
> Added a check to verify if the minimum [MTLGPUFamilyMac2](https://developer.apple.com/documentation/metal/mtlgpufamily/mac2?language=objc) GPU family is supported by the platform. If not supported then Metal Pipeline cannot be used, and rendering falls back to software pipeline.

LGTM.

modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 1569:

> 1567:     (JNIEnv *env, jclass jClass)
> 1568: {
> 1569:     id<MTLDevice> device = MTLCreateSystemDefaultDevice();

MTLCreateSystemDefaultDevice is expensive.
In case where we return true, if there is a way to re-use `device` as part of MTLContext it should be explored in a follow-up task.

-------------

Marked as reviewed by jdv (Committer).

PR Review: https://git.openjdk.org/jfx/pull/2061#pullrequestreview-3748750586
PR Review Comment: https://git.openjdk.org/jfx/pull/2061#discussion_r2762001174

From arapte at openjdk.org  Wed Feb  4 05:03:54 2026
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 4 Feb 2026 05:03:54 GMT
Subject: Integrated: 8375466: Metal rendering pipeline crashes on virtualized
 OS
In-Reply-To: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
References: <uiE7_fv3zVR11nfA-IuOZkg9tzhG8rahmVUi9_wEZ2c=.cc786447-092b-41f3-b9ec-79aeb4afea00@github.com>
Message-ID: <0dosTiw_99MFa5doIbfYDrSY4PQx3FECLKa17OL8kMU=.abc3fbf3-c72b-4c65-b13d-d7d8cfb8e8ed@github.com>

On Mon, 2 Feb 2026 13:30:40 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue:
> As described in the bug, a crash occurs on macOS VM created using Parallels.
> The crash occurs when trying to create a [MTLArgumentEncoder](https://github.com/openjdk/jfx/blob/5ac1620ac0ba20170ae9758e20893feba5ebc58b/modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m#L76C49-L76C82), which is required for creating Shaders(Both Prism and Decora)
> This crash is not observed on macOS VM created using Apple Virtualization Framework.
> 
> Fix:
> Support for MTLArgumentEncoder is mandatory for Prism Metal Rendering pipeline. Without support for MTLArgumentEncoder the Shaders cannot be created.
> In this scenario Prism should gracefully fallback to Software rendering.
> Added a check to verify if the minimum [MTLGPUFamilyMac2](https://developer.apple.com/documentation/metal/mtlgpufamily/mac2?language=objc) GPU family is supported by the platform. If not supported then Metal Pipeline cannot be used, and rendering falls back to software pipeline.

This pull request has now been integrated.

Changeset: 3ae6bc00
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3ae6bc00b803517941d3459641b0c66b749beecf
Stats:     25 lines in 2 files changed: 25 ins; 0 del; 0 mod

8375466: Metal rendering pipeline crashes on virtualized OS

Reviewed-by: kcr, jdv

-------------

PR: https://git.openjdk.org/jfx/pull/2061

From daniel.peintner at gmail.com  Wed Feb  4 07:44:03 2026
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Wed, 4 Feb 2026 08:44:03 +0100
Subject: SortedList, identical elements + re-arranging
In-Reply-To: <5bc1acb9-cdde-456c-8d09-d502cd41d155@gmail.com>
References: <CAGBnJPu-hfRcr4h5_Uzb95Cix+dsMoj3mC4c7A6wdMTbtrbreg@mail.gmail.com>
 <CAAoP7T4WeBEx0_JG74k_31tTNR32+_xfaym-OVXvXbjprrC5wg@mail.gmail.com>
 <5bc1acb9-cdde-456c-8d09-d502cd41d155@gmail.com>
Message-ID: <CAAoP7T6DhEN8pDxhTDguw53j_ApppbVYwDec1_MuNXxdp7X_RQ@mail.gmail.com>

Hi John,

Thank you very much for your feedback.

> The solution IMHO is to make this simply crystal clear in your
> Comparator.  If equal items should be ordered in insertion order, then the
> index should be part of the comparator.  Any decision that SortedList makes
> could be correct for some use cases, and incorrect for others.
>

You might be right that one could (should?) of course take into account the
original order of the underlying list in the comparator to be sure.

On the other hand, the sort method of Collections [1] states

>  This sort is guaranteed to be stable: equal elements will not be
reordered as a result of the sort.

I am not saying it is a *real* conflict, but my assumption/expectation was
that the order of a SortedList behaves somewhat the same.

Thanks,

-- Daniel

[1]
https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Collections.html#sort(java.util.List)



> --John
>
> On 29/01/2026 11:09, Daniel Peintner wrote:
>
> Hi,
>
> I had and still have the same problem in a similar situation.
>
> The situation is as follows. A table contains a list of entries. A user
> selects an entry and performs a copy and paste operation (in order to
> modify the entry later).
> In this situation, the copied entry is identical by nature (Comparator
> returns 0).
>
> Even if I insert the *new* entry into the underlying list after the
> existing entry, SortedList decides to display the entry *before* the
> existing entry.
>
> This is confusing for a user.
>
> If there is a good solution for this, it would be helpful.
> However, I agree with Cormac Redmond that, ideally, the order should not
> change if the Comparator returns 0 (zero).
>
> Thanks,
>
> -- Daniel
>
>
>
> On Wed, Jan 28, 2026 at 4:51?AM Cormac Redmond <credmond at certak.com>
> wrote:
>
>> Hi,
>>
>> I have noticed a troublesome quirk with SortedList which causes
>> unexpected re-positioning of elements in its list.
>>
>> This is a noticeable problem when you are, for example, sorting a
>> TableView on a column and re-insert an identical element at the same index
>> in the source list (i.e., nothings changing). E.g., if your goal is to
>> refresh a single row, even when there's no difference in the underlying
>> object, SortedList can still shift its place in its arrays and hence the
>> row shifts visibly in the table. On large tables, this can be a huge jump,
>> outside of view. This occurs when the sort column value shares the same
>> value with other rows (i.e., in my code sample below, multiple people are
>> aged 62 and sorting is by age).
>>
>> Sample below code and output below. The bit in green represents what I
>> would expect on each subsequent printout, but the bit in red shows the
>> random re-arrangement of elements.
>>
>> There's no need to include a full TableView example to show this. But
>> I've included a small gif too, for example.
>>
>> ---- Source Initial ----
>> Person item [0]: Person[name=Bob, age=60, id=0]
>> Person item [1]: Person[name=Alice, age=70, id=1]
>> Person item [2]: Person[name=Diana, age=30, id=2]
>> Person item [3]: Person[name=Frank1, age=62, id=3]
>> Person item [4]: Person[name=Eve, age=62, id=4]
>> Person item [5]: Person[name=Frank2, age=62, id=5]
>> Person item [6]: Person[name=Jim, age=62, id=6]
>> Person item [7]: Person[name=Ivy, age=62, id=7]
>> Person item [8]: Person[name=Jack, age=53, id=8]
>>
>> ---- Sorted Initial (Subsequent Prints Should Match This, But Don't) ----
>> Person item [0]: Person[name=Diana, age=30, id=2]
>> Person item [1]: Person[name=Jack, age=53, id=8]
>> Person item [2]: Person[name=Bob, age=60, id=0]
>> Person item [3]: Person[name=Frank1, age=62, id=3]
>> Person item [4]: Person[name=Eve, age=62, id=4]
>> Person item [5]: Person[name=Frank2, age=62, id=5]
>> Person item [6]: Person[name=Jim, age=62, id=6]
>> Person item [7]: Person[name=Ivy, age=62, id=7]
>> Person item [8]: Person[name=Alice, age=70, id=1]
>>
>> ---- Sorted After Identical Replace Index 5 ----
>> Person item [0]: Person[name=Diana, age=30, id=2]
>> Person item [1]: Person[name=Jack, age=53, id=8]
>> Person item [2]: Person[name=Bob, age=60, id=0]
>> Person item [3]: Person[name=Frank2, age=62, id=5]
>> Person item [4]: Person[name=Frank1, age=62, id=3]
>> Person item [5]: Person[name=Eve, age=62, id=4]
>> Person item [6]: Person[name=Jim, age=62, id=6]
>> Person item [7]: Person[name=Ivy, age=62, id=7]
>> Person item [8]: Person[name=Alice, age=70, id=1]
>>
>> ---- Sorted After Identical Replace Index 4 ----
>> Person item [0]: Person[name=Diana, age=30, id=2]
>> Person item [1]: Person[name=Jack, age=53, id=8]
>> Person item [2]: Person[name=Bob, age=60, id=0]
>> Person item [3]: Person[name=Eve, age=62, id=4]
>> Person item [4]: Person[name=Frank2, age=62, id=5]
>> Person item [5]: Person[name=Frank1, age=62, id=3]
>> Person item [6]: Person[name=Jim, age=62, id=6]
>> Person item [7]: Person[name=Ivy, age=62, id=7]
>> Person item [8]: Person[name=Alice, age=70, id=1]
>>
>> ---- Sorted After Identical Replace Index 3 ----
>> Person item [0]: Person[name=Diana, age=30, id=2]
>> Person item [1]: Person[name=Jack, age=53, id=8]
>> Person item [2]: Person[name=Bob, age=60, id=0]
>> Person item [3]: Person[name=Frank1, age=62, id=3]
>> Person item [4]: Person[name=Eve, age=62, id=4]
>> Person item [5]: Person[name=Frank2, age=62, id=5]
>> Person item [6]: Person[name=Jim, age=62, id=6]
>> Person item [7]: Person[name=Ivy, age=62, id=7]
>> Person item [8]: Person[name=Alice, age=70, id=1]
>>
>> ...etc.
>>
>>
>> Code:
>> public class SortedListBehaviour {
>>
>>     public static void main(String[] args) {
>>
>>         ObservableList<Person> personList =
>> FXCollections.observableArrayList();
>>
>>         personList.addAll(
>>             new Person("Bob", 60, 0),
>>             new Person("Alice", 70, 1),
>>             new Person("Diana", 30, 2),
>>             new Person("Frank1", 62, 3),
>>             new Person("Eve", 62, 4),
>>             new Person("Frank2", 62, 5),
>>             new Person("Jim", 62, 6),
>>             new Person("Ivy", 62, 7),
>>             new Person("Jack", 53, 8)
>>         );
>>
>>         SortedList<Person> sortedList = new SortedList<>(personList,
>> Comparator.comparing(Person::age));
>>
>>         // Starting out
>>         printList(personList, "Source Initial");
>>
>>         // This is sorted by age, all subsequent prints should look like
>> this, but they don't
>>         printList(sortedList, "Sorted Initial (Subsequent Prints Should
>> Match This, But Don't)");
>>
>>         personList.set(5, new Person("Frank2", 62, 5)); // Replace with
>> identical, at same index
>>         printList(sortedList, "Sorted After Identical Replace Index 5");
>>
>>         personList.set(4, new Person("Eve", 62, 4));  // Replace with
>> identical, at same index
>>         printList(sortedList, "Sorted After Identical Replace Index 4");
>>
>>         personList.set(3, new Person("Frank1", 62, 3));  // Replace with
>> identical, at same index
>>         printList(sortedList, "Sorted After Identical Replace Index 3");
>>     }
>>
>>     private static void printList(final List<Person> list, final String
>> source) {
>>         System.out.println("\n---- " + source + " ----");
>>         for (int i = 0; i < list.size(); i++) {
>>             final Person next = list.get(i);
>>             System.out.println("Person item [" + i + "]: " + next);
>>         }
>>     }
>>
>>     public record Person(String name, int age, int id) {
>>         @Override
>>         public boolean equals(final Object o) {
>>             if (o == null || getClass() != o.getClass()) {
>>                 return false;
>>             }
>>             final Person person = (Person) o;
>>             return id == person.id && age == person.age &&
>> Objects.equals(name, person.name);
>>         }
>>
>>         @Override
>>         public int hashCode() {
>>             return Objects.hash(name, age, id);
>>         }
>>     }
>> }
>>
>>
>> UI example also; the "Refresh" item here replaces the object with an
>> identical object and the same index, yet it will often jump around the
>> table as you can see, and selection can change too.
>>
>> [image: sl.gif]
>>
>> I understand that strictly speaking the list is still sorted correctly
>> (by age), but SortedList could make some effort to reduce re-arranging
>> already-present elements.
>>
>>
>>
>> Regards,
>>
>> *Cormac Redmond*
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260204/d3fe7d5d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sl.gif
Type: image/gif
Size: 58742 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260204/d3fe7d5d/sl-0001.gif>

From john.hendrikx at gmail.com  Wed Feb  4 08:43:03 2026
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 4 Feb 2026 09:43:03 +0100
Subject: SortedList, identical elements + re-arranging
In-Reply-To: <CAAoP7T6DhEN8pDxhTDguw53j_ApppbVYwDec1_MuNXxdp7X_RQ@mail.gmail.com>
References: <CAGBnJPu-hfRcr4h5_Uzb95Cix+dsMoj3mC4c7A6wdMTbtrbreg@mail.gmail.com>
 <CAAoP7T4WeBEx0_JG74k_31tTNR32+_xfaym-OVXvXbjprrC5wg@mail.gmail.com>
 <5bc1acb9-cdde-456c-8d09-d502cd41d155@gmail.com>
 <CAAoP7T6DhEN8pDxhTDguw53j_ApppbVYwDec1_MuNXxdp7X_RQ@mail.gmail.com>
Message-ID: <d7b3e8fd-e8c5-49d3-8389-6e3b2a10e281@gmail.com>

Hi Daniel,

On 04/02/2026 08:44, Daniel Peintner wrote:
> Hi John,
>
> Thank you very much for your feedback.
>
>     The solution IMHO is to make this simply crystal clear in your
>     Comparator.? If equal items should be ordered in insertion order,
>     then the index should be part of the comparator.? Any decision
>     that SortedList makes could be correct for some use cases, and
>     incorrect for others.
>
>
> You might be right that one could (should?) of course take into
> account the original order of the underlying list in the comparator to
> be sure.
>
> On the other hand, the sort method of Collections [1] states
>
> > ?This sort is guaranteed to be stable: equal elements will not be
> reordered as a result of the sort.

This statement is about the sort algorithm used.? It means that if you
have two equal elements (already present at the time of sorting) that
the algorithm won't decide to swap them around.??Some algorithms may
reorder equal elements unintentionally due to the way they are
implemented.? This re-arranging for such algorithms could occur on each
call to `sort`, even if nothing else changed.? Stable sort algorithms
take extra care to ensure unnecessary re-arranging of equal
elements?doesn't happen. For example, given 5 equal elements:

????? A1, A2, A3, A4, A5

A stable sort when re-applied will never re-arrange these, however, an
unstable sort may re-arrange these in some random order each time the
list is sorted, for example?to:

????? A2, A4, A1, A5, A3

The stability statement however provides no guarantees when you add a
new element (even if it was the same as one that was just removed, or
duplicated).? In that case the new element gets a random spot among its
peers.? Only in subsequent sorts does the algorithm guarantee that it
doesn't move relative to other equal elements; so if I add A6, it may
end up anywhere (the rest of the elements however remain in the same
relative order):

???? A1, A2, A6, A3, A4, A5

Only after a resort does it ensure again that the sort is stable, and it
will remain in the same order:

???? A1, A2, A6, A3, A4, A5

If I remove any of the elements, a stable sort will also ensure that the
remaining equal elements stay in the same order, so if I remove A4, it
will become:

???? A1, A2, A6, A3,?A5

I hope that clarifies it a bit.

>
> I am not saying it is a *real* conflict, but my assumption/expectation
> was that the order of a SortedList behaves somewhat the same.

Unfortunately, it can't guarantee this, and the stability guarantee
doesn't apply in your case.? So if you really want the new / duplicate
item to appear in a specific location relative to other equal elements,
you must add another sort key to the comparator to remove any ambiguity.

--John

>
> Thanks,
>
> -- Daniel
>
> [1]?https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Collections.html#sort(java.util.List)
>
> ?
>
>     --John
>
>     On 29/01/2026 11:09, Daniel Peintner wrote:
>>     Hi,
>>
>>     I had and still have the same problem in a similar situation.
>>
>>     The situation is as follows. A table contains a list of entries.
>>     A user selects an entry and performs a copy and paste operation
>>     (in order to modify the entry later).
>>     In this situation, the copied entry is identical by nature
>>     (Comparator returns 0).
>>
>>     Even if I insert the *new* entry into the underlying list after
>>     the existing entry, SortedList decides to display the entry
>>     *before* the existing entry.
>>
>>     This is confusing for a user.
>>
>>     If there is a good solution for this, it would be helpful.
>>     However, I agree with Cormac Redmond that, ideally, the order
>>     should not change if the Comparator returns 0 (zero).
>>
>>     Thanks,
>>
>>     -- Daniel
>>
>>
>>
>>     On Wed, Jan 28, 2026 at 4:51?AM Cormac Redmond
>>     <credmond at certak.com> wrote:
>>
>>         Hi,
>>
>>         I have noticed a troublesome quirk with SortedList which
>>         causes unexpected re-positioning?of elements in its list.
>>
>>         This is a noticeable?problem when you are, for example,
>>         sorting a TableView on a column and re-insert an identical
>>         element at the same index in the source list (i.e., nothings
>>         changing). E.g., if your goal is to refresh a single row,
>>         even when there's no difference in the underlying object,
>>         SortedList can still shift its place in its arrays and hence
>>         the row shifts visibly in the table. On large tables, this
>>         can be a huge jump, outside of view. This occurs when the
>>         sort column value shares the same value with other?rows
>>         (i.e., in my code sample below, multiple people are aged 62
>>         and sorting is by age).
>>
>>         Sample below code and output below. The bit in green
>>         represents what I would expect on each subsequent printout,
>>         but the bit in red shows the random re-arrangement of elements.
>>
>>         There's no need to include a full TableView example to show
>>         this. But I've included a small gif too, for example.
>>
>>         ---- Source Initial ----
>>         Person item [0]: Person[name=Bob, age=60, id=0]
>>         Person item [1]: Person[name=Alice, age=70, id=1]
>>         Person item [2]: Person[name=Diana, age=30, id=2]
>>         Person item [3]: Person[name=Frank1, age=62, id=3]
>>         Person item [4]: Person[name=Eve, age=62, id=4]
>>         Person item [5]: Person[name=Frank2, age=62, id=5]
>>         Person item [6]: Person[name=Jim, age=62, id=6]
>>         Person item [7]: Person[name=Ivy, age=62, id=7]
>>         Person item [8]: Person[name=Jack, age=53, id=8]
>>
>>         ---- Sorted Initial (Subsequent Prints Should Match This, But
>>         Don't) ----
>>         Person item [0]: Person[name=Diana, age=30, id=2]
>>         Person item [1]: Person[name=Jack, age=53, id=8]
>>         Person item [2]: Person[name=Bob, age=60, id=0]
>>         Person item [3]: Person[name=Frank1, age=62, id=3]
>>         Person item [4]: Person[name=Eve, age=62, id=4]
>>         Person item [5]: Person[name=Frank2, age=62, id=5]
>>         Person item [6]: Person[name=Jim, age=62, id=6]
>>         Person item [7]: Person[name=Ivy, age=62, id=7]
>>         Person item [8]: Person[name=Alice, age=70, id=1]
>>
>>         ---- Sorted After Identical Replace Index 5 ----
>>         Person item [0]: Person[name=Diana, age=30, id=2]
>>         Person item [1]: Person[name=Jack, age=53, id=8]
>>         Person item [2]: Person[name=Bob, age=60, id=0]
>>         Person item [3]: Person[name=Frank2, age=62, id=5]
>>         Person item [4]: Person[name=Frank1, age=62, id=3]
>>         Person item [5]: Person[name=Eve, age=62, id=4]
>>         Person item [6]: Person[name=Jim, age=62, id=6]
>>         Person item [7]: Person[name=Ivy, age=62, id=7]
>>         Person item [8]: Person[name=Alice, age=70, id=1]
>>
>>         ---- Sorted After Identical Replace Index 4 ----
>>         Person item [0]: Person[name=Diana, age=30, id=2]
>>         Person item [1]: Person[name=Jack, age=53, id=8]
>>         Person item [2]: Person[name=Bob, age=60, id=0]
>>         Person item [3]: Person[name=Eve, age=62, id=4]
>>         Person item [4]: Person[name=Frank2, age=62, id=5]
>>         Person item [5]: Person[name=Frank1, age=62, id=3]
>>         Person item [6]: Person[name=Jim, age=62, id=6]
>>         Person item [7]: Person[name=Ivy, age=62, id=7]
>>         Person item [8]: Person[name=Alice, age=70, id=1]
>>
>>         ---- Sorted After Identical Replace Index 3 ----
>>         Person item [0]: Person[name=Diana, age=30, id=2]
>>         Person item [1]: Person[name=Jack, age=53, id=8]
>>         Person item [2]: Person[name=Bob, age=60, id=0]
>>         Person item [3]: Person[name=Frank1, age=62, id=3]
>>         Person item [4]: Person[name=Eve, age=62, id=4]
>>         Person item [5]: Person[name=Frank2, age=62, id=5]
>>         Person item [6]: Person[name=Jim, age=62, id=6]
>>         Person item [7]: Person[name=Ivy, age=62, id=7]
>>         Person item [8]: Person[name=Alice, age=70, id=1]
>>
>>         ...etc.
>>
>>
>>         Code:
>>         public class SortedListBehaviour {
>>
>>         ? ? public static void main(String[] args) {
>>
>>         ? ? ? ? ObservableList<Person> personList =
>>         FXCollections.observableArrayList();
>>
>>         ? ? ? ? personList.addAll(
>>         ? ? ? ? ? ? new Person("Bob", 60, 0),
>>         ? ? ? ? ? ? new Person("Alice", 70, 1),
>>         ? ? ? ? ? ? new Person("Diana", 30, 2),
>>         ? ? ? ? ? ? new Person("Frank1", 62, 3),
>>         ? ? ? ? ? ? new Person("Eve", 62, 4),
>>         ? ? ? ? ? ? new Person("Frank2", 62, 5),
>>         ? ? ? ? ? ? new Person("Jim", 62, 6),
>>         ? ? ? ? ? ? new Person("Ivy", 62, 7),
>>         ? ? ? ? ? ? new Person("Jack", 53, 8)
>>         ? ? ? ? );
>>
>>         ? ? ? ? SortedList<Person> sortedList = new
>>         SortedList<>(personList, Comparator.comparing(Person::age));
>>
>>         ? ? ? ? // Starting out
>>         ? ? ? ? printList(personList, "Source Initial");
>>
>>         ? ? ? ? // This is sorted by age, all subsequent prints
>>         should look like this, but they don't
>>         ? ? ? ? printList(sortedList, "Sorted Initial (Subsequent
>>         Prints Should Match This, But Don't)");
>>
>>         ? ? ? ? personList.set(5, new Person("Frank2", 62, 5)); //
>>         Replace with identical, at same index
>>         ? ? ? ? printList(sortedList, "Sorted After Identical Replace
>>         Index 5");
>>
>>         ? ? ? ? personList.set(4, new Person("Eve", 62, 4)); ?//
>>         Replace with identical, at same index
>>         ? ? ? ? printList(sortedList, "Sorted After Identical Replace
>>         Index 4");
>>
>>         ? ? ? ? personList.set(3, new Person("Frank1", 62, 3)); ?//
>>         Replace with identical, at same index
>>         ? ? ? ? printList(sortedList, "Sorted After Identical Replace
>>         Index 3");
>>         ? ? }
>>
>>         ? ? private static void printList(final List<Person> list,
>>         final String source) {
>>         ? ? ? ? System.out.println("\n---- " + source + " ----");
>>         ? ? ? ? for (int i = 0; i < list.size(); i++) {
>>         ? ? ? ? ? ? final Person next = list.get(i);
>>         ? ? ? ? ? ? System.out.println("Person item [" + i + "]: " +
>>         next);
>>         ? ? ? ? }
>>         ? ? }
>>
>>         ? ? public record Person(String name, int age, int id) {
>>         ? ? ? ? @Override
>>         ? ? ? ? public boolean equals(final Object o) {
>>         ? ? ? ? ? ? if (o == null || getClass() != o.getClass()) {
>>         ? ? ? ? ? ? ? ? return false;
>>         ? ? ? ? ? ? }
>>         ? ? ? ? ? ? final Person person = (Person) o;
>>         ? ? ? ? ? ? return id == person.id <http://person.id> && age
>>         == person.age && Objects.equals(name, person.name
>>         <http://person.name>);
>>         ? ? ? ? }
>>
>>         ? ? ? ? @Override
>>         ? ? ? ? public int hashCode() {
>>         ? ? ? ? ? ? return Objects.hash(name, age, id);
>>         ? ? ? ? }
>>         ? ? }
>>         }
>>
>>
>>         UI example also; the "Refresh" item here replaces the object
>>         with an identical object and the same index, yet it will
>>         often jump around the table as you can see, and selection can
>>         change too.
>>
>>         sl.gif
>>
>>         I understand that strictly speaking the list is still sorted
>>         correctly (by age), but SortedList could make some effort to
>>         reduce re-arranging already-present elements.
>>
>>
>>
>>         Regards,
>>         *
>>         *
>>         *Cormac Redmond*
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260204/f53304f1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sl.gif
Type: image/gif
Size: 58742 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260204/f53304f1/sl-0001.gif>

From arapte at openjdk.org  Wed Feb  4 09:08:59 2026
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 4 Feb 2026 09:08:59 GMT
Subject: [jfx26] RFR: 8375466: Metal rendering pipeline crashes on virtualized
 OS
Message-ID: <hjVQy_fO5eHjAiVTUCNPgP2jxgXY7hGdZ4vwBL4t9js=.72f31739-0cb0-4d14-a367-ef0e544c1f39@github.com>

A clean backport. The fix is necessary for avoiding a Metal crash on macOS VM.

-------------

Commit messages:
 - Backport 3ae6bc00b803517941d3459641b0c66b749beecf

Changes: https://git.openjdk.org/jfx/pull/2062/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375466
  Stats: 25 lines in 2 files changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/2062.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2062/head:pull/2062

PR: https://git.openjdk.org/jfx/pull/2062

From kcr at openjdk.org  Wed Feb  4 13:46:59 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Feb 2026 13:46:59 GMT
Subject: [jfx26] RFR: 8375466: Metal rendering pipeline crashes on
 virtualized OS
In-Reply-To: <hjVQy_fO5eHjAiVTUCNPgP2jxgXY7hGdZ4vwBL4t9js=.72f31739-0cb0-4d14-a367-ef0e544c1f39@github.com>
References: <hjVQy_fO5eHjAiVTUCNPgP2jxgXY7hGdZ4vwBL4t9js=.72f31739-0cb0-4d14-a367-ef0e544c1f39@github.com>
Message-ID: <R3G2Gjv0Y1zzrNFMMsaWfjFyv7lUY9hn49kmcS9rMSE=.cb18a606-ca9a-435c-a6a9-d7e6e80693fd@github.com>

On Wed, 4 Feb 2026 09:01:07 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> A clean backport. The fix is necessary for avoiding a Metal crash on macOS VM.

LGTM for jfx26 backport

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/2062#pullrequestreview-3751152651

From arapte at openjdk.org  Wed Feb  4 15:05:55 2026
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 4 Feb 2026 15:05:55 GMT
Subject: [jfx26] Integrated: 8375466: Metal rendering pipeline crashes on
 virtualized OS
In-Reply-To: <hjVQy_fO5eHjAiVTUCNPgP2jxgXY7hGdZ4vwBL4t9js=.72f31739-0cb0-4d14-a367-ef0e544c1f39@github.com>
References: <hjVQy_fO5eHjAiVTUCNPgP2jxgXY7hGdZ4vwBL4t9js=.72f31739-0cb0-4d14-a367-ef0e544c1f39@github.com>
Message-ID: <Ps12Vcx9RD-AFGB-EXyS2rdaO1HQaPTlJIQmOtqoHjI=.c0d9950a-fac5-4451-8688-3ab4c0b999a6@github.com>

On Wed, 4 Feb 2026 09:01:07 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> A clean backport. The fix is necessary for avoiding a Metal crash on macOS VM.

This pull request has now been integrated.

Changeset: cb6b8585
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/cb6b85859e5ba3546af1d8d188f6813617fff113
Stats:     25 lines in 2 files changed: 25 ins; 0 del; 0 mod

8375466: Metal rendering pipeline crashes on virtualized OS

Reviewed-by: kcr
Backport-of: 3ae6bc00b803517941d3459641b0c66b749beecf

-------------

PR: https://git.openjdk.org/jfx/pull/2062

From hmeda at openjdk.org  Wed Feb  4 16:32:48 2026
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 4 Feb 2026 16:32:48 GMT
Subject: RFR: 8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4
Message-ID: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>

This PR updates webkit to v2.50.4. Verified build and sanity on mac, windows and linux platforms. No issue seen.

-------------

Commit messages:
 - additional fixes from webkit-2.50.4

Changes: https://git.openjdk.org/jfx/pull/2063/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377099
  Stats: 692 lines in 75 files changed: 467 ins; 72 del; 153 mod
  Patch: https://git.openjdk.org/jfx/pull/2063.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2063/head:pull/2063

PR: https://git.openjdk.org/jfx/pull/2063

From andy.goryachev at oracle.com  Wed Feb  4 21:17:04 2026
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 4 Feb 2026 21:17:04 +0000
Subject: Experiment: Node properties
Message-ID: <CY8PR10MB72651B8D00F2F0D9A7A35AB5E598A@CY8PR10MB7265.namprd10.prod.outlook.com>

I would like to share the results of a little experiment involving optimization of storage of Node properties.  The basic idea is to create a compact fast map-like container to hold the rarely instantiated properties in order to reduce the application memory footprint.

The savings are not overwhelming, but not exactly zero.  I would imagine this optimization might be more interesting in any resource constrained environment such as Android / iOS / RaspberryPi.  Please refer to [0] for the details.

I encourage you to try it with your application, to see whether you notice any change in memory consumption and/or performance.  Let me know what you think!

Cheers,
-andy


References

[0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260204/b97243f9/attachment.htm>

From kcr at openjdk.org  Wed Feb  4 23:24:24 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Feb 2026 23:24:24 GMT
Subject: RFR: 8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4
In-Reply-To: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
References: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
Message-ID: <xlz2rT2sPdfkH210cgVPkQEES-wWUUBISFeeluOe7wM=.b872f529-2496-4852-8029-bfab4fb79ec1@github.com>

On Wed, 4 Feb 2026 16:15:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates webkit to v2.50.4. Verified build and sanity on mac, windows and linux platforms. No issue seen.

Reviewers: @kevinrushforth @tiainen

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2063#issuecomment-3850235863

From jhendrikx at openjdk.org  Thu Feb  5 09:50:18 2026
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 5 Feb 2026 09:50:18 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v8]
In-Reply-To: <gnrULmFBlbY7-pu5FwKLDaH98ZDm8wGsSxj3xq6TyHA=.5ddc559e-9e67-428d-b9ed-89960d0d16c2@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <gnrULmFBlbY7-pu5FwKLDaH98ZDm8wGsSxj3xq6TyHA=.5ddc559e-9e67-428d-b9ed-89960d0d16c2@github.com>
Message-ID: <OSj-ep3Qyn4_LiaBBqLpGClb2MOHL0famK4-wfkGbOM=.872aae72-61bd-4bac-9fff-b34b999cb3ff@github.com>

On Wed, 7 Jan 2026 21:34:45 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> When a Window is created with a certain X/Y coordinate to place it on a specific screen, and is subsequently shown for the first time, one of the first things it does is size the window according to the size of the Scene.  It does this based on the render scale of the *primary* screen as it has not moved the peer yet to the correct screen.  After the scene has been sized, it is moved to the correct screen, triggering a change of render scale, but not a resizing of the Window (as this is only done once).
>> 
>> The result of this is that due to slight difference in render scale, the size calculated for the scene may be a few pixels off.  As the scene's preferred size is used for this calculation, even a few pixels too small can result in Labels being shown with ellipsis on the intended target screen with a different render scale.
>> 
>> When observing the render scale X or Y property, one can observe a change from 1.0 (the default value) to 2.0 (the primary screen's render scale) to another value (depending on the target screen).  However, the Window involved (being positioned by the user using setX()/setY() before it is shown) was never shown on the primary screen, yet the size calculation assumed it was.
>> 
>> To solve this problem, the peer should be moved to the correct screen **before** asking the Scene for its preferred size to use as the initial Window size.  Doing so (by adding an additional `applyBounds` call) also results in the render scale properties to only change once (or not at all) from their default value to the target screen's value (or not at all if the target screen is 1.0 scale).
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove empty lines
>  - Remove debug prints

I don't think this will cause any problems on Linux, but does a fix an issue on Mac.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2007#issuecomment-3852358563

From kcr at openjdk.org  Thu Feb  5 13:45:10 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Feb 2026 13:45:10 GMT
Subject: RFR: 8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4
In-Reply-To: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
References: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
Message-ID: <D0RpvmQk7HYn9uCD4_6BbYb3e3_OjUeUVDVwkmDGRXY=.b96fe2c1-4f76-4a9f-9e7a-51ab5021518e@github.com>

On Wed, 4 Feb 2026 16:15:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates webkit to v2.50.4. Verified build and sanity on mac, windows and linux platforms. No issue seen.

Looks good. My sanity testing is green.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/2063#pullrequestreview-3757198550

From jpereda at openjdk.org  Thu Feb  5 14:15:47 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 5 Feb 2026 14:15:47 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error building
 libprism_es2
Message-ID: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>

This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.

-------------

Commit messages:
 - Fix errors and warnings building prism_es2 for iOS

Changes: https://git.openjdk.org/jfx/pull/2064/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377185
  Stats: 16 lines in 5 files changed: 4 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/2064.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2064/head:pull/2064

PR: https://git.openjdk.org/jfx/pull/2064

From lkostyra at openjdk.org  Thu Feb  5 14:46:04 2026
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 5 Feb 2026 14:46:04 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <kFKf0BcXxAjs9-TlYFwGbA2SpDTSbS44DdECm0taS2k=.a3588aa5-c790-4003-8fbc-7e04821f7d64@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

LGTM. This change is fairly straightforward and it removes a pretty important point of discrepancy between hardware. To my knowledge even modern APIs support ABGR format more commonly than XBGR, so I don't suspect this would break anything.

My main Windows machine did not have the issue (so I guess it won the GPU driver lottery) but I verified it with the Windows 10 Hyper-V VM - Unified Stages do not render without the fix and render properly with transparency when adding the fix. Other sanity testing also looked good.

-------------

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2058#pullrequestreview-3757555374

From kcr at openjdk.org  Thu Feb  5 14:56:34 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Feb 2026 14:56:34 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <SIox8s3tEUVn5fJqJckzSk_eDNcyphdHdhaCNfxfb4s=.17e80d00-d4d9-4278-821a-0061478ed03c@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

I wasn't able to reproduce this (I tried on an old system that once had done so, but that was when it was running Windows 10 with a different driver).

I did run some tests and I see no regressions, so I'll approve this as well.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/2058#pullrequestreview-3757615574

From duke at openjdk.org  Thu Feb  5 15:30:52 2026
From: duke at openjdk.org (duke)
Date: Thu, 5 Feb 2026 15:30:52 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <PyGYwWWfewqClOsMvKYeYVQTh5tQgZQmJc8ZvHaSx-Q=.dc96f5df-ee7f-42bb-9073-abc3a65e8006@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

@crschnick 
Your change (at version ca0683f820db7adfbfef818a88489649f1c3c215) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3854388282

From duke at openjdk.org  Thu Feb  5 16:30:40 2026
From: duke at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 16:30:40 GMT
Subject: Integrated: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <EFLunMq1QnrGh3PH1mczL_8ScyHH1Kaum1lXs_0ErLI=.31238398-b04d-400b-a240-d911e9de03bf@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

This pull request has now been integrated.

Changeset: 28bde153
Author:    Christopher Schnick <cr at crschnick.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8154847: Rendering is incorrect or not visible with StageStyle.UNIFIED on some graphics cards

Co-authored-by: Martin Fox <mfox at openjdk.org>
Reviewed-by: lkostyra, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/2058

From kevin.rushforth at oracle.com  Thu Feb  5 16:31:07 2026
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 5 Feb 2026 08:31:07 -0800
Subject: JavaFX 26 is in Rampdown Phase Two (RDP2)
Message-ID: <7e02d9b8-593e-4423-b442-2218fbe52b5e@oracle.com>

To: JavaFX Developers

As a reminder, JavaFX 26 is now in Rampdown Phase Two (RDP2). [1]

P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed 
during RDP2. Explicit approval is needed for all bug fixes and 
enhancements (except for doc and test fixes) to go in to the jfx26 
branch [2]. The bar for approving bug fixes is appropriately high at 
this point. We do not anticipate approving any more enhancements.

Now that we are in RDP2, the goal is to stabilize what is there, fixing 
bugs that are new in JavaFX 26. We need to be extremely careful about 
including anything that introduces risk.

We will use the same rules for RDP2 that the JDK uses [3], with two 
modifications:

1. Approval is needed from one of the OpenJFX project leads (not the 
OpenJDK project lead)

2. Since we are not part of the JDK, we need to use labels that do not 
collide with the JDK 26 release. As an obvious choice, derived from the 
JBS fix version, we will use "jfx26-fix-request", "jfx26-fix-yes", 
"jfx26-fix-no" and "jfx26-fix-nmi", "jfx26-enhancement-request", 
"jfx26-enhancement-yes", "jfx26-enhancement-no" and 
"jfx26-enhancement-nmi" as corresponding labels.

REMINDER: In this release we will integrate almost all stabilization 
changes via backports from the master branch [4].

 ? * Almost all fixes intended for the jfx26 stabilization branch will 
also be applicable to the master branch. Integrate such a change into 
the master branch first. Then, after you have obtained any required 
approvals, backport it to the stabilization branch using the Skara 
`/backport` command or, if necessary, by manually opening a backport PR 
with the title `Backport $HASH`, where `$HASH` is the original commit 
hash.? (The JDK Developers? Guide contains more information on working 
with backports [5].)

 ? * Some fixes will be specific to the stabilization branch and not 
applicable to the master branch. Integrate such a change directly into 
the stabilization branch.

IMPORTANT: Reviewers and Committers now have an extra responsibility to 
double-check the target branch of each PR that they review, integrate, 
or sponsor. By default a PR will be targeted to `master` which is the 
main development line (JavaFX 26 as of today). This is usually what we 
want. A backport PR should be targeted to `jfx26` if, and only if, it is 
intended for JavaFX 26 and meets the criteria for the current rampdown 
phase (we're in RDP2 as of today). Reviewers are advised to be extra 
cautious in approving potentially risky fixes targeted to `jfx26`. If 
there is a concern, then a reviewer can as part of the review indicate 
that the PR should be retargeted to `master` for 26 (or withdrawn if it 
is a backport of a fix already in `master`). Reviewers also need to be 
extra careful when reviewing PRs targeted to jfx26 that it doesn't 
mistakenly contain any commits from the master branch. You'll be able to 
tell because the diffs will contain changes that are not part of the fix 
being reviewed. Such a PR will either need to be closed and redone, or 
it will need to be rebased and force-pushed. This should be less of a 
problem for this release, since almost all PRs for jfx26 will be done as 
backport-style PRs, but it can still be a problem if the developer 
mistakenly merges master into their backport branch.

Let me know if there are any questions.

-- Kevin


[1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-November/057615.html

[2] https://github.com/openjdk/jfx/tree/jfx26

[3] http://openjdk.org/jeps/3

[4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements

[5] https://openjdk.org/guide/#working-with-backports-in-jbs



From duke at openjdk.org  Thu Feb  5 17:14:59 2026
From: duke at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 17:14:59 GMT
Subject: RFR: 8375578: Enable translucent window backdrops
In-Reply-To: <T7B2wvrpV6WGSXOsYz39SszSBuBRKGsmmg20Bp4YAFg=.2fc76972-844c-47af-b36c-3634263b5e5a@github.com>
References: <BhkSCG097CfBhCDNEbPVzWCZfGjN2ZkdpLopdexpR_w=.b389de7e-156b-4f8f-8c7d-fda8c69ccaff@github.com>
 <XlrH4dyQ1nBrRfK67kWzcmgvKKMyVXSHAYubVyAmh3Q=.2767f8e9-6db0-4eda-b40b-2945ae7a6893@github.com>
 <T7B2wvrpV6WGSXOsYz39SszSBuBRKGsmmg20Bp4YAFg=.2fc76972-844c-47af-b36c-3634263b5e5a@github.com>
Message-ID: <tKMGxnDIqD4r3uCXHs_t7D7Ccuq85N0WMVwyMfH1mf4=.c97b2b91-cf87-4d91-a790-162e40c5b25a@github.com>

On Thu, 29 Jan 2026 16:27:53 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Depending on how long this takes, would it be possible to extract the fix for the unified stage BackBufferFormat (if it actually fixes all cases) as a separate PR? That would make the review easier to split a feature addition and bugfix into two issues. I can definitely do the testing for the fix
>
>> Depending on how long this takes, would it be possible to extract the fix for the unified stage BackBufferFormat (if it actually fixes all cases) as a separate PR?
> 
> It would probably be faster for you to test and submit the PR yourself. The fix is just the two lines in native-prism-d3d where the BackBufferFormat is set to D3DFMT_A8R8G8B8 instead of being left unspecified. Based on the write up for bug [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847) if you don't set the back buffer format what you get varies depending on the graphic card. It should be OK to enable alpha unconditionally, in the end it should only affect UNIFIED. Most stage styles wipe out the alpha channel by drawing an opaque background. The exceptions are TRANSPARENT and UNIFIED and only UNIFIED uses the swap chain.
> 
> If you'd prefer I can enter the PR but it would probably have to wait until next week.

@beldenfox you can now rebase on master and remove the BackBufferFormat adjustments in this PR. That should make this PR more straightforward

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3855015482

From duke at openjdk.org  Thu Feb  5 17:54:57 2026
From: duke at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 17:54:57 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <QkU1WlT3nuiP2XZg91UuH54qE8te1bhXxERvJYKwATQ=.d0a9c529-d4a2-41f2-af33-a8960ee3fb55@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

I think this is a good target for a backport? I have no idea how the backport process works in practice though. Is there page where that process is documented?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3855244048

From kcr at openjdk.org  Thu Feb  5 18:55:55 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Feb 2026 18:55:55 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <QkU1WlT3nuiP2XZg91UuH54qE8te1bhXxERvJYKwATQ=.d0a9c529-d4a2-41f2-af33-a8960ee3fb55@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
 <QkU1WlT3nuiP2XZg91UuH54qE8te1bhXxERvJYKwATQ=.d0a9c529-d4a2-41f2-af33-a8960ee3fb55@github.com>
Message-ID: <G43I4BKLGjrYeoTCZ3dk8Eisfp6d66JjgUWN0QEWYbA=.fa7e61b8-f12d-4450-9f93-216b8aadfa04@github.com>

On Thu, 5 Feb 2026 17:52:23 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> I think this is a good target for a backport? I have no idea how the backport process works in practice though. Is there page where that process is documented?

Given where we are in the JavaFX 26 release cycle, it is too late for the GA release, but this seems like a good candidate for a 26 update release (jfx26u) and possibly also a 25 update release (jfx25u).

See [this message](https://mail.openjdk.org/pipermail/openjfx-dev/2026-January/058955.html) on the mailing list. The easiest way is to use Skara's `/backport` command, which in this case would be `/backport jfx26u`. You can issue the `/backport` command by adding a comment either in this PR or in the commit, 28bde153cbf960e1b8d74d258ba351a5305f124b in the repo. Then follow the instructions to create the PR. Once you have created the PR, request approval (using Skara's `/approval request` command).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3855555398

From jpereda at openjdk.org  Thu Feb  5 19:10:11 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 5 Feb 2026 19:10:11 GMT
Subject: RFR: 8377316: [iOS] App crashes due to GlassThreadDataKey not
 initialized
Message-ID: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>

This PR moves the pthread initialization outside the assertion, which is typically ignored as `NDEBUG` is defined in the compilation phase. Therefore a possible runtime crash is prevented if the pthread initialization is bypassed in such case.

-------------

Commit messages:
 - Move pthread initialization outside assert

Changes: https://git.openjdk.org/jfx/pull/2065/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2065&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377316
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/2065.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2065/head:pull/2065

PR: https://git.openjdk.org/jfx/pull/2065

From duke at openjdk.org  Thu Feb  5 19:22:25 2026
From: duke at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 19:22:25 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <e7r7HKRFKijrxt2FLNV1AckWGCwBdQRJMhP9tLXAz1Y=.95746318-9266-4874-b2f7-1ba2b252e222@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

Ok so according https://wiki.openjdk.org/spaces/SKARA/pages/39616516/Skara#Skara-GitHub, associating an account is only posible for Author, Committer or Reviewer 

If I understand correctly, I am a Contributor right now. But I show up in https://openjdk.org/census#crschnick as Author? Or do the different projects use inconsistent naming schemes for the same thing?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3855724482

From kcr at openjdk.org  Thu Feb  5 19:36:29 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 5 Feb 2026 19:36:29 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <e7r7HKRFKijrxt2FLNV1AckWGCwBdQRJMhP9tLXAz1Y=.95746318-9266-4874-b2f7-1ba2b252e222@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
 <e7r7HKRFKijrxt2FLNV1AckWGCwBdQRJMhP9tLXAz1Y=.95746318-9266-4874-b2f7-1ba2b252e222@github.com>
Message-ID: <lDFe8TDDol_e-wuoi6pgQGye2Q_7EW14Y7g0VNAwCPY=.26d26ee5-37a7-4963-98c8-c85bbf4d4f84@github.com>

On Thu, 5 Feb 2026 19:19:36 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> Ok so according https://wiki.openjdk.org/spaces/SKARA/pages/39616516/Skara#Skara-GitHub, associating an account is only posible for Author, Committer or Reviewer
> 
> If I understand correctly, I am a Contributor right now. But I show up in https://openjdk.org/census#crschnick as Author? Or do the different projects use inconsistent naming schemes for the same thing?

Skara doesn't know that you are you. :) 

Meaning, Skara doesn't know that `crschnick at github.com` is crschnick in the OpenJDK census. Follow the [instructions here](https://wiki.openjdk.org/spaces/SKARA/pages/39616516/Skara#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername) -- to associate your OpenJDK ID with your GitHub account.

I meant to point you at this shortly after you became an Author, but forgot.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3855787138

From duke at openjdk.org  Thu Feb  5 19:36:30 2026
From: duke at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 19:36:30 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <Oq4NiWI_rds9j7mu0fu_IFjOy6695AVatPnDwKyi5LQ=.96e133ec-b651-4c48-8456-0b431aa72137@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <duke at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

Oh yeah I get that, but I was confused the names for the roles. I got them mixed up, everything is good now

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3855793945

From andy.goryachev at oracle.com  Thu Feb  5 20:29:06 2026
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 5 Feb 2026 20:29:06 +0000
Subject: Experiment: Node properties
In-Reply-To: <CY8PR10MB72651B8D00F2F0D9A7A35AB5E598A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB72651B8D00F2F0D9A7A35AB5E598A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CY8PR10MB726509402F9E86697AB0FE86E599A@CY8PR10MB7265.namprd10.prod.outlook.com>

To take it further, decreasing the cost of rarely used properties in the Node class (or the Node class hierarchy should this idea gains traction) would make it possible to add more convenience properties such as boundsOnScreen, owningWindow, etc.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Andy Goryachev <andy.goryachev at oracle.com>
Date: Wednesday, February 4, 2026 at 13:17
To: OpenJFX <openjfx-dev at openjdk.org>
Subject: Experiment: Node properties

I would like to share the results of a little experiment involving optimization of storage of Node properties.  The basic idea is to create a compact fast map-like container to hold the rarely instantiated properties in order to reduce the application memory footprint.

The savings are not overwhelming, but not exactly zero.  I would imagine this optimization might be more interesting in any resource constrained environment such as Android / iOS / RaspberryPi.  Please refer to [0] for the details.

I encourage you to try it with your application, to see whether you notice any change in memory consumption and/or performance.  Let me know what you think!

Cheers,
-andy


References

[0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260205/341b55fd/attachment.htm>

From crschnick at openjdk.org  Thu Feb  5 20:40:37 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 20:40:37 GMT
Subject: [jfx26u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
Message-ID: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>

Hi all,

This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 28bde153cbf960e1b8d74d258ba351a5305f124b

Changes: https://git.openjdk.org/jfx26u/pull/6/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx26u&pr=6&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8154847
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx26u/pull/6.diff
  Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/6/head:pull/6

PR: https://git.openjdk.org/jfx26u/pull/6

From crschnick at openjdk.org  Thu Feb  5 20:47:09 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Thu, 5 Feb 2026 20:47:09 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
Message-ID: <NTgN-m1W6EAp_ZR7EaR0geXpx-qG7Utr-3dBITeVu00=.ab134d9e-e5d3-4446-8d31-1428e2be1a6b@github.com>

On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8.
> 
> If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong.
> 
> This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable.
> 
> Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms.
> 
> The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems.
> 
> The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM.
> 
> You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason.
> 
> You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare.

Ok that worked now. Two things I noticed: The backport does not list co-contributors and the autogenerated email with the PR description template contains leading spaces, meaning that you need to do some manual fomatting after copy-pasting the text

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3856090690

From mstrauss at openjdk.org  Fri Feb  6 02:39:01 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 6 Feb 2026 02:39:01 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
Message-ID: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>

`test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:


TooltipTest > testCssStylesheetChangeTooltip() FAILED
    java.lang.AssertionError
        at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
        at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
        at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
        at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
        at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
        at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
        at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
        at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
        at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
        at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
        at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
        at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)


or


TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
    Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
        at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
        at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
        at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
        at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.Node.reapplyCss(Node.java:9996)
        ...


This test bug is solved by making sure that the scene graph is only accessed on the FX application thread.

Run the test with:

./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.TooltipTest.testCssStylesheetChangeTooltip

-------------

Commit messages:
 - Access scene graph on FX application thread

Changes: https://git.openjdk.org/jfx/pull/2066/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377189
  Stats: 115 lines in 1 file changed: 56 ins; 26 del; 33 mod
  Patch: https://git.openjdk.org/jfx/pull/2066.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2066/head:pull/2066

PR: https://git.openjdk.org/jfx/pull/2066

From crschnick at xpipe.io  Fri Feb  6 04:28:09 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 6 Feb 2026 05:28:09 +0100
Subject: Experiment: Node properties
In-Reply-To: <CY8PR10MB726509402F9E86697AB0FE86E599A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB72651B8D00F2F0D9A7A35AB5E598A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CY8PR10MB726509402F9E86697AB0FE86E599A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <fbaea106-3f83-47b1-b4db-2657d43002cb@xpipe.io>

I tested it with our application that creates a lot of nodes, and the 
heap was reduced by around 25-50MB on a ~600MB heap. But that was with 
putting as much nodes as possible on the screen.

So yeah it's definitely nice to have if it doesn't introduce a lot of 
other complexity and potential issues.

On 05/02/2026 21:29, Andy Goryachev wrote:
> To take it further, decreasing the cost of rarely used properties in 
> the Node class (or the Node class hierarchy should this idea gains 
> traction) would make it possible to add more convenience properties 
> such as boundsOnScreen, owningWindow, etc.
>
> -andy
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Andy 
> Goryachev <andy.goryachev at oracle.com>
> *Date: *Wednesday, February 4, 2026 at 13:17
> *To: *OpenJFX <openjfx-dev at openjdk.org>
> *Subject: *Experiment: Node properties
>
> I would like to share the results of a little experiment involving 
> optimization of storage of Node properties. ?The basic idea is to 
> create a compact fast map-like container to hold the rarely 
> instantiated properties in order to reduce the application memory 
> footprint.
>
> The savings are not overwhelming, but not exactly zero. ?I would 
> imagine this optimization might be more interesting in any resource 
> constrained environment such as Android / iOS / RaspberryPi. ?Please 
> refer to [0] for the details.
>
> I encourage you to try it with your application, to see whether you 
> notice any change in memory consumption and/or performance. ?Let me 
> know what you think!
>
> Cheers,
> -andy
>
>
> *References*
>
> [0] 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260206/3927f04c/attachment.htm>

From arapte at openjdk.org  Fri Feb  6 08:23:29 2026
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 6 Feb 2026 08:23:29 GMT
Subject: RFR: 8377316: [iOS] App crashes due to GlassThreadDataKey not
 initialized
In-Reply-To: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>
References: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>
Message-ID: <geLVduREplH9w2mCnuOFI9vJ-qt1ZBZwXleO4agtVIY=.27c62897-e1a7-45eb-9c38-1d476d8def1a@github.com>

On Thu, 5 Feb 2026 19:05:06 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR moves the pthread initialization outside the assertion, which is typically ignored as `NDEBUG` is defined in the compilation phase. Therefore a possible runtime crash is prevented if the pthread initialization is bypassed in such case.

LGTM..

-------------

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2065#pullrequestreview-3761496352

From lkostyra at openjdk.org  Fri Feb  6 12:36:19 2026
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 6 Feb 2026 12:36:19 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <we5-Z-Cw3mmDw_Ttt6tAL5UrJh-Rav0ggGkwLY2prOU=.9f7df788-5b26-4ec7-a4e8-d79a1c1b5351@github.com>

On Fri, 6 Feb 2026 02:33:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

The change is pretty straightforward, but since it was an intermittent failure I think we should have two pairs of eyes verify it.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2066#issuecomment-3860189414

From kcr at openjdk.org  Fri Feb  6 13:31:53 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Feb 2026 13:31:53 GMT
Subject: RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <NTgN-m1W6EAp_ZR7EaR0geXpx-qG7Utr-3dBITeVu00=.ab134d9e-e5d3-4446-8d31-1428e2be1a6b@github.com>
References: <VJSlILr-90pZGgleeq8tiXbLpc2IEWNdz4S7oUUA-vw=.22b65fc4-b716-4932-a280-e37feddc048e@github.com>
 <NTgN-m1W6EAp_ZR7EaR0geXpx-qG7Utr-3dBITeVu00=.ab134d9e-e5d3-4446-8d31-1428e2be1a6b@github.com>
Message-ID: <SRuskwFPldej5txdFCTIhkUS7BLGksNz4Ob5K89Q-XQ=.31e73137-ca32-4d78-b41a-5f26e83eeb83@github.com>

On Thu, 5 Feb 2026 20:44:46 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Ok that worked now. Two things I noticed: The backport does not list co-contributors and the autogenerated email with the PR description template contains leading spaces, meaning that you need to do some manual fomatting after copy-pasting the text

The PR description is just meant for those who will look at it, so not listing co-contributors doesn't present a problem. I hadn't noticed the leading spaces before, but I don't typically look at the email Skara sends when creating a backport PR.

I see that you created the backport PR successfully, so I'll take a look at it.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3860473981

From kcr at openjdk.org  Fri Feb  6 13:34:05 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Feb 2026 13:34:05 GMT
Subject: [jfx26u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
References: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
Message-ID: <1PeK2_TuG__G_5KmSc1th5jke_v2ilNHRN2DQJX_hew=.44a20623-3532-4a1d-baa6-d992a1debcc7@github.com>

On Thu, 5 Feb 2026 20:31:21 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.
> 
> Thanks!

@crschnick As Skara notes, you forgot the "request" modifier for the "approval" command. Something like this is what you will need: `/approval request REASON YOU THINK IT SHOULD BE BACKPORTED` (and don't worry much about the reason...we already discussed it on the PR and I'll approve it once you make the request).

-------------

PR Comment: https://git.openjdk.org/jfx26u/pull/6#issuecomment-3860488001

From kcr at openjdk.org  Fri Feb  6 13:52:46 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Feb 2026 13:52:46 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <IPWXPaRMj_Lxy1JKH6Xl7hb0-o5jFrXo14rDqVqk3aE=.76186eb7-d3e9-475b-80e0-c195c1723163@github.com>

On Fri, 6 Feb 2026 02:33:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

LGTM. I ran the test 100 times in a loop without your fix on my Mac M1 system and it failed after 14 iterations. With the fix it passed all 100 times.

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph ...

Ah, good. So it was a test bug, likely exposed by [JDK-8375363](https://bugs.openjdk.org/browse/JDK-8375363), as you suggested in the bug report.

Thanks for fixing this!

@andy-goryachev-oracle or @lukostyra Can one of you be the second reviewer?

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/2066#pullrequestreview-3763230330

From lkostyra at openjdk.org  Fri Feb  6 14:06:02 2026
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 6 Feb 2026 14:06:02 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <wR5Gd33hmwgZQm7zQlzBK2CSPNFzoHanEb54HTMdV_k=.b9940caf-5bc9-4cda-ab06-f927af54cb65@github.com>

On Fri, 6 Feb 2026 02:33:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

I ran this on my Windows machine also for 100 iterations and the results seem good.

I noticed in a similar CI run (100 iterations of just `TooltipTest`) that one instance just barely missed the mark on one of the Tooltip show assertions:

TooltipTest > testShowDelayCssShowTooltipTwice() FAILED
    org.opentest4j.AssertionFailedError: 204 <= 200 ==> expected: <true> but was: <false>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
        at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214)
        at app//test.robot.javafx.scene.TooltipTest.assertTooltipShowDelay(TooltipTest.java:72)
        at app//test.robot.javafx.scene.TooltipTest.testShowDelayCssShowTooltipTwice(TooltipTest.java:228)


I am wondering if we should slightly increase it? I'm not 100% sure if that would make sense though, since it is mostly just trying to chase a random hiccup which can still happen if we're less lucky...

-------------

PR Review: https://git.openjdk.org/jfx/pull/2066#pullrequestreview-3763298331

From kcr at openjdk.org  Fri Feb  6 14:10:07 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Feb 2026 14:10:07 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <wR5Gd33hmwgZQm7zQlzBK2CSPNFzoHanEb54HTMdV_k=.b9940caf-5bc9-4cda-ab06-f927af54cb65@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
 <wR5Gd33hmwgZQm7zQlzBK2CSPNFzoHanEb54HTMdV_k=.b9940caf-5bc9-4cda-ab06-f927af54cb65@github.com>
Message-ID: <OAm0il4XegOO4iY1d5-7Jg9Hao1xGUzODwCTJ8YHJJk=.9ee40d58-fa06-4183-b2d6-b79eb97f7aaa@github.com>

On Fri, 6 Feb 2026 14:02:30 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> I noticed in a similar CI run (100 iterations of just TooltipTest) that one instance just barely missed the mark on one of the Tooltip show assertions ...

I might recommend doing that separately rather than as part of this fix, but either is fine with me.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2066#issuecomment-3860680615

From kcr at openjdk.org  Fri Feb  6 14:44:51 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 6 Feb 2026 14:44:51 GMT
Subject: [jfx26u] RFR: Merge jfx:jfx26
Message-ID: <5P4QExQ5TIB-gICuffZ8XOuXpMNRgkhy1KlNRepCNEY=.f4c8bd03-3a67-4817-a5e6-fd2cb980b144@github.com>

Clean merge from `jfx:jfx26` to `jfx26u:master`.

-------------

Commit messages:
 - Merge
 - 8375466: Metal rendering pipeline crashes on virtualized OS
 - 8373936: RichEditorDemoApp enhancements

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx26u/pull/7/files
  Stats: 1348 lines in 14 files changed: 871 ins; 349 del; 128 mod
  Patch: https://git.openjdk.org/jfx26u/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/7/head:pull/7

PR: https://git.openjdk.org/jfx26u/pull/7

From jvos at openjdk.org  Fri Feb  6 14:56:38 2026
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 6 Feb 2026 14:56:38 GMT
Subject: RFR: 8377316: [iOS] App crashes due to GlassThreadDataKey not
 initialized
In-Reply-To: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>
References: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>
Message-ID: <GFJy9l1_jtSxVr0f4A44GWFqd15xQ5gyTHIKNIhpaZM=.88565f72-6067-4fd0-a39e-298db541fc0e@github.com>

On Thu, 5 Feb 2026 19:05:06 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR moves the pthread initialization outside the assertion, which is typically ignored as `NDEBUG` is defined in the compilation phase. Therefore a possible runtime crash is prevented if the pthread initialization is bypassed in such case.

Marked as reviewed by jvos (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/2065#pullrequestreview-3763559902

From andy.goryachev at oracle.com  Fri Feb  6 15:01:12 2026
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 6 Feb 2026 15:01:12 +0000
Subject: [External] : Re: Experiment: Node properties
In-Reply-To: <fbaea106-3f83-47b1-b4db-2657d43002cb@xpipe.io>
References: <CY8PR10MB72651B8D00F2F0D9A7A35AB5E598A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CY8PR10MB726509402F9E86697AB0FE86E599A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <fbaea106-3f83-47b1-b4db-2657d43002cb@xpipe.io>
Message-ID: <CY8PR10MB726544DB742D358B6B18F1A0E566A@CY8PR10MB7265.namprd10.prod.outlook.com>

This is an interesting result, thanks for testing!  It sort of matches my result - not quite 10%, but then again it's not a complete set of properties/classes.  I wonder if doing this trick for Region and Labeled should release even more memory.

Did you run the branch with no instrumentation and used VisualVM?  Did you notice any impact on performance?

Thanks!
-andy




From: Christopher Schnick <crschnick at xpipe.io>
Date: Thursday, February 5, 2026 at 20:29
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: [External] : Re: Experiment: Node properties


I tested it with our application that creates a lot of nodes, and the heap was reduced by around 25-50MB on a ~600MB heap. But that was with putting as much nodes as possible on the screen.

So yeah it's definitely nice to have if it doesn't introduce a lot of other complexity and potential issues.

On 05/02/2026 21:29, Andy Goryachev wrote:
To take it further, decreasing the cost of rarely used properties in the Node class (or the Node class hierarchy should this idea gains traction) would make it possible to add more convenience properties such as boundsOnScreen, owningWindow, etc.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Andy Goryachev <andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com>
Date: Wednesday, February 4, 2026 at 13:17
To: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Experiment: Node properties

I would like to share the results of a little experiment involving optimization of storage of Node properties.  The basic idea is to create a compact fast map-like container to hold the rarely instantiated properties in order to reduce the application memory footprint.

The savings are not overwhelming, but not exactly zero.  I would imagine this optimization might be more interesting in any resource constrained environment such as Android / iOS / RaspberryPi.  Please refer to [0] for the details.

I encourage you to try it with your application, to see whether you notice any change in memory consumption and/or performance.  Let me know what you think!

Cheers,
-andy


References

[0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md<https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md__;!!ACWV5N9M2RV99hQ!KUAfcEsUwD1Nm7pkzJLJtwdpbpqI2T-46rvMVrfxUFaR6sizzAAMYZxWDvnr7_qJJylFQfIsOfOEEgGIYybK_ZWv$>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260206/4fab0e81/attachment.htm>

From jpereda at openjdk.org  Fri Feb  6 15:00:11 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 6 Feb 2026 15:00:11 GMT
Subject: Integrated: 8377316: [iOS] App crashes due to GlassThreadDataKey not
 initialized
In-Reply-To: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>
References: <nFFkxtI_mpdBMh_NEST3IbsmwzGS2ITxZPeX8MOtyuc=.67de01a2-09de-4703-8905-79f40944e7d6@github.com>
Message-ID: <cMpcm2fosvzEZPCH8-SVWm82Q-3AsWtvDj5qrCE8lis=.bade9f09-8728-4f08-8a14-f1d925b2ce53@github.com>

On Thu, 5 Feb 2026 19:05:06 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR moves the pthread initialization outside the assertion, which is typically ignored as `NDEBUG` is defined in the compilation phase. Therefore a possible runtime crash is prevented if the pthread initialization is bypassed in such case.

This pull request has now been integrated.

Changeset: 60139bd0
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/60139bd0298e7cb60391ba9e683670091843769b
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8377316: [iOS] App crashes due to GlassThreadDataKey not initialized

Reviewed-by: arapte, jvos

-------------

PR: https://git.openjdk.org/jfx/pull/2065

From crschnick at xpipe.io  Fri Feb  6 21:41:35 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 6 Feb 2026 22:41:35 +0100
Subject: [External] : Re: Experiment: Node properties
In-Reply-To: <CY8PR10MB726544DB742D358B6B18F1A0E566A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB72651B8D00F2F0D9A7A35AB5E598A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CY8PR10MB726509402F9E86697AB0FE86E599A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <fbaea106-3f83-47b1-b4db-2657d43002cb@xpipe.io>
 <CY8PR10MB726544DB742D358B6B18F1A0E566A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <49949a9c-f703-49dd-b626-e4c3147a7b0d@xpipe.io>

I used the no instrumentation branch with the IntelliJ profiler. Didn't 
see any performance issues.

If you are adding enough nodes while also having a lot of stylesheets to 
arrive at a heap size of ~600MB, there is a performance impact in 
general even without using this branch.

On 06/02/2026 16:01, Andy Goryachev wrote:
> This is an interesting result, thanks for testing! ?It sort of matches 
> my result - not quite 10%, but then again it's not a complete set of 
> properties/classes. ?I wonder if doing this trick for Region and 
> Labeled should release even more memory.
>
> Did you run the branch with no instrumentation and used VisualVM? ?Did 
> you notice any impact on performance?
>
> Thanks!
> -andy
>
>
>
>
> *From: *Christopher Schnick <crschnick at xpipe.io>
> *Date: *Thursday, February 5, 2026 at 20:29
> *To: *Andy Goryachev <andy.goryachev at oracle.com>
> *Cc: *OpenJFX <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: Experiment: Node properties
>
> I tested it with our application that creates a lot of nodes, and the 
> heap was reduced by around 25-50MB on a ~600MB heap. But that was with 
> putting as much nodes as possible on the screen.
>
> So yeah it's definitely nice to have if it doesn't introduce a lot of 
> other complexity and potential issues.
>
> On 05/02/2026 21:29, Andy Goryachev wrote:
>
>     To take it further, decreasing the cost of rarely used properties
>     in the Node class (or the Node class hierarchy should this idea
>     gains traction) would make it possible to add more convenience
>     properties such as boundsOnScreen, owningWindow, etc.
>
>     -andy
>
>
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>?on behalf of
>     Andy Goryachev <andy.goryachev at oracle.com>
>     *Date: *Wednesday, February 4, 2026 at 13:17
>     *To: *OpenJFX <openjfx-dev at openjdk.org>
>     *Subject: *Experiment: Node properties
>
>     I would like to share the results of a little experiment involving
>     optimization of storage of Node properties. ?The basic idea is to
>     create a compact fast map-like container to hold the rarely
>     instantiated properties in order to reduce the application memory
>     footprint.
>
>     The savings are not overwhelming, but not exactly zero. ?I would
>     imagine this optimization might be more interesting in any
>     resource constrained environment such as Android / iOS /
>     RaspberryPi. ?Please refer to [0] for the details.
>
>     I encourage you to try it with your application, to see whether
>     you notice any change in memory consumption and/or performance.
>     ?Let me know what you think!
>
>     Cheers,
>     -andy
>
>
>     *References*
>
>     [0]
>     https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260206/1584a7d0/attachment.htm>

From johan.vos at gluonhq.com  Mon Feb  9 13:26:30 2026
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 9 Feb 2026 14:26:30 +0100
Subject: backport requests
Message-ID: <CABxFH2FO_hZXwX1=2pDtgrJ-AnLwZfJc22YfTttUEsC33iTHUQ@mail.gmail.com>

Hi,

TLDR: When doing a backport, it helps if you give as much information as
possible on why you believe such a backport is important.

I see an increasing number of backport requests for javafx 17, 21 and 25.
It's really great to see developers wanting to improve older versions of
JavaFX.
I want to apologize for not approving all those requests, but let me
explain the reasons, and let's see how we can move forward.

First of all, integrating a backport is expensive. The resulting code and
builds are available for free, so there is a cost but no income for this
(simply said, it's sponsored by Gluon)
We run all tests on our own hardware, and we need to maintain this
hardware. Moreover, the different OS versions and build tools need to be
maintained as well, and they are often different between LTS versions. That
creates a complex situation, since we don't want to have 3 dedicated
hardware sets for 3 LTS releases. Head-releases are relatively easy, but
LTS releases require lots of administration/infrastructure.

As most of you know, a full JavaFX build takes some time. Especially
building webkit (and especially on Windows) is a resource-intensive process
of > 1 hour. Running all tests takes even more time.
For LTS releases, it is extremely important not to break something, as
organisations rely on the assumptions that LTS releases are rock stable.
Every change, no matter how small, is a candidate for breaking something,
hence every change needs to go through rigorous multi-platform testing.

So what backports are currently being accepted?

1. Security fixes.
This is the single most important category. When vulnerabilities are
disclosed, there needs to be a release of JavaFX LTS versions where those
vulnerabilities are addressed. That means the security fixes that go in
e.g. 26.0.1 should be backported to 17/21/25.

2. Fixes in third party components (e.g. webkit, xslt)
Security issues are often related to third party components, and in order
to apply the security fixes, it help staying on the latest release.

3. P1/P2 issues.
Clearly, we don't want to have critical bugs in the release.

4. Simple, well documented, small fixes that are already applied and tested
in HEAD and have been in a release, and that address issues affecting a
large user base and that have no dependencies on later Java versions (e.g.
JavaFX requires JDK 11, so no switch expressions etc)

Skara is extremely helpful when doing backports. If a backport can be
applied clean to an LTS repository, Skara will tell you, and the process
becomes easier. Off course, everything still needs to be tested.

When doing a backport, it helps if you give as much information as possible
on why you believe such a backport is important, and why you think the risk
is low. In case I believe the benefits of a particular backport request do
not outweigh the risk, I will reply in the PR for that backport and we can
discuss further.

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260209/2a935e93/attachment-0001.htm>

From jvos at openjdk.org  Mon Feb  9 21:47:29 2026
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 9 Feb 2026 21:47:29 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2
In-Reply-To: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
Message-ID: <3vv1Ny6Aa4fOtM-9HYg_UBdH9hiwwTRqkpFT8xqV9wA=.81b942e9-135f-427b-b010-237b1f528859@github.com>

On Thu, 5 Feb 2026 14:08:17 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.

modules/javafx.graphics/src/main/native-prism-es2/ios/ios-window-system.h line 31:

> 29: #import <jni.h>
> 30: 
> 31: #ifndef jlong_to_ptr

Probably better to completely remove these definitions here.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2064#discussion_r2774607415

From mstrauss at openjdk.org  Mon Feb  9 21:47:44 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Feb 2026 21:47:44 GMT
Subject: RFR: 8377426: Adjust scene background to color scheme
Message-ID: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>

When a non-opaque scene fill color is used with a stage style other than `StageStyle.TRANSPARENT`, the actual fill color is always white. This doesn't work well when the scene uses a dark color scheme. A practical solution is to allow non-opaque scene fill colors, and blend them on top of a white or black background (depending on color scheme) to derive an opaque color that adapts intuitively to the color scheme.

To test this, simply create a scene that uses a non-opaque fill color and observe the scene background when the color scheme is changed.

This PR includes a system test, run it with:

./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.SceneFillTest.testSceneFill

-------------

Commit messages:
 - Adjust scene background to color scheme

Changes: https://git.openjdk.org/jfx/pull/2068/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377426
  Stats: 164 lines in 5 files changed: 155 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/2068.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2068/head:pull/2068

PR: https://git.openjdk.org/jfx/pull/2068

From angorya at openjdk.org  Mon Feb  9 21:47:58 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Feb 2026 21:47:58 GMT
Subject: RFR: 8377393: RichTextArea: failed to export null color attribute
 value
Message-ID: <2J3fKhgi4sLbJMgbRr1E6JqGFJpPGWY4CuxNOaWi7PU=.5c03a63c-c553-4df9-ac18-9739a69d0db4@github.com>

RichEditorDemo exposed a logical flaw in the RichTextFormatHandler responsible for copy/save/export code. Technically speaking, this is a product bug in the RichTextArea, though it can only be reproduced with RichEditorDemo.

To reproduce:

- open RichEditorDemo app
- type 1, tab, 2, tab, 3
- select the first line
- copy (command-C or ctrl-C)
- paste (command-V or ctrl-V)

--> nothing gets pasted because the RichEditorDemo toolbar sets the text color to null, which breaks the attribute

Also, attempt to save this file produces corrupted output.

-------------

Commit messages:
 - export null color value

Changes: https://git.openjdk.org/jfx/pull/2067/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377393
  Stats: 13 lines in 2 files changed: 6 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/2067.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2067/head:pull/2067

PR: https://git.openjdk.org/jfx/pull/2067

From mstrauss at openjdk.org  Mon Feb  9 21:48:08 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Feb 2026 21:48:08 GMT
Subject: RFR: 8375588: Enhanced property metadata [v4]
In-Reply-To: <yOvPWXkQMCySoZypGlw9ts5dDdiKQMg5gGGammA5Th0=.8b20e0d1-2574-4b96-a4a4-e24376241220@github.com>
References: <K_PNHjvaDdRAyxR7iCEM2w1E_FAOZle0RHz1XlTtpp0=.925eabd7-1458-4872-b53e-c2c176b992c6@github.com>
 <yOvPWXkQMCySoZypGlw9ts5dDdiKQMg5gGGammA5Th0=.8b20e0d1-2574-4b96-a4a4-e24376241220@github.com>
Message-ID: <7PZMZzwT-o-BSi24HnmNZ4FcOVsqYYAl0hvxCIQpyHc=.affb0db0-2d5a-4e87-9398-6efa4e7adb8a@github.com>

On Thu, 22 Jan 2026 16:53:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c).
>> 
>> ### New API
>> This PR includes the following API additions:
>> 
>> 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation.
>> 2. The `javafx.beans.property.AttachedProperty` interface.
>> 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property.
>> 
>> The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval.
>> 
>> ### Testing
>> For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules:
>> * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property.
>> *  `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property").
>> * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter.
>> * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime.
>> * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`.
>> * An instance property does not implement `AttachedProperty`.
>> * An instance property has a parameterless property getter.
>> * An attached property implements `AttachedProperty`.
>> * An attached property has a static single-argument property getter that accepts the target object.
>> * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter.
>> * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`.
>> 
>> Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/property-metadata
>  - review changes
>  - ReadOnlyProperty.getDeclaringClass() tests
>  - doc
>  - Enhanced property metadata

I've run into another scenario where having first-class styleable attached properties would make life _much_ easier. I've placed a `TabPane` such that its tabs overlap a `HeaderBar`. In order for the header bar to work correctly, I need to set the `HeaderBar.dragType` property on the tab pane and on its tabs (which are produced by a skin and not easily accessible from JavaFX code).

Actually getting hold of the tabs of a `TabPane` is complicated by the fact that they only exist after the skin has been inflated by CSS; they don't exist after I've typed `var tabPane = new TabPane()` in code. So I need to manually inflate the skin, or defer configuration to the next pulse. After that, I need to use `Node.lookupAll(".tab")` to get the nodes that represent the tabs, or I need to traverse the children of the tab pane until I've found the tabs. Only then can I set the `HeaderBar.dragType` property on those nodes.

If we had styleable attached properties, I could just provide a stylesheet for my tab pane:

.tab-pane {
    -fx-headerbar-dragtype: transparent-subtree;
}

.tab-pane .tab {
    -fx-headerbar-dragtype: none;
}

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3863351123

From mstrauss at openjdk.org  Mon Feb  9 21:48:04 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Feb 2026 21:48:04 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double)
Message-ID: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>

Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.

There are no new tests for this enhancement, since the existing tests already cover all relevant code paths.

-------------

Commit messages:
 - Reduce substring allocations in Color.web(String, double)

Changes: https://git.openjdk.org/jfx/pull/2069/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2069&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377427
  Stats: 223 lines in 1 file changed: 30 ins; 4 del; 189 mod
  Patch: https://git.openjdk.org/jfx/pull/2069.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2069/head:pull/2069

PR: https://git.openjdk.org/jfx/pull/2069

From jvos at openjdk.org  Mon Feb  9 21:49:15 2026
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 9 Feb 2026 21:49:15 GMT
Subject: [jfx25u] RFR: 8371106: [macOS] Min/max window height is incorrect
 for EXTENDED StageStyle
In-Reply-To: <Cy0BF7M3yT3q0WLTdpl_Mz1oQzwJ1FACDfMpMl9W8Ko=.a135b7b4-3591-4c8e-ac21-b1fdadc216de@github.com>
References: <Cy0BF7M3yT3q0WLTdpl_Mz1oQzwJ1FACDfMpMl9W8Ko=.a135b7b4-3591-4c8e-ac21-b1fdadc216de@github.com>
Message-ID: <KhjbSsPev8OWjR_oDKtRc300ed-TxVPIYiScFDnm_kI=.203b38f5-3cf5-4508-8b9b-a5247a3a0e1d@github.com>

On Sat, 20 Dec 2025 02:52:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [013e55b1](https://github.com/openjdk/jfx/commit/013e55b1ba687d212185d00167f375b816faf8c5) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 11 Nov 2025 and was reviewed by Andy Goryachev and Kevin Rushforth.
> 
> Thanks!

@mstr2 this bp looks small and isolated, but apart from that, is there a particular reason why you think this should be in 25u?

-------------

PR Comment: https://git.openjdk.org/jfx25u/pull/41#issuecomment-3871257786

From angorya at openjdk.org  Mon Feb  9 21:49:21 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Feb 2026 21:49:21 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
Message-ID: <fLOhbBJQvbpjH2Q_kJHnciyUHunBVWgHJpdUPXYP0ag=.656a95a9-f535-4688-9954-0ac000e30382@github.com>

On Tue, 25 Nov 2025 18:58:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> This enhancement allows `Stage` to be placed on the screen similar to a popup window, where a user-specified positioning anchors defines a point on the stage that should coincide with a given location on the screen. For this purpose, the following new methods are added to `Stage`:
> 
> 
> public class Stage {
>     public void relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);
>     public void relocate(AnchorPoint screenAnchor, Insets screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
>     public void relocate(Screen, AnchorPoint screenAnchor, Insets screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
> }
> 
> 
> ## AnchorPoint
> `AnchorPoint` is a point that is either specified in absolute coordinates, or relative to the screen or stage:
> 
> var anchor1 = AnchorPoint.proportional(0.5, 0.5); // center of the screen/stage
> var anchor2 = AnchorPoint.absolute(100, 100); // absolute coordinates within screen/stage
> 
> 
> For example, a stage that sits flush with the bottom-right corner of the screen can be shown as follows:
> 
> var screenAnchor = AnchorPoint.proportional(1, 1); // or use the AnchorPoint.BOTTOM_RIGHT constant
> var stageAnchor = AnchorPoint.proportional(1, 1);
> stage.relocate(screenAnchor, stageAnchor);
> stage.show();
> 
> 
> ## AnchorPolicy
> `AnchorPolicy` controls how the anchor may be adjusted when the preferred placement doesn't fit within the screen bounds:
> 
> 
> public enum AnchorPolicy {
>     FIXED,
>     FLIP_HORIZONTAL,
>     FLIP_VERTICAL,
>     AUTO
> }
> 
> 
> * `FIXED`: always use the provided anchor; only adjust the resulting position to fit within the screen.
> * `FLIP_HORIZONTAL`: if the preferred placement violates horizontal constraints, try a horizontally flipped anchor (e.g. top-left to top-right) before falling back to the original anchor.
> * `FLIP_VERTICAL`: likewise for vertical constraints.
> * `AUTO`: automatically choose the most suitable flip:
>    if only horizontal constraints are violated, acts like `FLIP_HORIZONTAL`;
>    if only vertical constraints are violated, acts like `FLIP_VERTICAL`;
>    if both are violated, try a diagonally flipped anchor (both axes) and pick the placement that requires the least adjustment.
> 
> This is useful for popup-like behavior where you have a preferred "opening direction", but want the window to flip to the opposite side of the reference point when there isn?t enough space (e.g. "prefer below, but open above if below doesn?t fit").
> 
> ### PopupWindow support
> The new `PopupWindow.anchorPolicy` property adds the same "flip the anchor when it...

oh no, we let it expire...  I still think it's a useful change.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1986#issuecomment-3872363786

From tsayao at openjdk.org  Mon Feb  9 21:49:28 2026
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 9 Feb 2026 21:49:28 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v72]
In-Reply-To: <FViE6wu_kLXXMlRQlf35SZaB0iP-UzQaMrxDEDTg2WI=.69a005a9-1660-4d74-a136-384fc5c4f0cb@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <FViE6wu_kLXXMlRQlf35SZaB0iP-UzQaMrxDEDTg2WI=.69a005a9-1660-4d74-a136-384fc5c4f0cb@github.com>
Message-ID: <FHCeYNW5uJl-9qNDIuZ4q9Nu5w56vGyZVrIS4te0zTg=.fcb34385-32be-401d-9c6c-bf284cf1becf@github.com>

On Sun, 25 Jan 2026 16:05:56 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:
> 
>  - Review fixes
>  - sync headerbar changes
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	tests/system/src/test/java/test/util/Util.java
>  - Merge branch 'master' into 8354943
>  - Remote assumeTrue for JDK-8364547
>  - Merge branch 'master' into 8354943
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp
>  - Merge branch 'master' into 8354943
>  - Fix copyright header
>  - ... and 78 more: https://git.openjdk.org/jfx/compare/055f827e...01e84817

There is a small issue with sizing I broke on the last change.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3862390870

From duke at openjdk.org  Mon Feb  9 21:49:26 2026
From: duke at openjdk.org (duke)
Date: Mon, 9 Feb 2026 21:49:26 GMT
Subject: Withdrawn: 8372530: Easier placement of windows with positioning
 anchor
In-Reply-To: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
Message-ID: <s18bSWUDUk45gnvH46oH641bF1CP7hXcTQs-UD_qg6s=.7394d1f3-de20-4d2a-995e-be10f11ef1cc@github.com>

On Tue, 25 Nov 2025 18:58:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> This enhancement allows `Stage` to be placed on the screen similar to a popup window, where a user-specified positioning anchors defines a point on the stage that should coincide with a given location on the screen. For this purpose, the following new methods are added to `Stage`:
> 
> 
> public class Stage {
>     public void relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);
>     public void relocate(AnchorPoint screenAnchor, Insets screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
>     public void relocate(Screen, AnchorPoint screenAnchor, Insets screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
> }
> 
> 
> ## AnchorPoint
> `AnchorPoint` is a point that is either specified in absolute coordinates, or relative to the screen or stage:
> 
> var anchor1 = AnchorPoint.proportional(0.5, 0.5); // center of the screen/stage
> var anchor2 = AnchorPoint.absolute(100, 100); // absolute coordinates within screen/stage
> 
> 
> For example, a stage that sits flush with the bottom-right corner of the screen can be shown as follows:
> 
> var screenAnchor = AnchorPoint.proportional(1, 1); // or use the AnchorPoint.BOTTOM_RIGHT constant
> var stageAnchor = AnchorPoint.proportional(1, 1);
> stage.relocate(screenAnchor, stageAnchor);
> stage.show();
> 
> 
> ## AnchorPolicy
> `AnchorPolicy` controls how the anchor may be adjusted when the preferred placement doesn't fit within the screen bounds:
> 
> 
> public enum AnchorPolicy {
>     FIXED,
>     FLIP_HORIZONTAL,
>     FLIP_VERTICAL,
>     AUTO
> }
> 
> 
> * `FIXED`: always use the provided anchor; only adjust the resulting position to fit within the screen.
> * `FLIP_HORIZONTAL`: if the preferred placement violates horizontal constraints, try a horizontally flipped anchor (e.g. top-left to top-right) before falling back to the original anchor.
> * `FLIP_VERTICAL`: likewise for vertical constraints.
> * `AUTO`: automatically choose the most suitable flip:
>    if only horizontal constraints are violated, acts like `FLIP_HORIZONTAL`;
>    if only vertical constraints are violated, acts like `FLIP_VERTICAL`;
>    if both are violated, try a diagonally flipped anchor (both axes) and pick the placement that requires the least adjustment.
> 
> This is useful for popup-like behavior where you have a preferred "opening direction", but want the window to flip to the opposite side of the reference point when there isn?t enough space (e.g. "prefer below, but open above if below doesn?t fit").
> 
> ### PopupWindow support
> The new `PopupWindow.anchorPolicy` property adds the same "flip the anchor when it...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jfx/pull/1986

From crschnick at openjdk.org  Mon Feb  9 21:49:09 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Mon, 9 Feb 2026 21:49:09 GMT
Subject: [jfx26u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
References: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
Message-ID: <8CCkbUGHXLK2MlZYwqliRUFeSzMQbC1jw1E29FECPvM=.8dd30cb7-ab54-497e-9a75-9d6d8a8a344d@github.com>

On Thu, 5 Feb 2026 20:31:21 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.
> 
> Thanks!

In general, how for can backporting go? I would argue this fix has even more relevance for older applications and JavaFX runtimes. If you are running older applications on older hardware, there is a higher change the application uses UNIFIED than now and also a higher chance that the bug occurs on older systems

-------------

PR Comment: https://git.openjdk.org/jfx26u/pull/6#issuecomment-3862646311

From kcr at openjdk.org  Mon Feb  9 21:49:17 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Feb 2026 21:49:17 GMT
Subject: [jfx26u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
References: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
Message-ID: <874Y7eC6ilaPecb8IUuaZpvXqoB04NsTbCByD5zf8Ec=.b6d3f50a-39e6-4c33-9cbd-370a84b4ee76@github.com>

On Thu, 5 Feb 2026 20:31:21 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.
> 
> Thanks!

Approved. Since this is a clean backport, it only needs Maintainer approval. Review is optional (and not needed in this case). Once the approval is recorded, you may integrate it.

-------------

PR Comment: https://git.openjdk.org/jfx26u/pull/6#issuecomment-3862728546

From crschnick at openjdk.org  Mon Feb  9 21:49:52 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Mon, 9 Feb 2026 21:49:52 GMT
Subject: [jfx17u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
Message-ID: <nq-l6Jb9CHPzwc3TRij9Wh1_2C9ygfJelBdEwfHSf34=.fd03b75e-199b-4fd3-bd8b-f2718c2309b9@github.com>

Hi all,

This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 28bde153cbf960e1b8d74d258ba351a5305f124b

Changes: https://git.openjdk.org/jfx17u/pull/251/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=251&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8154847
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/251.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/251/head:pull/251

PR: https://git.openjdk.org/jfx17u/pull/251

From jvos at openjdk.org  Mon Feb  9 21:49:36 2026
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 9 Feb 2026 21:49:36 GMT
Subject: [jfx17u] RFR: 8368572: Update WebKit to 623.1
Message-ID: <23XCvs988Ua1RFZv7RV1jQxGYu6V3ePzI42MUiAeGJI=.a35933d5-225f-4bc3-815c-4f6975967be5@github.com>

Hi all,

This pull request contains a backport of commit 422d3a95 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos.

Thanks!

-------------

Commit messages:
 - Backport 422d3a954d531c9cca32b1401b5937b05b1b07fa

Changes: https://git.openjdk.org/jfx17u/pull/253/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8368572
  Stats: 505662 lines in 8991 files changed: 253929 ins; 188948 del; 62785 mod
  Patch: https://git.openjdk.org/jfx17u/pull/253.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/253/head:pull/253

PR: https://git.openjdk.org/jfx17u/pull/253

From kcr at openjdk.org  Mon Feb  9 21:49:22 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Feb 2026 21:49:22 GMT
Subject: [jfx26u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <8CCkbUGHXLK2MlZYwqliRUFeSzMQbC1jw1E29FECPvM=.8dd30cb7-ab54-497e-9a75-9d6d8a8a344d@github.com>
References: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
 <8CCkbUGHXLK2MlZYwqliRUFeSzMQbC1jw1E29FECPvM=.8dd30cb7-ab54-497e-9a75-9d6d8a8a344d@github.com>
Message-ID: <2Wd5TuCPcnGbVF_6c1OoX6uk37RqmIHXec8lOXDNzD8=.aca9f5b3-36f8-4b7e-9e3f-aa54db2ff114@github.com>

On Fri, 6 Feb 2026 21:32:06 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> In general, how for can backporting go? I would argue this fix has even more relevance for older applications and JavaFX runtimes. If you are running older applications on older hardware, there is a higher change the application uses UNIFIED than now and also a higher chance that the bug occurs on older systems

That would be up to the maintainer of each code line. Gluon maintains jfx25u and jfx17u, so @johanvos is the approver. Feel free to make the request and he will decide.

There is currently no maintainer for the the OpenJFX 11u or 8u code lines. The jfx11u repo has been archived and we never created a jfx8u GitHub repo (that code line had no maintainer when we moved from Mercurial to git).

-------------

PR Comment: https://git.openjdk.org/jfx26u/pull/6#issuecomment-3862742051

From jvos at openjdk.org  Mon Feb  9 21:50:00 2026
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 9 Feb 2026 21:50:00 GMT
Subject: [jfx17u] Integrated: 8370235: WebKit build fails on Windows 32-bit and
 Linux 32-bit after JDK-8367578
Message-ID: <PnxS3VSkw3t8DhPjhF3UK-qb_THCpzy4dQMWt8Nj7kU=.261d325b-cffb-4593-8286-0dfdf6e7e408@github.com>

Hi all,

This pull request contains a backport of commit ef387fc2 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 31 Oct 2025 and was reviewed by Kevin Rushforth and Hima Bindu Meda.

Thanks!

-------------

Commit messages:
 - Backport ef387fc2b0899a2a32f79e3b8454dce69f094a03

Changes: https://git.openjdk.org/jfx17u/pull/252/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370235
  Stats: 9 lines in 1 file changed: 8 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/252.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/252/head:pull/252

PR: https://git.openjdk.org/jfx17u/pull/252

From duke at openjdk.org  Mon Feb  9 21:49:27 2026
From: duke at openjdk.org (duke)
Date: Mon, 9 Feb 2026 21:49:27 GMT
Subject: [jfx26u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
References: <pqGR8bG87fhOZS6rWgdSMcQDWfMwy2Up5M77dT390U0=.08706b06-4fdb-4abc-b64f-9fdbb945de82@github.com>
Message-ID: <uXmd1JNQx73T17bGwStCkab_wDfaUAvuNQtSnPqbRoQ=.389313f5-122b-4aef-98fc-240ebae9083f@github.com>

On Thu, 5 Feb 2026 20:31:21 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.
> 
> Thanks!

@crschnick 
Your change (at version 1d0c86a1d4cb731b66dfe3390f61aca113bc9ffe) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jfx26u/pull/6#issuecomment-3870738020

From kcr at openjdk.org  Mon Feb  9 21:50:25 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Feb 2026 21:50:25 GMT
Subject: [jfx26u] RFR: Merge jfx:jfx26 [v2]
In-Reply-To: <5P4QExQ5TIB-gICuffZ8XOuXpMNRgkhy1KlNRepCNEY=.f4c8bd03-3a67-4817-a5e6-fd2cb980b144@github.com>
References: <5P4QExQ5TIB-gICuffZ8XOuXpMNRgkhy1KlNRepCNEY=.f4c8bd03-3a67-4817-a5e6-fd2cb980b144@github.com>
Message-ID: <P3WHtsJtRzbrfIclAOvP9W21gaOjBAebelOG235pyTg=.070fdbc2-bff3-4e83-a996-65f3e0c871c3@github.com>

> Clean merge from `jfx:jfx26` to `jfx26u:master`.

Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge
 - 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative
   
   Backport-of: 0f091426eb44e7a11bf6c8d15a2359d8d7760da8
 - 8375225: WebIObserverTest fails with WebKit 623.1
   
   Reviewed-by: kcr
   Backport-of: 055f827e470e8f28a0d408fb8550ae759e068984
 - 8368572: Update WebKit to 623.1
   
   Reviewed-by: kcr
   Backport-of: 422d3a954d531c9cca32b1401b5937b05b1b07fa
 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos
   
   Reviewed-by: jvos
   Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6
 - 8376022: Change JavaFX release version to 26.0.1 in jfx26u
   
   Reviewed-by: jvos

-------------

Changes:
  - all: https://git.openjdk.org/jfx26u/pull/7/files
  - new: https://git.openjdk.org/jfx26u/pull/7/files/14c7f576..14c7f576

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jfx26u&pr=7&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx26u/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/7/head:pull/7

PR: https://git.openjdk.org/jfx26u/pull/7

From jvos at openjdk.org  Mon Feb  9 21:50:04 2026
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 9 Feb 2026 21:50:04 GMT
Subject: [jfx17u] Integrated: 8370235: WebKit build fails on Windows 32-bit and
 Linux 32-bit after JDK-8367578
In-Reply-To: <PnxS3VSkw3t8DhPjhF3UK-qb_THCpzy4dQMWt8Nj7kU=.261d325b-cffb-4593-8286-0dfdf6e7e408@github.com>
References: <PnxS3VSkw3t8DhPjhF3UK-qb_THCpzy4dQMWt8Nj7kU=.261d325b-cffb-4593-8286-0dfdf6e7e408@github.com>
Message-ID: <4uxpC7NvrhNBGPCJM0ysLvyowd2_ozD73XAUdMjxUw4=.0769c381-e8ba-4edc-8d05-30f5e858b339@github.com>

On Mon, 9 Feb 2026 15:37:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit ef387fc2 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 31 Oct 2025 and was reviewed by Kevin Rushforth and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 17e2dd81
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/17e2dd8156abf3aa4c869bf73fe0aee95ceecbe6
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

8370235: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578

Backport-of: ef387fc2b0899a2a32f79e3b8454dce69f094a03

-------------

PR: https://git.openjdk.org/jfx17u/pull/252

From kcr at openjdk.org  Mon Feb  9 21:50:34 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Feb 2026 21:50:34 GMT
Subject: [jfx26u] Integrated: Merge jfx:jfx26
In-Reply-To: <5P4QExQ5TIB-gICuffZ8XOuXpMNRgkhy1KlNRepCNEY=.f4c8bd03-3a67-4817-a5e6-fd2cb980b144@github.com>
References: <5P4QExQ5TIB-gICuffZ8XOuXpMNRgkhy1KlNRepCNEY=.f4c8bd03-3a67-4817-a5e6-fd2cb980b144@github.com>
Message-ID: <ba4RPlx8t-DAi0UCHp7z0eKKYvdbRWro7lIYO2DSVSY=.9ba1dee7-5bca-4fa8-9a3e-f78155597bce@github.com>

On Fri, 6 Feb 2026 14:37:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge from `jfx:jfx26` to `jfx26u:master`.

This pull request has now been integrated.

Changeset: c3abe59e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx26u/commit/c3abe59ed9e41117e40ae7fc07c968afa5f416e2
Stats:     1348 lines in 14 files changed: 871 ins; 349 del; 128 mod

Merge

-------------

PR: https://git.openjdk.org/jfx26u/pull/7

From crschnick at openjdk.org  Mon Feb  9 21:50:33 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Mon, 9 Feb 2026 21:50:33 GMT
Subject: [jfx25u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
Message-ID: <a_-vUxg2UhGXP3vSHOBBFslXWKCY9V5phnOCORrJd_M=.8b57b1f2-fbaf-4bb8-8e4f-7ee74a37dd6c@github.com>

Hi all,

This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 28bde153cbf960e1b8d74d258ba351a5305f124b

Changes: https://git.openjdk.org/jfx25u/pull/47/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=47&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8154847
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx25u/pull/47.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/47/head:pull/47

PR: https://git.openjdk.org/jfx25u/pull/47

From jvos at openjdk.org  Mon Feb  9 21:50:36 2026
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 9 Feb 2026 21:50:36 GMT
Subject: [jfx25u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <a_-vUxg2UhGXP3vSHOBBFslXWKCY9V5phnOCORrJd_M=.8b57b1f2-fbaf-4bb8-8e4f-7ee74a37dd6c@github.com>
References: <a_-vUxg2UhGXP3vSHOBBFslXWKCY9V5phnOCORrJd_M=.8b57b1f2-fbaf-4bb8-8e4f-7ee74a37dd6c@github.com>
Message-ID: <0aw_-bg-u5EBsFkUpRL7aHkAaIKVD7zIXQz8Sut-AQQ=.4e6bc942-0143-4ecb-b70e-f6d1fffc848e@github.com>

On Mon, 9 Feb 2026 10:14:10 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.
> 
> Thanks!

Fixing an old standing issue with 1 line sounds good :)
At first sight, it seems unlikely that issues in this backport will only show up in the backport. So I expect that potential problems will be visible in HEAD as well. If that is true, then it might be safer to target this to 25.0.4, which gives us 3 months testing before we bake it into an LTS. 
What do you think?

-------------

PR Comment: https://git.openjdk.org/jfx25u/pull/47#issuecomment-3871273971

From mstrauss at openjdk.org  Mon Feb  9 21:50:09 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Feb 2026 21:50:09 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip [v2]
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <Q3g79juKKPDap-69eK0sxSs6dbAv7mJuOHGUIz42wCo=.2acfc2aa-dd0b-4139-87e8-16a6b41f7c1d@github.com>

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  increase DELTA to 150

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/2066/files
  - new: https://git.openjdk.org/jfx/pull/2066/files/a46fd46e..8fe46bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=2066&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2066&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/2066.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2066/head:pull/2066

PR: https://git.openjdk.org/jfx/pull/2066

From crschnick at openjdk.org  Mon Feb  9 21:50:38 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Mon, 9 Feb 2026 21:50:38 GMT
Subject: [jfx25u] RFR: 8154847: Rendering is incorrect or not visible with
 StageStyle.UNIFIED on some graphics cards
In-Reply-To: <a_-vUxg2UhGXP3vSHOBBFslXWKCY9V5phnOCORrJd_M=.8b57b1f2-fbaf-4bb8-8e4f-7ee74a37dd6c@github.com>
References: <a_-vUxg2UhGXP3vSHOBBFslXWKCY9V5phnOCORrJd_M=.8b57b1f2-fbaf-4bb8-8e4f-7ee74a37dd6c@github.com>
Message-ID: <sfsWcpNHES4qeS07CKWtGn8LwrWjNRIl0pf1gRKWXeM=.418c9ffc-3505-4dad-8ce0-8e396a75b2c1@github.com>

On Mon, 9 Feb 2026 10:14:10 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [28bde153](https://github.com/openjdk/jfx/commit/28bde153cbf960e1b8d74d258ba351a5305f124b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Christopher Schnick on 5 Feb 2026 and was reviewed by Lukasz Kostyra and Kevin Rushforth.
> 
> Thanks!

Yeah that is fine, that issue has been open long enough for 3 months to not make a huge difference

-------------

PR Comment: https://git.openjdk.org/jfx25u/pull/47#issuecomment-3871586887

From angorya at openjdk.org  Mon Feb  9 21:50:13 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Feb 2026 21:50:13 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip [v2]
In-Reply-To: <Q3g79juKKPDap-69eK0sxSs6dbAv7mJuOHGUIz42wCo=.2acfc2aa-dd0b-4139-87e8-16a6b41f7c1d@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
 <Q3g79juKKPDap-69eK0sxSs6dbAv7mJuOHGUIz42wCo=.2acfc2aa-dd0b-4139-87e8-16a6b41f7c1d@github.com>
Message-ID: <9B-IlQGmmqGhfYUAPWzg4YeQ4fDdkDd7aQGH-qQH7c4=.0c620afc-7f7c-4619-9a4f-75aba882da05@github.com>

On Sat, 7 Feb 2026 01:36:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
>> 
>> 
>> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>>     java.lang.AssertionError
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
>> 
>> 
>> or
>> 
>> 
>> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-interna...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   increase DELTA to 150

Marked as reviewed by angorya (Reviewer).

thank you for making this change!

-------------

PR Review: https://git.openjdk.org/jfx/pull/2066#pullrequestreview-3763729883
Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2066#pullrequestreview-3765067307

From mhanl at openjdk.org  Mon Feb  9 21:50:18 2026
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 9 Feb 2026 21:50:18 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip [v2]
In-Reply-To: <Q3g79juKKPDap-69eK0sxSs6dbAv7mJuOHGUIz42wCo=.2acfc2aa-dd0b-4139-87e8-16a6b41f7c1d@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
 <Q3g79juKKPDap-69eK0sxSs6dbAv7mJuOHGUIz42wCo=.2acfc2aa-dd0b-4139-87e8-16a6b41f7c1d@github.com>
Message-ID: <XN1Jo7uZORjObMThntxOXN13kv1Wbr4AaUrVKoL2nZA=.c5d4036e-9d97-49bc-bc83-5f31fc68e7b4@github.com>

On Sat, 7 Feb 2026 01:36:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
>> 
>> 
>> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>>     java.lang.AssertionError
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
>> 
>> 
>> or
>> 
>> 
>> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-interna...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   increase DELTA to 150

Since I wrote the test, I can confirm this fix looks good. 

Back then, it worked for me (as it did until recently), so I did not consider modifying the stylesheet on another thread is a problem. But makes sense.

> TooltipTest > testShowDelayCssShowTooltipTwice() FAILED
    org.opentest4j.AssertionFailedError: 204 <= 200 ==> expected: <true> but was: <false>

I think we had this kind of problem at least once in the past.
It should be safe to increase the delta a bit more, since we are far away from the default timing.
(That was the problem back then. You set a show delay of 100ms, but it still used the default 1000ms. So the delta should not be that big as otherwise we will not catch this regression. But we are far away from that).

Marked as reviewed by mhanl (Committer).

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/2066#pullrequestreview-3763912600
PR Review: https://git.openjdk.org/jfx/pull/2066#pullrequestreview-3765069085

From angorya at openjdk.org  Mon Feb  9 21:50:26 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Feb 2026 21:50:26 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <eaqwhN6TBM7EIa13dE_gqOtIR40LjbTiuP_ry-WN0kw=.22266d58-1add-408b-8509-43a43235f33c@github.com>

On Fri, 6 Feb 2026 02:33:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

I would rather increase the delay as a part of this fix.
Otherwise the fix looks good.
macOS 26.2 on M1 silicon.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2066#issuecomment-3861061397

From kcr at openjdk.org  Mon Feb  9 21:50:30 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 9 Feb 2026 21:50:30 GMT
Subject: RFR: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <EcoUHoN5z4sVl0z5mLc0NinBfX_L9vAWp9AVstBdRDg=.01e71fc6-8aba-4fd9-b377-d439e2bf1970@github.com>

On Fri, 6 Feb 2026 02:33:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

@mstr2 Both Lukazs and Andy have made the case for also changing the DELTA value as part of this fix to eliminate another source of intermittent failures in this test. The PR is already approved, so it's up to you. If you do want to update it, maybe increasing the delta from 100 to either 150 or 200 might be reasonable. Otherwise, we'll file a follow-on bug so we'll have something tracking it in case we ever see it in the wild.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2066#issuecomment-3861976950

From mstrauss at openjdk.org  Mon Feb  9 21:50:33 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 9 Feb 2026 21:50:33 GMT
Subject: Integrated: 8377189: Intermittent failure in
 TooltipTest.testCssStylesheetChangeTooltip
In-Reply-To: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
References: <5lNyZuDcBUx3xh_2fQ9YYsDWbdSOQKktOKjYc_W0JL8=.ad45bad3-ddc2-4685-b6c3-df280281f8a7@github.com>
Message-ID: <-irZz1gS100q3lBn7rqumCLcUCG5eS99YlueYsXUTT8=.6f57959a-3123-4d33-a726-81eeffce6ac5@github.com>

On Fri, 6 Feb 2026 02:33:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `test.robot.javafx.scene.TooltipTest` modifies the scene graph on a test worker thread, which can corrupt the scene graph and leads to test failures such as:
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() FAILED
>     java.lang.AssertionError
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:144)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCss(Node.java:9996)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Node.reapplyCSS(Node.java:9959)
>         at [javafx.graphics at 27-ea](mailto:javafx.graphics at 27-ea)/javafx.scene.Scene$10.onChanged(Scene.java:1682)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:44)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>         at [javafx.base at 27-ea](mailto:javafx.base at 27-ea)/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> 
> 
> or
> 
> 
> TooltipTest > testCssStylesheetChangeTooltip() STANDARD_ERROR
>     Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "java.util.List.clear()" because "this.selectors" is null
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:148)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:490)
>         at [javafx.graphics at 27-internal](mailto:javafx.graphics at 27-internal)/javafx.scene.CssStyleHelper.createStyleHelper(CssSt...

This pull request has now been integrated.

Changeset: b5417280
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b5417280874a0ef57e60bd08cd156ce290c2336d
Stats:     116 lines in 1 file changed: 56 ins; 26 del; 34 mod

8377189: Intermittent failure in TooltipTest.testCssStylesheetChangeTooltip

Reviewed-by: angorya, mhanl, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/2066

From jpereda at openjdk.org  Mon Feb  9 22:56:55 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 9 Feb 2026 22:56:55 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v2]
In-Reply-To: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
Message-ID: <wg36y77IU1-XiW-hn-dS4O4WpyOnjqfXQwOFHP8pT7Y=.2541e7ca-0920-4858-8701-840cdad82446@github.com>

> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary conversions

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/2064/files
  - new: https://git.openjdk.org/jfx/pull/2064/files/60e59f9f..4c3dc446

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/2064.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2064/head:pull/2064

PR: https://git.openjdk.org/jfx/pull/2064

From angorya at openjdk.org  Mon Feb  9 23:08:00 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 9 Feb 2026 23:08:00 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double)
In-Reply-To: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
Message-ID: <TfQt8cx4VVAmh51l_a3gE59kl1Z9xupHVdiB_0wLxpY=.9a10f360-09ca-4e35-86fb-02ac75cc2c16@github.com>

On Sun, 8 Feb 2026 04:24:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.
> 
> There are no new tests for this enhancement, since the existing tests already cover all relevant code paths.

+1

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3874340681

From jpereda at openjdk.org  Mon Feb  9 23:11:34 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 9 Feb 2026 23:11:34 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v3]
In-Reply-To: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
Message-ID: <QPE-ypt9ZqxF-cjdJJM8WRMslP8ReX1m4B9IdW425mg=.ff426769-0b4f-4f4a-a50f-07bf2e6f2935@github.com>

> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Unify defines in PrismES2Defs header

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/2064/files
  - new: https://git.openjdk.org/jfx/pull/2064/files/4c3dc446..a14d7938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=01-02

  Stats: 20 lines in 3 files changed: 8 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/2064.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2064/head:pull/2064

PR: https://git.openjdk.org/jfx/pull/2064

From jpereda at openjdk.org  Mon Feb  9 23:11:37 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 9 Feb 2026 23:11:37 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v3]
In-Reply-To: <3vv1Ny6Aa4fOtM-9HYg_UBdH9hiwwTRqkpFT8xqV9wA=.81b942e9-135f-427b-b010-237b1f528859@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
 <3vv1Ny6Aa4fOtM-9HYg_UBdH9hiwwTRqkpFT8xqV9wA=.81b942e9-135f-427b-b010-237b1f528859@github.com>
Message-ID: <2owrFS2cqs52sDzf1nqMr1_KSfqDPJZjHL67k7e6Cyc=.a9fd9e05-bc50-462f-8c9f-e0286cd71773@github.com>

On Fri, 6 Feb 2026 15:04:02 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unify defines in PrismES2Defs header
>
> modules/javafx.graphics/src/main/native-prism-es2/ios/ios-window-system.h line 31:
> 
>> 29: #import <jni.h>
>> 30: 
>> 31: #ifndef jlong_to_ptr
> 
> Probably better to completely remove these definitions here.

Done, I've moved them to `PrismES2Defs.h`

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2064#discussion_r2784979433

From angorya at openjdk.org  Tue Feb 10 00:19:36 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 10 Feb 2026 00:19:36 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double)
In-Reply-To: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
Message-ID: <8JH4vUASJI73tlyaOs9ubBhAo_6jjMqh_QXiSW7AEDo=.b9435524-29c9-4856-9ebf-91ae62594ff2@github.com>

On Sun, 8 Feb 2026 04:24:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.
> 
> There are no new tests for this enhancement, since the existing tests already cover all relevant code paths.

modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 405:

> 403:         if (colorString.regionMatches(true, 0, "#", 0, 1)) {
> 404:             offset = 1;
> 405:         } else if (colorString.regionMatches(true, 0, "0x", 0, 2)) {

interestingly, while the code (both old and new) ignores case, the javadoc says nothing about case sensitivity.

modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 517:

> 515:         int limit = end;
> 516: 
> 517:         while (start < limit && Character.isWhitespace(color.charAt(start))) {

I think this change is not equivalent: the `trim()` function (used before) removes leading and trailing "spaces" which are defined as `space is defined as any character whose codepoint is less than or equal to 'U+0020' (the space character).`

`Character.isWhitespace()` is different:


hex| trim| isWhitespace
0x00 W -
0x01 W -
0x02 W -
0x03 W -
0x04 W -
0x05 W -
0x06 W -
0x07 W -
0x08 W -
0x09 W W
0x0a W W
0x0b W W
0x0c W W
0x0d W W
0x0e W -
0x0f W -
0x10 W -
0x11 W -
0x12 W -
0x13 W -
0x14 W -
0x15 W -
0x16 W -
0x17 W -
0x18 W -
0x19 W -
0x1a W -
0x1b W -
0x1c W W
0x1d W W
0x1e W W
0x1f W W
0x20 W W


see https://github.com/andy-goryachev-oracle/Test/blob/main/test/goryachev/research/TestWhitespace.java

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2785029304
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2785075804

From mstrauss at openjdk.org  Tue Feb 10 00:31:48 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 00:31:48 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double)
In-Reply-To: <8JH4vUASJI73tlyaOs9ubBhAo_6jjMqh_QXiSW7AEDo=.b9435524-29c9-4856-9ebf-91ae62594ff2@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <8JH4vUASJI73tlyaOs9ubBhAo_6jjMqh_QXiSW7AEDo=.b9435524-29c9-4856-9ebf-91ae62594ff2@github.com>
Message-ID: <YMDKddyWxa-swJdOJs9q-kEHn7lwAuABnmOkH33ESLc=.c1fba6a7-165d-4ad5-9354-1e2bb747a85e@github.com>

On Mon, 9 Feb 2026 23:43:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.
>> 
>> There are no new tests for this enhancement, since the existing tests already cover all relevant code paths.
>
> modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 517:
> 
>> 515:         int limit = end;
>> 516: 
>> 517:         while (start < limit && Character.isWhitespace(color.charAt(start))) {
> 
> I think this change is not equivalent: the `trim()` function (used before) removes leading and trailing "spaces" which are defined as `space is defined as any character whose codepoint is less than or equal to 'U+0020' (the space character).`
> 
> `Character.isWhitespace()` is different:
> 
> 
> hex| trim| isWhitespace
> 0x00 W -
> 0x01 W -
> 0x02 W -
> 0x03 W -
> 0x04 W -
> 0x05 W -
> 0x06 W -
> 0x07 W -
> 0x08 W -
> 0x09 W W
> 0x0a W W
> 0x0b W W
> 0x0c W W
> 0x0d W W
> 0x0e W -
> 0x0f W -
> 0x10 W -
> 0x11 W -
> 0x12 W -
> 0x13 W -
> 0x14 W -
> 0x15 W -
> 0x16 W -
> 0x17 W -
> 0x18 W -
> 0x19 W -
> 0x1a W -
> 0x1b W -
> 0x1c W W
> 0x1d W W
> 0x1e W W
> 0x1f W W
> 0x20 W W
> 
> 
> see https://github.com/andy-goryachev-oracle/Test/blob/main/test/goryachev/research/TestWhitespace.java

While that's true, I think it is irrelevant. `Color.web()` is not specified to just skip over non-whitespace control characters inside of a color function, and it is not prudent to assume that a string parsing function would silently skip over non-whitespace control characters by default.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2785195163

From mstrauss at openjdk.org  Tue Feb 10 02:02:32 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 02:02:32 GMT
Subject: RFR: 8370902: RichTextArea: migrate to new text APIs
In-Reply-To: <DTPO-UP8FOCR9RLOpSMqlfnkayONMGQgA0GNxnTK-Dc=.b83df6df-d752-4f9b-a525-bc0a21aa01ed@github.com>
References: <DTPO-UP8FOCR9RLOpSMqlfnkayONMGQgA0GNxnTK-Dc=.b83df6df-d752-4f9b-a525-bc0a21aa01ed@github.com>
Message-ID: <iZ-XakorLFXAUUWK9zbFDMekv83tdA6xLVQEmcXxW6I=.4710ffb6-3b08-4971-a0cc-f5abb7358bd5@github.com>

On Wed, 17 Dec 2025 20:38:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Updates the `RichTextArea` code to use the new text layout APIs delivered in https://bugs.openjdk.org/browse/JDK-8341670
> 
> Also:
> 
> - updates the "demo" model in the `RichTextAreaDemoApp` to show underline/strikethrough in the presence of `TextFlow` borders

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/2012#pullrequestreview-3776316923

From mstrauss at openjdk.org  Tue Feb 10 02:06:58 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 02:06:58 GMT
Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse
 button is none [v4]
In-Reply-To: <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com>
References: <dADoFJEJtoFxB_H0lsXfbPTWSnATO2ZhMxytsYc81tc=.ec3b88c9-79fe-4a61-a14d-5f160b822d74@github.com>
 <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com>
Message-ID: <Xr-iRSy03DkB4-oFRwoQYAmTyUME7eo921zVOyvItp8=.3f29b2f2-11ff-43e3-84f3-64b0431ab957@github.com>

On Tue, 13 Jan 2026 18:04:40 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

>> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point
>
> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/2034#pullrequestreview-3776324960

From mstrauss at openjdk.org  Tue Feb 10 02:28:29 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 02:28:29 GMT
Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist
 in the codebase [v5]
In-Reply-To: <KbN9xV3UOZ44D0skAQGlpZT5lXr_MixX-sQxW_xrck4=.d62bee28-9394-4cfd-ac90-96b4449942b1@github.com>
References: <aBDEqZrtBShCwYtvoGhfc7GShGt-Nba0F3azvcUqaXw=.61f43f80-2708-459b-b2ab-ad0253f24221@github.com>
 <UOab_fnia-DmqBXebeaxO3muhSbSVIkW2MJV-WyLxWE=.c99e2b71-bcea-4f22-8a3a-bdda8b1493f9@github.com>
 <Z3igwatNNSVE5-iDSZoyQNE2oVlvmRNfPzrH6Sx0vFg=.e5b07ab2-9c16-4e38-9200-1b9b4b87cfa1@github.com>
 <DSuAj4eUGgdAfrE3uFncoG0CBNlQchtsUC8q5gxK5VM=.f706fe8c-7fad-4feb-b5ca-c5b899f29cfd@github.com>
 <hXJzgOnrfLUtEPjffaPQ5V3NgJDG1FOZwGywohVdvNQ=.cbfbd119-2227-4210-84e8-90044bf8a8c3@github.com>
 <O5bn2oPVnFzsI-hm-CR9WltB5bEekQeYDKTC1Xh1mxE=.2a076fde-c564-47cc-a0c1-eb090debb9b0@github.com>
 <9O0PjqkxndeuLXsrXz9WIYlk3I32MgaEuhQ6mRMbGbU=.e865939f-3ad1-4e23-98af-ac8f382e9f2f@github.com>
 <d6a5MPXgukC4MZNmo9Axo0akBcjXFiStfUTdDFI3OIo=.f0d2f4f2-df55-44c2-87c3-8ced588c5238@github.com>
 <KbN9xV3UOZ44D0skAQGlpZT5lXr_MixX-sQxW_xrck4=.d62bee28-9394-4cfd-ac90-96b4449942b1@github.com>
Message-ID: <4uOGCU1JFPCao1aNLJUIb69Lg749l9GjpJLt4WgB4CU=.1d704d1e-95a8-4e61-a54f-407a1bd4ef43@github.com>

On Thu, 15 Jan 2026 22:27:03 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

>> my point this is not an equivalent change, because it changes the behavior.  Before the change, a null will be returned, after this change - a non-null value of some other class.
>> 
>> we don't want to change the scope of this PR, right?
>
> I added a test that should clarify the handling for mismatched types. The test passes both in the old and new implementation to show that the behaviour is the same and in both cases, null is never returned on mismatched types

This is not an equivalent change: Before the change, a `ClassCastException` could have been thrown from `observable.getValue()`, which is then swallowed and logged. After the change, the exception bubbles up to the caller.

However, the old code doesn't make any sense at all, because it doesn't do what the original author intended it to do. Christopher is correct: the generic type `T` doesn't have a lower bound, so it is erased to `Object` in the method descriptor: `()[Ljava/lang/Object;`. The statement `return (T)observable.getValue();` can therefore never throw a `ClassCastException` at runtime, because any reference type is convertible to `Object`. The try-catch block is dead code at best, and actually _hides_ an unrelated `ClassCastException` that was thrown from `observable.getValue()`; it confusingly logs that the "select-binding has wrong type", which is not what has happened.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2785455568

From mstrauss at openjdk.org  Tue Feb 10 02:31:28 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 02:31:28 GMT
Subject: RFR: 8375444: MenuButton - textTruncated Property is always false
 [v4]
In-Reply-To: <ZXCy8GwSabwBi-GfH2LAV-OyjGqc5j_sBLR8Fys4-bc=.14fd1482-c88e-4b07-92b5-b03ad79a7e66@github.com>
References: <pv-Gpauv1_KlSbjPgI6TRzlYaiFJkYH4tHzKhQmL5zc=.40cc952d-0d8c-407a-9f7e-6a3a318b6822@github.com>
 <ZXCy8GwSabwBi-GfH2LAV-OyjGqc5j_sBLR8Fys4-bc=.14fd1482-c88e-4b07-92b5-b03ad79a7e66@github.com>
Message-ID: <G_lBWBOduLS2bwKSfdDZ6Hp71hUZdoEiuzEn37xdstQ=.aca392ca-06f5-426a-b15b-67f92f2f4a51@github.com>

On Tue, 20 Jan 2026 08:41:45 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long.
>> 
>> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property.
>> I've also extended the existing tests for the truncated property.
>> 
>> It would be great, to get some feedback on how i fixes the bug.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8375444
>   Removed commented out print statements.
>   Fixed import order.

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/2040#pullrequestreview-3776384593

From crschnick at xpipe.io  Tue Feb 10 03:53:41 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 10 Feb 2026 04:53:41 +0100
Subject: backport requests
In-Reply-To: <CABxFH2FO_hZXwX1=2pDtgrJ-AnLwZfJc22YfTttUEsC33iTHUQ@mail.gmail.com>
References: <CABxFH2FO_hZXwX1=2pDtgrJ-AnLwZfJc22YfTttUEsC33iTHUQ@mail.gmail.com>
Message-ID: <90335d30-cc09-4d95-be8e-9ffbe6ae8363@xpipe.io>

About 4., it would be a nice feature if skara could automatically handle 
delayed backports, e.g. could automatically remind you after some time 
that the backport can now be done after it has been available in HEAD 
for some time.

On 09/02/2026 14:26, Johan Vos wrote:
> Hi,
>
> TLDR: When doing a backport, it helps if you give as much information 
> as possible on why you believe such a backport is important.
>
> I see an increasing number of backport requests for javafx 17, 21 and 
> 25. It's really great to see developers wanting to improve older 
> versions of JavaFX.
> I want to apologize for not approving all those requests, but let me 
> explain the reasons, and let's see how we can move forward.
>
> First of all, integrating a backport is expensive. The resulting code 
> and builds are available for free,?so there is a cost but no income 
> for this (simply said, it's sponsored by Gluon)
> We run all tests on our own hardware, and we need to maintain this 
> hardware. Moreover, the different OS versions and build tools need to 
> be maintained as well, and they are often different between LTS 
> versions. That creates a complex situation, since we don't want to 
> have 3 dedicated hardware sets for 3 LTS releases. Head-releases are 
> relatively easy, but LTS releases require lots of 
> administration/infrastructure.
>
> As most of you know, a full JavaFX build takes some time. Especially 
> building webkit (and especially on Windows) is a resource-intensive 
> process of > 1 hour. Running all tests takes even more time.
> For LTS releases, it is extremely important not to break something, as 
> organisations rely on the assumptions that LTS releases are rock 
> stable. Every change, no matter how small, is a candidate for breaking 
> something, hence every change needs to go through rigorous 
> multi-platform testing.
>
> So what backports are currently being accepted?
>
> 1. Security fixes.
> This is the single most important category. When vulnerabilities are 
> disclosed, there needs to be a release of JavaFX LTS versions where 
> those vulnerabilities are addressed. That means the security fixes 
> that go in e.g. 26.0.1 should be backported to 17/21/25.
>
> 2. Fixes in third party components (e.g. webkit, xslt)
> Security issues are often related to third party components, and in 
> order to apply the security fixes, it help staying on the latest release.
>
> 3. P1/P2 issues.
> Clearly, we don't want to have critical bugs in the release.
>
> 4. Simple, well documented, small fixes that are already applied and 
> tested in HEAD and have been in a release, and that address issues 
> affecting a large user base and that have no dependencies on later 
> Java versions (e.g. JavaFX requires JDK 11, so no switch expressions etc)
>
> Skara is extremely helpful when doing backports. If a backport can be 
> applied clean to an LTS repository, Skara will tell you, and the 
> process becomes easier. Off course, everything still needs to be tested.
>
> When doing a backport, it helps if you give as much information as 
> possible on why you believe such a backport is important,?and why you 
> think the?risk is low. In case I believe the benefits of a particular 
> backport request do not outweigh the risk, I will reply in the PR for 
> that backport and we can discuss further.
>
> - Johan
>

From jvos at openjdk.org  Tue Feb 10 09:07:18 2026
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 10 Feb 2026 09:07:18 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v3]
In-Reply-To: <QPE-ypt9ZqxF-cjdJJM8WRMslP8ReX1m4B9IdW425mg=.ff426769-0b4f-4f4a-a50f-07bf2e6f2935@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
 <QPE-ypt9ZqxF-cjdJJM8WRMslP8ReX1m4B9IdW425mg=.ff426769-0b4f-4f4a-a50f-07bf2e6f2935@github.com>
Message-ID: <tHo822N39w7uD7BkKhy7-vBCbzRCPLc-VTq5RDZnC9s=.42e152f5-002d-4351-85b9-51d5ba8304ad@github.com>

On Mon, 9 Feb 2026 23:11:34 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unify defines in PrismES2Defs header

modules/javafx.graphics/src/main/native-prism-es2/PrismES2Defs.h line 72:

> 70: #include <TargetConditionals.h>
> 71: 
> 72: #define jlong_to_ptr(value) (intptr_t)(value)

I believe we should be able to use those on IOS as well?
In any case, it is better to case to a pointer instead of to a long

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2064#discussion_r2786705195

From jpereda at openjdk.org  Tue Feb 10 09:40:42 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 10 Feb 2026 09:40:42 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v4]
In-Reply-To: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
Message-ID: <oiHlb6j3yI0JaVAD5v_frOwOy3TiA08Bxa7K-M7eOR8=.70d5d2a0-c78f-4b5f-bfd9-1814f3f3cb3c@github.com>

> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  remove pointer casting and revert unneeded changes

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/2064/files
  - new: https://git.openjdk.org/jfx/pull/2064/files/a14d7938..6e6255d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2064&range=02-03

  Stats: 12 lines in 2 files changed: 1 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/2064.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2064/head:pull/2064

PR: https://git.openjdk.org/jfx/pull/2064

From jpereda at openjdk.org  Tue Feb 10 09:40:45 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 10 Feb 2026 09:40:45 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v4]
In-Reply-To: <tHo822N39w7uD7BkKhy7-vBCbzRCPLc-VTq5RDZnC9s=.42e152f5-002d-4351-85b9-51d5ba8304ad@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
 <QPE-ypt9ZqxF-cjdJJM8WRMslP8ReX1m4B9IdW425mg=.ff426769-0b4f-4f4a-a50f-07bf2e6f2935@github.com>
 <tHo822N39w7uD7BkKhy7-vBCbzRCPLc-VTq5RDZnC9s=.42e152f5-002d-4351-85b9-51d5ba8304ad@github.com>
Message-ID: <UVnR7Y2t9GScLofLogZdXOBGCKGRkePlOGmvRAFBKJw=.3982af7e-3232-450d-bd88-c5ad9b0b7031@github.com>

On Tue, 10 Feb 2026 09:04:46 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove pointer casting and revert unneeded changes
>
> modules/javafx.graphics/src/main/native-prism-es2/PrismES2Defs.h line 72:
> 
>> 70: #include <TargetConditionals.h>
>> 71: 
>> 72: #define jlong_to_ptr(value) (intptr_t)(value)
> 
> I believe we should be able to use those on IOS as well?
> In any case, it is better to case to a pointer instead of to a long

I removed the unnecessary casting in `IOSWindowSystemInterface.m`, so there is no need to modify `PrismES2Defs.h`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2064#discussion_r2786862873

From jvos at openjdk.org  Tue Feb 10 10:43:23 2026
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 10 Feb 2026 10:43:23 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v4]
In-Reply-To: <oiHlb6j3yI0JaVAD5v_frOwOy3TiA08Bxa7K-M7eOR8=.70d5d2a0-c78f-4b5f-bfd9-1814f3f3cb3c@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
 <oiHlb6j3yI0JaVAD5v_frOwOy3TiA08Bxa7K-M7eOR8=.70d5d2a0-c78f-4b5f-bfd9-1814f3f3cb3c@github.com>
Message-ID: <GZfiVfOZDfSjIKyMpdjkZjUfihELptEOs-5YKShJ470=.8eae1ba4-debb-4fd1-b7b0-cd1b28d1da99@github.com>

On Tue, 10 Feb 2026 09:40:42 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove pointer casting and revert unneeded changes

This looks ok now.

Since this PR only touches code inside the native-prism-es2/ios subdirectory, one Approval should be enough -- unless @kevinrushforth  or @arapte or @andy-goryachev-oracle disagree?

Since this PR only touches code inside the native-prism-es2/ios subdirectory, one Approval should be enough -- unless @kevinrushforth  or @arapte or @andy-goryachev-oracle disagree?

-------------

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2064#pullrequestreview-3778160031
PR Comment: https://git.openjdk.org/jfx/pull/2064#issuecomment-3876803741
PR Comment: https://git.openjdk.org/jfx/pull/2064#issuecomment-3876807623

From jhendrikx at openjdk.org  Tue Feb 10 10:44:43 2026
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 10 Feb 2026 10:44:43 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double)
In-Reply-To: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
Message-ID: <EeVvIH3d9Wl2pnfsWmwTxoWZ2t0jvz1v_40PVT2hPlQ=.cae6a650-0266-49f4-ae62-aa4f688335df@github.com>

On Sun, 8 Feb 2026 04:24:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.

Use of `parseDouble` is questionable anyway (unless input was sanitized first) as it is a Java double parser.  For example, this works:


Color.web("rgba(2, 2, 1, 0.25e2f)")

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3876803545

From lukasz.kostyra at oracle.com  Tue Feb 10 13:40:20 2026
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Tue, 10 Feb 2026 13:40:20 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <9fecab86-2b6d-4854-81dd-a55096908ea3@xpipe.io>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B024908A4D6D3DFACDF4DFE89A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
 <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B03B9B31653966CF488F0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <9fecab86-2b6d-4854-81dd-a55096908ea3@xpipe.io>
Message-ID: <DM3PPF3367D7B9BE295275F6F5B73160940FE62A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Hi Christopher,

In addition to bugs you found I also found some more edge cases in KickstartFX where Clear opts did not work properly. I pushed fixes to all those problems (my finds, your find on KickstartFX/MonkeyTester and (I think) on your other application) on the direct3d12 branch - https://github.com/openjdk/jfx-sandbox/commit/cc5a72e130156f9f245d0232ae938644bb2e9c61 - could you give it a try? Note that this won?t fix transparency on UNIFIED Stages yet or Hyper-V problems, I still have to go through those (I plan to tackle these after performance fixes on dGPUs).

If there are still some issues in your other application I?d like to give it a test myself and debug the problems locally (if that?s possible of course :) ).

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io>
Sent: Monday, 2 February 2026 16:14
To: Lukasz Kostyra <lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Yes, the corruption issues are fixed with that property
On 02/02/2026 16:09, Lukasz Kostyra wrote:
Uh, let me finish that email - a random Windows popup appeared while typing which caused my mail client lose focus and interpret typing as shortcuts?

Anyway, I also see the popup windows have this glitch. I will take a closer look at them soon.

As for your other corruption issues, can you check with -Dprism.d3d12.clearOpts=false ? I have a strong suspicion that optimization would be the one to blame again - I was planning to rework it a bit more soon anyway, so it might be a good test candidate for that.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 2 February 2026 16:06
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: [External] : Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking.

I also see the popup windows in MonkeyTester have this glitch, but on my machine it only happens once. R

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Monday, 2 February 2026 16:00
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Looks good, the font looks correct now.

I went through most of the application to see if there's anything else. In the MonkeyTester page, I found this issue with popup windows in the menu bar and shadows I guess? In the d3d9 build, this does not occur. Video is attached.

If you get around to reviewing https://github.com/openjdk/jfx/pull/2058<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/2058__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXfZsrqcq$>, you can use the same testing system to also run kickstartfx with d3d12 as that is also broken in various ways on there.

With our main application, I am getting render corruption issues as shown in the video. I can also give instructions on how to run that application, it is very similar to kickstartfx. Just needs a bit more setup.

Other than that, as mentioned by Martin I think, the translucent background fill for the UNIFIED stage style does not show correctly in kickstartfx if you compare it to the normal build. The left sidebar frame should have the proper window theme color when the performance mode is disabled, however it is only white or black, depending on the system theme:

[cid:image001.png at 01DC9A9A.F4130300]


On 02/02/2026 12:36, Lukasz Kostyra wrote:
This should be the final attempt at resolving this topic once and for all :)

I pushed https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXdE2KA0-$> just now which in my testing makes KickstartFX work properly even on UploadingPainter. After quite a bit of testing and scrolling it seems to me the corrupted font issues are now resolved. Please give it a go and let me know if it works on your end.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 29 January 2026 14:38
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today?

Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Thursday, 29 January 2026 13:31
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking?

The good news is that  https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged.
On 29/01/2026 12:02, Lukasz Kostyra wrote:
I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled?

That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis.

As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed.

For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line.

I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter.

Let me know if KickstartFX runs properly with PresentingPainter.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Wednesday, 21 January 2026 13:54
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu)

On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations.

You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install<https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
On 21/01/2026 13:48, Lukasz Kostyra wrote:
Thanks for checking.

I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine.

I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :)

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Tuesday, 20 January 2026 16:24
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


In our main application I am getting the following error spammed in the logs:

16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture>(BaseGraphics.java:464)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture>(BaseShaderGraphics.java:159)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent>(NGImageView.java:123)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender>(NGImageView.java:103)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint>(ViewPainter.java:481)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl>(ViewPainter.java:329)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run>(UploadingPainter.java:143)
16:18:08:572 - error:     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)

In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues.
On 20/01/2026 15:40, Lukasz Kostyra wrote:
Hi Christopher,

After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$> and according to my local testing everything seems to be fine now.

When you have a moment, could you check out the changes above and let me know if everything works correctly in your app?

If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$> you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app.

Regards,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Wednesday, 10 December 2025 13:29
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

It should work fine without the property. Thanks for your help, I?ll keep searching.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Tuesday, 9 December 2025 17:10
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works.

Or should I still pass the property in this commit as well?
On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
Hi Christopher,

I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$> . Let me know how it works and if the problem has been resolved.

Thanks,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 4 December 2025 11:52
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Wednesday, 3 December 2025 18:53
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false
On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
Hi Christopher,

I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$> to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead.

When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line?

If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down.

Thanks,
-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Friday, 28 November 2025 13:25
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I did not encounter the vanishing issue anymore with that build, so at least it is usable.

However, the font rendering issue still exists for some nodes:

[cid:image002.png at 01DC9A9A.F4130300]

It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly.

Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit.
On 28/11/2025 12:41, Lukasz Kostyra wrote:
Hi Christopher,

I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$> . If you find a moment, could you build JFX from that branch and check if your app works correctly?

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 17 November 2025 15:14
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen.

To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it.

On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Saturday, 15 November 2025 17:39
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Forgot to add, there is nothing out of the ordinary printed in the verbose logs.

If I find the time, I can look into compiling a debug build.

But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me.
On 15/11/2025 17:34, Christopher Schnick wrote:

Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering:

[cid:image003.png at 01DC9A9A.F4130300]

Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay.

After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc.
On 13/11/2025 16:30, Lukasz Kostyra wrote:
Thanks for checking.

It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that.

The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information.

If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks.

If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?.

I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there.

Good luck!
- Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Thursday, 13 November 2025 16:11
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time.

There is no exception thrown as far as I can see, so not sure what you need for debugging.

For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm<https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$> . It is built from these sources: https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
On 13/11/2025 14:40, Lukasz Kostyra wrote:
Hello openjfx-dev,

The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com<https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>

This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread).

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 25 or later.
4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo  - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions.
5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx<https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]

We look forward to your feedback.

Regards,
Lukasz


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/4eda774a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26376 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/4eda774a/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18275 bytes
Desc: image002.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/4eda774a/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 57114 bytes
Desc: image003.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/4eda774a/image003-0001.png>

From mstrauss at openjdk.org  Tue Feb 10 15:09:55 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 15:09:55 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
Message-ID: <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>

> Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.
> 
> There are no new tests for this enhancement, since the existing tests already cover all relevant code paths.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  CSS-compliant double parser

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/2069/files
  - new: https://git.openjdk.org/jfx/pull/2069/files/95a305a2..040dc875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=2069&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2069&range=00-01

  Stats: 469 lines in 3 files changed: 468 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/2069.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2069/head:pull/2069

PR: https://git.openjdk.org/jfx/pull/2069

From mstrauss at openjdk.org  Tue Feb 10 15:15:19 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 10 Feb 2026 15:15:19 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
Message-ID: <n4iJnmHcj3qVdK89gk_zIHFXsFP1aRc-YnVJRtpmN0U=.c5bafa85-ed1d-4336-bf2e-fcf1623c6306@github.com>

On Tue, 10 Feb 2026 15:09:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Color.web(string, double) parses a color string by creating substrings of the input. Almost all of these string allocations can be removed, except for an invocation of `Double.parseDouble(String)`, which doesn't have an overload that accepts a sub-range of the input string.
>> 
>> There are no new tests for this enhancement, since the existing tests already cover all relevant code paths.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSS-compliant double parser

> Use of `parseDouble` is questionable anyway (unless input was sanitized first) as it is a Java double parser. For example, this works:
> 
> ```java
> Color.web("rgba(2, 2, 1, 0.25e2f)")
> ```

You're right, the specification of `Color.web()` explicitly states: _Creates an RGB color specified with an HTML or CSS attribute string_.

Not every string that is parsed by `Double.parseDouble()` is a valid CSS number, and if it is not, it should be rejected by `Color.web()`. I've added code that parses a number according to CSS grammar. With this change, color parsing is now completely allocation-free.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3878370660

From crschnick at xpipe.io  Tue Feb 10 15:22:32 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 10 Feb 2026 16:22:32 +0100
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9BE295275F6F5B73160940FE62A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
 <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B03B9B31653966CF488F0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <9fecab86-2b6d-4854-81dd-a55096908ea3@xpipe.io>
 <DM3PPF3367D7B9BE295275F6F5B73160940FE62A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
Message-ID: <b2027ac3-7f9c-48db-a6fa-41329db266d2@xpipe.io>

I tested with XPipe and KickstartFX, and I didn't encounter any issues. 
Not even minor ones I could spot. So good work on that!

On 10/02/2026 14:40, Lukasz Kostyra wrote:
>
> Hi Christopher,
>
> In addition to bugs you found I also found some more edge cases in 
> KickstartFX where Clear opts did not work properly. I pushed fixes to 
> all those problems (my finds, your find on KickstartFX/MonkeyTester 
> and (I think) on your other application) on the direct3d12 branch - 
> https://github.com/openjdk/jfx-sandbox/commit/cc5a72e130156f9f245d0232ae938644bb2e9c61 
> - could you give it a try? Note that this won?t fix transparency on 
> UNIFIED Stages yet or Hyper-V problems, I still have to go through 
> those (I plan to tackle these after performance fixes on dGPUs).
>
> If there are still some issues in your other application I?d like to 
> give it a test myself and debug the problems locally (if that?s 
> possible of course :) ).
>
> -Lukasz
>
> *From:*Christopher Schnick <crschnick at xpipe.io>
> *Sent:* Monday, 2 February 2026 16:14
> *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
> *Cc:* OpenJFX <openjfx-dev at openjdk.org>
> *Subject:* Re: [External] : Re: JavaFX Direct3D 12 - Second EA release
>
> Yes, the corruption issues are fixed with that property
>
> On 02/02/2026 16:09, Lukasz Kostyra wrote:
>
>     Uh, let me finish that email - a random Windows popup appeared
>     while typing which caused my mail client lose focus and interpret
>     typing as shortcuts?
>
>     Anyway, I also see the popup windows have this glitch. I will take
>     a closer look at them soon.
>
>     As for your other corruption issues, can you check with
>     -Dprism.d3d12.clearOpts=false ? I have a strong suspicion that
>     optimization would be the one to blame again - I was planning to
>     rework it a bit more soon anyway, so it might be a good test
>     candidate for that.
>
>     -Lukasz
>
>     *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> *On Behalf Of *Lukasz Kostyra
>     *Sent:* Monday, 2 February 2026 16:06
>     *To:* Christopher Schnick <crschnick at xpipe.io>
>     <mailto:crschnick at xpipe.io>
>     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject:* RE: [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>     Thanks for checking.
>
>     I also see the popup windows in MonkeyTester have this glitch, but
>     on my machine it only happens once. R
>
>     *From:*Christopher Schnick <crschnick at xpipe.io>
>     *Sent:* Monday, 2 February 2026 16:00
>     *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>     *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>     Looks good, the font looks correct now.
>
>     I went through most of the application to see if there's anything
>     else. In the MonkeyTester page, I found this issue with popup
>     windows in the menu bar and shadows I guess? In the d3d9 build,
>     this does not occur. Video is attached.
>
>     If you get around to reviewing
>     https://github.com/openjdk/jfx/pull/2058
>     <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/2058__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXfZsrqcq$>,
>     you can use the same testing system to also run kickstartfx with
>     d3d12 as that is also broken in various ways on there.
>
>     With our main application, I am getting render corruption issues
>     as shown in the video. I can also give instructions on how to run
>     that application, it is very similar to kickstartfx. Just needs a
>     bit more setup.
>
>     Other than that, as mentioned by Martin I think, the translucent
>     background fill for the UNIFIED stage style does not show
>     correctly in kickstartfx if you compare it to the normal build.
>     The left sidebar frame should have the proper window theme color
>     when the performance mode is disabled, however it is only white or
>     black, depending on the system theme:
>
>     On 02/02/2026 12:36, Lukasz Kostyra wrote:
>
>         This should be the final attempt at resolving this topic once
>         and for all :)
>
>         I pushed
>         https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34
>         <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXdE2KA0-$>
>         just now which in my testing makes KickstartFX work properly
>         even on UploadingPainter. After quite a bit of testing and
>         scrolling it seems to me the corrupted font issues are now
>         resolved. Please give it a go and let me know if it works on
>         your end.
>
>         -Lukasz
>
>         *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>         <mailto:openjfx-dev-retn at openjdk.org> *On Behalf Of *Lukasz
>         Kostyra
>         *Sent:* Thursday, 29 January 2026 14:38
>         *To:* Christopher Schnick <crschnick at xpipe.io>
>         <mailto:crschnick at xpipe.io>
>         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>         <mailto:openjfx-dev at openjdk.org>
>         *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release
>
>         Indeed it is still there, although on my machine it happens
>         less with Presenting Painter. I tried it a couple of times
>         before sending the email and it worked fine, so seems like I
>         should also go buy a lottery ticket today?
>
>         Well, good news to me is that this happens on
>         PresentingPainter, so I now have some more possibilities in
>         terms of debugging it in-place. I?ll get back to you when it?s
>         fixed.
>
>         -Lukasz
>
>         *From:*Christopher Schnick <crschnick at xpipe.io>
>         *Sent:* Thursday, 29 January 2026 13:31
>         *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>         *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release
>
>         I commented out the uploading painter line and still see the
>         same issue. As you say, it shouldn't make a difference. Maybe
>         you hit the one time where the issue just didn't occur
>         statistically speaking?
>
>         The good news is that
>         https://bugs.openjdk.org/browse/JDK-8154847?should be finally
>         fixed by the new translucent backdrop PR, so it shouldn't need
>         this property anymore in the future when it is merged.
>
>         On 29/01/2026 12:02, Lukasz Kostyra wrote:
>
>             I looked through KickstartFX and I noticed there?s a point
>             where KickstartFX forces the use of Uploading Painter -
>             PlatformState.java @ 112. UploadingPainter was designed to
>             work with software pipeline as a fallback mechanism (SW
>             does not have the SwapChain/Presentation mechanisms that
>             HW pipelines use) so using it with hardware-accelerated
>             pipelines is not officially supported. When I set
>             prism.forceUploadingPainter to false text and buttons
>             rendered correctly with D3D12 on my machine. Could you
>             check if everything works fine on your end with
>             UploadingPainter disabled?
>
>             That being said, I do agree there should technically be no
>             visual difference between PresentingPainter and
>             UploadingPainter. I have some theories as to why that
>             would be the case, but because UploadingPainter with
>             hardware pipelines is not officially supported I?ll have
>             to push this issue towards a later point in time.
>             UploadingPainter makes this a bit extra difficult to debug
>             because graphics debuggers rely on applications calling
>             Present() to determine when the application progresses to
>             the next frame - with UploadingPainter no Present() is
>             called and debuggers can?t capture the frame properly for
>             analysis.
>
>             As for Hyper-V problems - I didn?t get a chance to test
>             these yet but we also did not try running JavaFX with
>             D3D12 backend on virtualized platforms. I will take a look
>             at that use case also at a later point in time, once the
>             performance improvements are completed.
>
>             For both of these (UploadingPainter issues and Hyper-V
>             issues) I?ll add separate bugs to my backlog and tackle
>             them later down the line.
>
>             I also checked why UploadingPainter was preferred in
>             KickstartFX and this seems to be the issue -
>             https://bugs.openjdk.org/browse/JDK-8154847. If what
>             Martin mentioned in comment history is correct, there?s a
>             possibility that with D3D12 there should be no
>             transparency issues, as D3D12 defaults to alpha-supported
>             SwapChain buffer (BGRX format exists but presents some
>             technical issues and limitations, BGRA is more
>             convenient). However I had no way of verifying this
>             theory, on my Intel Iris Xe laptop the reproducer works as
>             expected on both D3D and D3D12, with or without
>             UploadingPainter.
>
>             Let me know if KickstartFX runs properly with
>             PresentingPainter.
>
>             -Lukasz
>
>             *From:*Christopher Schnick <crschnick at xpipe.io>
>             <mailto:crschnick at xpipe.io>
>             *Sent:* Wednesday, 21 January 2026 13:54
>             *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>             <mailto:lukasz.kostyra at oracle.com>
>             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>             <mailto:openjfx-dev at openjdk.org>
>             *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA
>             release
>
>             Alright, that is good to know. I also ran the d3d12 build
>             in a Hyper-V Windows 11 VM, which are known to cause
>             issues. For example, this issue happens in those VMs with
>             StageStyle.UNIFIED:
>             https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx
>             uses the unified stage style unless you turn on
>             performance mode in the settings menu)
>
>             On that system, the app sometimes froze completely,
>             sometimes, the rendered image got stuck. Changing the
>             performance mode setting and the
>             property?-Dprism.forceUploadingPainter=true changed the
>             behavior, but it was broken in some way in all configurations.
>
>             You should be able to reproduce these issues easily with
>             the Windows Sandbox feature:
>             https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install
>             <https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
>
>             On 21/01/2026 13:48, Lukasz Kostyra wrote:
>
>                 Thanks for checking.
>
>                 I ran the KickstartFX build one more time, it failed
>                 but I found some leftover global gradle.properties
>                 file which defined older JDK which broke the build.
>                 Changing JDK to 25.0.1 everything built and works fine.
>
>                 I also found a way to build KickstartFX using custom
>                 JFX (customJavaFxLibsPath in build.gradle) and can
>                 reproduce your font issues locally on D3D12. I?ll
>                 report back when I solve them on my end. :)
>
>                 -Lukasz
>
>                 *From:*Christopher Schnick <crschnick at xpipe.io>
>                 <mailto:crschnick at xpipe.io>
>                 *Sent:* Tuesday, 20 January 2026 16:24
>                 *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                 <mailto:lukasz.kostyra at oracle.com>
>                 *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                 <mailto:openjfx-dev at openjdk.org>
>                 *Subject:* [External] : Re: JavaFX Direct3D 12 -
>                 Second EA release
>
>                 In our main application I am getting the following
>                 error spammed in the logs:
>
>                 16:18:08:571 - error: java.lang.NullPointerException:
>                 Cannot invoke "com.sun.prism.Texture.getPixelFormat()"
>                 because "tex" is null
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:571 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329)
>                 16:18:08:572 - error:? ? ?at
>                 javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143)
>                 16:18:08:572 - error:? ? ?at
>                 java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
>                 16:18:08:572 - error:? ? ?at
>                 java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
>                 16:18:08:572 - error:? ? ?at
>                 java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
>
>                 In kickstartfx, I still get the font rendering issues.
>                 Can you share the problems you encountered? I tried to
>                 build it on a blank VM with git clone, setting a JDK25
>                 in the PATH, and running gradlew.bat run without issues.
>
>                 On 20/01/2026 15:40, Lukasz Kostyra wrote:
>
>                     Hi Christopher,
>
>                     After Christmas break I came back to this issue
>                     with some new patches. There were some problems I
>                     found with the clear optimization, I just
>                     submitted
>                     https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31
>                     <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$>
>                     and according to my local testing everything seems
>                     to be fine now.
>
>                     When you have a moment, could you check out the
>                     changes above and let me know if everything works
>                     correctly in your app?
>
>                     If there are still problems I would like to find a
>                     way to build your app and test it locally. I tried
>                     doing that earlier via
>                     https://github.com/xpipe-io/kickstartfx
>                     <https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
>                     you linked earlier but encountered some problems
>                     when building, so I?m going to need your help or
>                     some instructions on how to build the app.
>
>                     Regards,
>
>                     -Lukasz
>
>                     *From:*openjfx-dev <openjfx-dev-retn at openjdk.org>
>                     <mailto:openjfx-dev-retn at openjdk.org> *On Behalf
>                     Of *Lukasz Kostyra
>                     *Sent:* Wednesday, 10 December 2025 13:29
>                     *To:* Christopher Schnick <crschnick at xpipe.io>
>                     <mailto:crschnick at xpipe.io>
>                     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                     <mailto:openjfx-dev at openjdk.org>
>                     *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA
>                     release
>
>                     It should work fine without the property. Thanks
>                     for your help, I?ll keep searching.
>
>                     -Lukasz
>
>                     *From:*Christopher Schnick <crschnick at xpipe.io>
>                     *Sent:* Tuesday, 9 December 2025 17:10
>                     *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                     *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                     *Subject:* [External] : Re: JavaFX Direct3D 12 -
>                     Second EA release
>
>                     I tried this commit, but the problem shows up
>                     again. I tested the previous commit with the
>                     passed property again, and that one still works.
>
>                     Or should I still pass the property in this commit
>                     as well?
>
>                     On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
>
>                         Hi Christopher,
>
>                         I updated the direct3d12 branch with the fix -
>                         https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8
>                         <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$>
>                         . Let me know how it works and if the problem
>                         has been resolved.
>
>                         Thanks,
>
>                         -Lukasz
>
>                         *From:*openjfx-dev
>                         <openjfx-dev-retn at openjdk.org>
>                         <mailto:openjfx-dev-retn at openjdk.org> *On
>                         Behalf Of *Lukasz Kostyra
>                         *Sent:* Thursday, 4 December 2025 11:52
>                         *To:* Christopher Schnick <crschnick at xpipe.io>
>                         <mailto:crschnick at xpipe.io>
>                         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                         <mailto:openjfx-dev at openjdk.org>
>                         *Subject:* RE: Re: JavaFX Direct3D 12 - Second
>                         EA release
>
>                         Thanks for checking. I filed
>                         https://bugs.openjdk.org/browse/JDK-8373088 to
>                         track this since this is unrelated to
>                         specifically text, will probably get to it in
>                         a few days.
>
>                         -Lukasz
>
>                         *From:*Christopher Schnick <crschnick at xpipe.io>
>                         *Sent:* Wednesday, 3 December 2025 18:53
>                         *To:* Lukasz Kostyra <lukasz.kostyra at oracle.com>
>                         *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                         *Subject:* [External] : Re: JavaFX Direct3D 12
>                         - Second EA release
>
>                         This commit fixes the problem when the
>                         property is set to false and it shows up again
>                         if the property is not set to false
>
>                         On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
>
>                             Hi Christopher,
>
>                             I did not find the way to reproduce this
>                             locally, but I found a problem with one of
>                             the optimizations that is in the backend.
>                             To double check if that is in fact the
>                             issue I pushed
>                             https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89
>                             <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$>
>                             to disable the optimization (it is on by
>                             default, disabling it fixes that specific
>                             problem on my end) and I?d like to
>                             double-check if this is the correct lead.
>
>                             When you have a moment, could you build
>                             JFX with that change and run your app with
>                             ?-Dprism.d3d12.clearOpts=false? added to
>                             the command line?
>
>                             If the problem persists with
>                             prism.d3d12.clearOpts set to false I would
>                             need some more information on how these
>                             labels are rendered to track this down.
>
>                             Thanks,
>
>                             -Lukasz
>
>                             *From:*Christopher Schnick
>                             <crschnick at xpipe.io>
>                             <mailto:crschnick at xpipe.io>
>                             *Sent:* Friday, 28 November 2025 13:25
>                             *To:* Lukasz Kostyra
>                             <lukasz.kostyra at oracle.com>
>                             <mailto:lukasz.kostyra at oracle.com>
>                             *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                             <mailto:openjfx-dev at openjdk.org>
>                             *Subject:* [External] : Re: JavaFX
>                             Direct3D 12 - Second EA release
>
>                             I did not encounter the vanishing issue
>                             anymore with that build, so at least it is
>                             usable.
>
>                             However, the font rendering issue still
>                             exists for some nodes:
>
>                             It is not deterministic, meaning that if I
>                             just scroll the scrollpane forward and
>                             back, the same text might get rendered
>                             correctly.
>
>                             Also, did you see the performance results
>                             I posted for my AMD system? Performance
>                             was quite bad there, so this is not in a
>                             stage where I can test this in production
>                             a bit.
>
>                             On 28/11/2025 12:41, Lukasz Kostyra wrote:
>
>                                 Hi Christopher,
>
>                                 I just pushed a fix for JDK-8371995
>                                 onto direct3d12 branch in the sandbox
>                                 -
>                                 https://github.com/openjdk/jfx-sandbox/tree/direct3d12
>                                 <https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$>
>                                 . If you find a moment, could you
>                                 build JFX from that branch and check
>                                 if your app works correctly?
>
>                                 -Lukasz
>
>                                 *From:*openjfx-dev
>                                 <openjfx-dev-retn at openjdk.org>
>                                 <mailto:openjfx-dev-retn at openjdk.org>
>                                 *On Behalf Of *Lukasz Kostyra
>                                 *Sent:* Monday, 17 November 2025 15:14
>                                 *To:* Christopher Schnick
>                                 <crschnick at xpipe.io>
>                                 <mailto:crschnick at xpipe.io>
>                                 *Cc:* OpenJFX
>                                 <openjfx-dev at openjdk.org>
>                                 <mailto:openjfx-dev at openjdk.org>
>                                 *Subject:* RE: Re: JavaFX Direct3D 12
>                                 - Second EA release
>
>                                 I might?ve found the problem, there is
>                                 an assertion that triggers when
>                                 multiple text objects using different
>                                 fonts are drawn. It could be related
>                                 (AFAIK Label controls will eventually
>                                 end up at the same text rendering
>                                 routines as Text nodes). Assertions
>                                 are compiled out on Release for
>                                 performance, so there is a chance it
>                                 would corrupt the rendering without
>                                 anything meaningful shown on screen.
>
>                                 To track this I just filed
>                                 https://bugs.openjdk.org/browse/JDK-8371995
>                                 . I will check it and let you know
>                                 when I fix it.
>
>                                 On your side It might still be handy
>                                 to build JFX in DebugNative, to
>                                 confirm if the triggered assertion is
>                                 the same and to later confirm if the
>                                 fix is working for you too.
>
>                                 -Lukasz
>
>                                 *From:*Christopher Schnick
>                                 <crschnick at xpipe.io>
>                                 *Sent:* Saturday, 15 November 2025 17:39
>                                 *To:* Lukasz Kostyra
>                                 <lukasz.kostyra at oracle.com>
>                                 *Cc:* OpenJFX <openjfx-dev at openjdk.org>
>                                 *Subject:* Re: [External] : Re: JavaFX
>                                 Direct3D 12 - Second EA release
>
>                                 Forgot to add, there is nothing out of
>                                 the ordinary printed in the verbose logs.
>
>                                 If I find the time, I can look into
>                                 compiling a debug build.
>
>                                 But the problem should be reproducible
>                                 somehow when just automatically
>                                 creating a lot of labels with random
>                                 styles, sizes, and text. Some of them
>                                 should break as they did for me.
>
>                                 On 15/11/2025 17:34, Christopher
>                                 Schnick wrote:
>
>                                     Ok, so I had more time to debug
>                                     it. The one weird thing I observed
>                                     when it was working was that some
>                                     labels have corrupted text rendering:
>
>
>                                     Not all of them, most are fine.
>                                     There are no differences in terms
>                                     of style classes etc. between the
>                                     labels. When scrolling, the
>                                     rendering sometimes switches
>                                     between this corrupted and normal
>                                     state after some delay.
>
>                                     After a while I also figured out
>                                     that text rendering is responsible
>                                     for the issue of the nodes
>                                     vanishing: Certain label contents
>                                     broke the renderer. For example,
>                                     in my application, the string
>                                     "Password manager" when assigned
>                                     to a label broke it and nothing
>                                     was rendered anymore. I tried to
>                                     find an easy reproducer but was
>                                     not able to. It's probably very
>                                     dependent on all the different
>                                     style classes that influence the
>                                     text shape/size/etc.
>
>                                     On 13/11/2025 16:30, Lukasz
>                                     Kostyra wrote:
>
>                                         Thanks for checking.
>
>                                         It is very possible the D3D12
>                                         runtime did not like
>                                         something, could be related to
>                                         your specific hardware. D3D12
>                                         by now has many extensions
>                                         which differ depending on
>                                         hardware and can lift certain
>                                         restrictions - we already
>                                         internally had a case where
>                                         one GPU had some restriction
>                                         that was not enforced on
>                                         another GPU and we had to
>                                         accommodate that.
>
>                                         The first step would be to try
>                                         running D3D12 with
>                                         ?-Dprism.verbose=true
>                                         -Dprism.debug=true?. These
>                                         should print additional logs
>                                         that might have some extra
>                                         information.
>
>                                         If there?s nothing useful
>                                         there, next step would be to
>                                         build JavaFX with
>                                         -PCONF=DebugNative - this will
>                                         compile shaders in Debug, add
>                                         assertions and debug logs to
>                                         the backend - and then run
>                                         your app with D3D12 debug
>                                         layers and GPU debugging
>                                         enabled by adding
>                                         ?-Dprsim.d3d12.debugLayers=true
>                                         -Dprism.d3d12.gpuDebug=true?.
>                                         Those will slow down the app
>                                         significantly, but will also
>                                         tell D3D12 to run additional
>                                         API use and GPU use checks.
>
>                                         If the problem happens during
>                                         a render loop and debug layers
>                                         catch it, there is a chance it
>                                         will cascade into other errors
>                                         and spam the console output -
>                                         you can tell D3D12 debug
>                                         layers to trigger an assertion
>                                         on first encountered error
>                                         with
>                                         ?-Dprism.d3d12.breakOnError=true?.
>
>                                         I am running out of time today
>                                         to check this myself, but if
>                                         you find something let me know
>                                         - I?ll try to reproduce the
>                                         problem myself and we?ll see
>                                         where we go from there.
>
>                                         Good luck!
>
>                                         - Lukasz
>
>                                         *From:*Christopher Schnick
>                                         <crschnick at xpipe.io>
>                                         <mailto:crschnick at xpipe.io>
>                                         *Sent:* Thursday, 13 November
>                                         2025 16:11
>                                         *To:* Lukasz Kostyra
>                                         <lukasz.kostyra at oracle.com>
>                                         <mailto:lukasz.kostyra at oracle.com>
>                                         *Cc:* openjfx-dev at openjdk.org
>                                         *Subject:* [External] : Re:
>                                         JavaFX Direct3D 12 - Second EA
>                                         release
>
>                                         I just tried to run a project
>                                         with provided jmods and at
>                                         some point, certain nodes are
>                                         just not rendered anymore and
>                                         the window contents vanish.
>                                         But they render for a short
>                                         period of time.
>
>                                         There is no exception thrown
>                                         as far as I can see, so not
>                                         sure what you need for debugging.
>
>                                         For testing, this is the built
>                                         application with the d3d12
>                                         jmods that you can use to
>                                         attempt to reproduce the
>                                         problem:
>                                         https://we.tl/t-DJuX0BeqXm
>                                         <https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$>
>                                         . It is built from these
>                                         sources:
>                                         https://github.com/xpipe-io/kickstartfx
>                                         <https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
>
>                                         On 13/11/2025 14:40, Lukasz
>                                         Kostyra wrote:
>
>                                             Hello openjfx-dev,
>
>                                             The second Early
>                                             Access(EA) build of JavaFX
>                                             with the Windows Direct3D
>                                             12 rendering pipeline is
>                                             now available at:
>                                             https://jdk.java.net/javafxdirect3d12/
>                                             <https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>
>
>                                             Please test this bundle
>                                             and share your feedback by:
>
>                                             - emailing
>                                             openjfx-dev at openjdk.java.net
>                                             or
>
>                                             - reporting issues via
>                                             JBS[https://bugs.openjdk.org/]
>                                             or at
>                                             https://bugreport.java.com
>                                             <https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>
>
>                                             This is the second EA
>                                             release. The backend is
>                                             feature-complete and went
>                                             through a first
>                                             optimization pass, but it
>                                             still requires some more
>                                             testing on more hardware
>                                             variants before we can
>                                             consider it complete. As
>                                             such, with this release we
>                                             also would like to call
>                                             for help with performance
>                                             testing the backend (more
>                                             details on that will be
>                                             sent in a separate email
>                                             thread).
>
>                                             Known issues and pending
>                                             tasks are captured on JBS
>                                             and can be accessed using
>                                             the filter provided on the
>                                             Direct3D 12 EA page
>                                             [https://jdk.java.net/javafxdirect3d12/
>                                             <https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>].
>                                             Before reporting a new
>                                             bug, please review the
>                                             existing issues to avoid
>                                             duplicates.
>
>                                             Important Notes:
>
>                                             1. This is a
>                                             Windows-specific feature,
>                                             so only a Windows-specific
>                                             bundle is provided.
>
>                                             2. The default rendering
>                                             pipeline is set to d3d12.
>                                             Use "-Dprism.order=d3d" or
>                                             "-Dprism.order=sw" to
>                                             select one of the other
>                                             pipelines for comparison
>                                             testing.
>
>                                             3. It is recommended to
>                                             use JDK 25 or later.
>
>                                             4. At this stage D3D12
>                                             backend is
>                                             feature-complete and went
>                                             through the first phase of
>                                             optimization. It is worth
>                                             noting that, while
>                                             generally we noticed
>                                             performance improvements,
>                                             it might not be on par
>                                             with D3D backend on every
>                                             machine combo? - we
>                                             already noted performance
>                                             being worse on recent
>                                             NVidia discrete GPUs
>                                             [https://bugs.openjdk.org/browse/JDK-8370486]
>                                             and are looking for solutions.
>
>                                             5. Issue behavior may vary
>                                             across different hardware,
>                                             so please provide detailed
>                                             information, such as the
>                                             output of "java
>                                             -Dprism.verbose=true" or
>                                             used hardware, when
>                                             reporting or discussing
>                                             issues.
>
>                                             6. Refer: Run HelloWorld
>                                             using JavaFX SDK
>                                             [https://openjfx.io/openjfx-docs/#install-javafx
>                                             <https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]
>
>                                             We look forward to your
>                                             feedback.
>
>                                             Regards,
>
>                                             Lukasz
>
>                                             Confidential- Oracle Internal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/b450acea/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26376 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/b450acea/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18275 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/b450acea/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 57114 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/b450acea/image003-0001.png>

From angorya at openjdk.org  Tue Feb 10 15:27:47 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 10 Feb 2026 15:27:47 GMT
Subject: RFR: 8370902: RichTextArea: migrate to new text APIs
In-Reply-To: <DTPO-UP8FOCR9RLOpSMqlfnkayONMGQgA0GNxnTK-Dc=.b83df6df-d752-4f9b-a525-bc0a21aa01ed@github.com>
References: <DTPO-UP8FOCR9RLOpSMqlfnkayONMGQgA0GNxnTK-Dc=.b83df6df-d752-4f9b-a525-bc0a21aa01ed@github.com>
Message-ID: <cHfdalG0U8mYhtQiinhK9nJgWLuYnPu-u6VtEQoVbLo=.e996fd83-ef2e-4337-97ed-504bbd95df44@github.com>

On Wed, 17 Dec 2025 20:38:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Updates the `RichTextArea` code to use the new text layout APIs delivered in https://bugs.openjdk.org/browse/JDK-8341670
> 
> Also:
> 
> - updates the "demo" model in the `RichTextAreaDemoApp` to show underline/strikethrough in the presence of `TextFlow` borders

@Ziad-Mid could you be the second reviewer please?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2012#issuecomment-3878495914

From angorya at openjdk.org  Tue Feb 10 15:39:26 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 10 Feb 2026 15:39:26 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <YMDKddyWxa-swJdOJs9q-kEHn7lwAuABnmOkH33ESLc=.c1fba6a7-165d-4ad5-9354-1e2bb747a85e@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <8JH4vUASJI73tlyaOs9ubBhAo_6jjMqh_QXiSW7AEDo=.b9435524-29c9-4856-9ebf-91ae62594ff2@github.com>
 <YMDKddyWxa-swJdOJs9q-kEHn7lwAuABnmOkH33ESLc=.c1fba6a7-165d-4ad5-9354-1e2bb747a85e@github.com>
Message-ID: <qlAs4idynWHEeHJffFBd-Lm6agHW_qXbOQcn5L1N1oI=.1882f850-7433-4888-8982-f6a35576c2eb@github.com>

On Tue, 10 Feb 2026 00:29:04 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 517:
>> 
>>> 515:         int limit = end;
>>> 516: 
>>> 517:         while (start < limit && Character.isWhitespace(color.charAt(start))) {
>> 
>> I think this change is not equivalent: the `trim()` function (used before) removes leading and trailing "spaces" which are defined as `space is defined as any character whose codepoint is less than or equal to 'U+0020' (the space character).`
>> 
>> `Character.isWhitespace()` is different:
>> 
>> 
>> hex| trim| isWhitespace
>> 0x00 W -
>> 0x01 W -
>> 0x02 W -
>> 0x03 W -
>> 0x04 W -
>> 0x05 W -
>> 0x06 W -
>> 0x07 W -
>> 0x08 W -
>> 0x09 W W
>> 0x0a W W
>> 0x0b W W
>> 0x0c W W
>> 0x0d W W
>> 0x0e W -
>> 0x0f W -
>> 0x10 W -
>> 0x11 W -
>> 0x12 W -
>> 0x13 W -
>> 0x14 W -
>> 0x15 W -
>> 0x16 W -
>> 0x17 W -
>> 0x18 W -
>> 0x19 W -
>> 0x1a W -
>> 0x1b W -
>> 0x1c W W
>> 0x1d W W
>> 0x1e W W
>> 0x1f W W
>> 0x20 W W
>> 
>> 
>> see https://github.com/andy-goryachev-oracle/Test/blob/main/test/goryachev/research/TestWhitespace.java
>
> While that's true, I think it is irrelevant. `Color.web()` is not specified to just skip over non-whitespace control characters inside of a color function, and it is not prudent to assume that a string parsing function would silently skip over non-whitespace control characters by default.

I am pointing out a non-zero chance of regression, for instance when this method is used to parse an external poorly formatted file with no sanitizing.

I do agree that this change is probably fine though.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2788695855

From lukasz.kostyra at oracle.com  Tue Feb 10 16:32:42 2026
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Tue, 10 Feb 2026 16:32:42 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <b2027ac3-7f9c-48db-a6fa-41329db266d2@xpipe.io>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io>
 <DM3PPF3367D7B9B31C7F83A0BD8FBF20E7CFE96A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <d1ee3c16-e25c-4364-ae0e-9d45a7479e20@xpipe.io>
 <DM3PPF3367D7B9B5E088A25EE43AB1710FCFE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b7092d51-9c47-4561-aaf6-be95faf5a4d2@xpipe.io>
 <DM3PPF3367D7B9BD090DAAC779DE3D66659FE9EA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B0179E6B7DD7DF5C0E9D0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2c990f10-0b9b-4a52-b708-f5a6ff23fd8d@xpipe.io>
 <DM3PPF3367D7B9BDBCCA85199E5401437CAFE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <DM3PPF3367D7B9B03B9B31653966CF488F0FE9AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <9fecab86-2b6d-4854-81dd-a55096908ea3@xpipe.io>
 <DM3PPF3367D7B9BE295275F6F5B73160940FE62A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <b2027ac3-7f9c-48db-a6fa-41329db266d2@xpipe.io>
Message-ID: <DM3PPF3367D7B9B7029B8AC74521A3B18CDFE62A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Perfect news! Thanks for helping me resolve these problems.

I?ll probably get back to this thread once I get to other things you reported, but for now I need to focus on something else.

Thank you once again!
-Lukasz

From: Christopher Schnick <crschnick at xpipe.io>
Sent: Tuesday, 10 February 2026 16:23
To: Lukasz Kostyra <lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I tested with XPipe and KickstartFX, and I didn't encounter any issues. Not even minor ones I could spot. So good work on that!
On 10/02/2026 14:40, Lukasz Kostyra wrote:
Hi Christopher,

In addition to bugs you found I also found some more edge cases in KickstartFX where Clear opts did not work properly. I pushed fixes to all those problems (my finds, your find on KickstartFX/MonkeyTester and (I think) on your other application) on the direct3d12 branch - https://github.com/openjdk/jfx-sandbox/commit/cc5a72e130156f9f245d0232ae938644bb2e9c61<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/cc5a72e130156f9f245d0232ae938644bb2e9c61__;!!ACWV5N9M2RV99hQ!IK8QqGcOFn2xISEnHmtXinuZzNvx9yre0nK-U-75XpgstHjNdE8zjs-6lnLSmH1engM2Viq_kTn2Cj26kKmGxnvf$> - could you give it a try? Note that this won?t fix transparency on UNIFIED Stages yet or Hyper-V problems, I still have to go through those (I plan to tackle these after performance fixes on dGPUs).

If there are still some issues in your other application I?d like to give it a test myself and debug the problems locally (if that?s possible of course :) ).


-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Monday, 2 February 2026 16:14
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Yes, the corruption issues are fixed with that property
On 02/02/2026 16:09, Lukasz Kostyra wrote:
Uh, let me finish that email - a random Windows popup appeared while typing which caused my mail client lose focus and interpret typing as shortcuts?

Anyway, I also see the popup windows have this glitch. I will take a closer look at them soon.

As for your other corruption issues, can you check with -Dprism.d3d12.clearOpts=false ? I have a strong suspicion that optimization would be the one to blame again - I was planning to rework it a bit more soon anyway, so it might be a good test candidate for that.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 2 February 2026 16:06
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: [External] : Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking.

I also see the popup windows in MonkeyTester have this glitch, but on my machine it only happens once. R

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Monday, 2 February 2026 16:00
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Looks good, the font looks correct now.

I went through most of the application to see if there's anything else. In the MonkeyTester page, I found this issue with popup windows in the menu bar and shadows I guess? In the d3d9 build, this does not occur. Video is attached.

If you get around to reviewing https://github.com/openjdk/jfx/pull/2058<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/2058__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXfZsrqcq$>, you can use the same testing system to also run kickstartfx with d3d12 as that is also broken in various ways on there.

With our main application, I am getting render corruption issues as shown in the video. I can also give instructions on how to run that application, it is very similar to kickstartfx. Just needs a bit more setup.

Other than that, as mentioned by Martin I think, the translucent background fill for the UNIFIED stage style does not show correctly in kickstartfx if you compare it to the normal build. The left sidebar frame should have the proper window theme color when the performance mode is disabled, however it is only white or black, depending on the system theme:

[cid:image001.png at 01DC9AB2.F7251110]


On 02/02/2026 12:36, Lukasz Kostyra wrote:
This should be the final attempt at resolving this topic once and for all :)

I pushed https://github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/dcaf8879db2b660e547e21edf31a1c8421aeab34__;!!ACWV5N9M2RV99hQ!J3KNuGQU-sZ0xyclRGtrUi12g5JK3IX5bWVDFjedmOKvrKaCdDd1yMemreDAQpIgwP1g8kVm5k7g_uGdXdE2KA0-$> just now which in my testing makes KickstartFX work properly even on UploadingPainter. After quite a bit of testing and scrolling it seems to me the corrupted font issues are now resolved. Please give it a go and let me know if it works on your end.

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 29 January 2026 14:38
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today?

Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Thursday, 29 January 2026 13:31
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking?

The good news is that  https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged.
On 29/01/2026 12:02, Lukasz Kostyra wrote:
I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled?

That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis.

As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed.

For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line.

I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter.

Let me know if KickstartFX runs properly with PresentingPainter.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Wednesday, 21 January 2026 13:54
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu)

On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations.

You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install<https://urldefense.com/v3/__https:/learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install__;!!ACWV5N9M2RV99hQ!PhZXH7yVYtau5GffJqYZ2u0kJWnvdfqwZ505JNps6FUDmkZT1cTaY28P1sUyr3UvO_oLMcT6UkYRK3KwB9dOzqRg$>
On 21/01/2026 13:48, Lukasz Kostyra wrote:
Thanks for checking.

I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine.

I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :)

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Tuesday, 20 January 2026 16:24
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


In our main application I am getting the following error spammed in the logs:

16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture>(BaseGraphics.java:464)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture<mailto:javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture>(BaseShaderGraphics.java:159)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent>(NGImageView.java:123)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender>(NGImageView.java:103)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:571 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip>(NGNode.java:2279)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip>(NGNode.java:2186)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip>(NGNode.java:2213)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache>(CacheFilter.java:682)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render>(CacheFilter.java:586)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached>(NGNode.java:2343)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2054)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent>(NGGroup.java:266)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent>(NGRegion.java:579)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender>(NGNode.java:2063)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render<mailto:javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render>(NGNode.java:1955)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint>(ViewPainter.java:481)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl>(ViewPainter.java:329)
16:18:08:572 - error:     at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run<mailto:javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run>(UploadingPainter.java:143)
16:18:08:572 - error:     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
16:18:08:572 - error:     at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)

In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues.
On 20/01/2026 15:40, Lukasz Kostyra wrote:
Hi Christopher,

After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31__;!!ACWV5N9M2RV99hQ!Js1REsWcDjMJTtd7_06jSspPNfrXAhmcztgQtVr7IH0e7xUQW51OhBZ-P9O6TfdB0v6e7Brk7yYlHI7mq363A1sg$> and according to my local testing everything seems to be fine now.

When you have a moment, could you check out the changes above and let me know if everything works correctly in your app?

If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$> you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app.

Regards,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Wednesday, 10 December 2025 13:29
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

It should work fine without the property. Thanks for your help, I?ll keep searching.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Tuesday, 9 December 2025 17:10
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works.

Or should I still pass the property in this commit as well?
On 09/12/2025 4:36 PM, Lukasz Kostyra wrote:
Hi Christopher,

I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8__;!!ACWV5N9M2RV99hQ!OLgt8HGQc2SZQqycgcFI2bUPgQXEdES6FZw0Gn_bo_kiS2WoY4A68Z3JxY-ElC_58HSF12FXKCoat4MrrESK9ceD$> . Let me know how it works and if the problem has been resolved.

Thanks,
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Thursday, 4 December 2025 11:52
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Wednesday, 3 December 2025 18:53
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false
On 03/12/2025 5:54 PM, Lukasz Kostyra wrote:
Hi Christopher,

I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89__;!!ACWV5N9M2RV99hQ!JFEGrvRPb5-P9TxSZen0sbWuRq_Go_lMwM3kO5m0u_RlMgJW1cDfe8HxdAlgEedAsg4aSm99IyDYzbsN8x-LMbPQ$> to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead.

When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line?

If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down.

Thanks,
-Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Friday, 28 November 2025 13:25
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I did not encounter the vanishing issue anymore with that build, so at least it is usable.

However, the font rendering issue still exists for some nodes:

[cid:image002.png at 01DC9AB2.F7251110]

It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly.

Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit.
On 28/11/2025 12:41, Lukasz Kostyra wrote:
Hi Christopher,

I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!KuiGt3yDg1iNtCswOA3yLUbPKFpTnRKQE9clxnsd6xQRhnGJLoz7c697JC77xG2Q4qwsMWDePar6hRx9DY1uTPpy$> . If you find a moment, could you build JFX from that branch and check if your app works correctly?

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> On Behalf Of Lukasz Kostyra
Sent: Monday, 17 November 2025 15:14
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RE: Re: JavaFX Direct3D 12 - Second EA release

I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen.

To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it.

On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too.

-Lukasz

From: Christopher Schnick <crschnick at xpipe.io<mailto:crschnick at xpipe.io>>
Sent: Saturday, 15 November 2025 17:39
To: Lukasz Kostyra <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
Cc: OpenJFX <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release


Forgot to add, there is nothing out of the ordinary printed in the verbose logs.

If I find the time, I can look into compiling a debug build.

But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me.
On 15/11/2025 17:34, Christopher Schnick wrote:

Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering:

[cid:image003.png at 01DC9AB2.F7251110]

Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay.

After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc.
On 13/11/2025 16:30, Lukasz Kostyra wrote:
Thanks for checking.

It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that.

The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information.

If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks.

If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?.

I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there.

Good luck!
- Lukasz

From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Sent: Thursday, 13 November 2025 16:11
To: Lukasz Kostyra <lukasz.kostyra at oracle.com><mailto:lukasz.kostyra at oracle.com>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release


I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time.

There is no exception thrown as far as I can see, so not sure what you need for debugging.

For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm<https://urldefense.com/v3/__https:/we.tl/t-DJuX0BeqXm__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn7hHbsl_$> . It is built from these sources: https://github.com/xpipe-io/kickstartfx<https://urldefense.com/v3/__https:/github.com/xpipe-io/kickstartfx__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn9_QfENu$>
On 13/11/2025 14:40, Lukasz Kostyra wrote:
Hello openjfx-dev,

The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com<https://urldefense.com/v3/__https:/bugreport.java.com__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn-g1RFIV$>

This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread).

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xnw7Bj6i8$>]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 25 or later.
4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo  - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions.
5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx<https://urldefense.com/v3/__https:/openjfx.io/openjfx-docs/*install-javafx__;Iw!!ACWV5N9M2RV99hQ!K0ztYeDtYFyIwxlmMB-9MDuvY7Xyd60-LuJK99hex3mclCWl29MJfnxkz2mmECxINzNr5bAdKvQ64O9Xn8uMZKUY$>]

We look forward to your feedback.

Regards,
Lukasz


Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/22f40cde/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26376 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/22f40cde/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18275 bytes
Desc: image002.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/22f40cde/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 57114 bytes
Desc: image003.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260210/22f40cde/image003-0001.png>

From angorya at openjdk.org  Wed Feb 11 09:55:33 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Feb 2026 09:55:33 GMT
Subject: RFR: 8377426: Adjust scene background to color scheme
In-Reply-To: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
References: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
Message-ID: <KrTFVDIVIsZPpCQ5m3B03Z9tlr0upzSDQbdvno9-jpE=.515f3301-80f8-40b7-a557-0f5ecfb5e00e@github.com>

On Sun, 8 Feb 2026 03:30:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a non-opaque scene fill color is used with a stage style other than `StageStyle.TRANSPARENT`, the actual fill color is always white. This doesn't work well when the scene uses a dark color scheme. A practical solution is to allow non-opaque scene fill colors, and blend them on top of a white or black background (depending on color scheme) to derive an opaque color that adapts intuitively to the color scheme.
> 
> To test this, simply create a scene that uses a non-opaque fill color and observe the scene background when the color scheme is changed.
> 
> This PR includes a system test, run it with:
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.SceneFillTest.testSceneFill

hmm, something is wrong:

> Task :systemTests:test

SceneFillTest > testSceneFill(String, String, String) > [3] rgba(0, 0, 0, 0.75), rgb(63, 63, 63), BLACK FAILED
    org.opentest4j.AssertionFailedError: expected: <0x3f3f3fff> but was: <0x404040ff>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
        at app//test.robot.javafx.scene.SceneFillTest.lambda$testSceneFill$1(SceneFillTest.java:96)

SceneFillTest > testSceneFill(String, String, String) > [4] rgba(127, 127, 127, 0.5), rgb(191, 191, 191), rgb(63, 63, 63) FAILED
    org.opentest4j.AssertionFailedError: expected: <0x3f3f3fff> but was: <0x404040ff>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
        at app//test.robot.javafx.scene.SceneFillTest.lambda$testSceneFill$2(SceneFillTest.java:106)

SceneFillTest > testSceneFill(String, String, String) > [6] rgba(0, 100, 0, 0.8), rgb(50, 131, 50), rgb(0, 80, 0) FAILED
    org.opentest4j.AssertionFailedError: expected: <0x328332ff> but was: <0x328333ff>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
        at app//test.robot.javafx.scene.SceneFillTest.lambda$testSceneFill$1(SceneFillTest.java:96)

6 tests completed, 3 failed

> Task :systemTests:test FAILED

[Incubating] Problems report is available at: file:///Users/angorya/Projects/jfx3/jfx/rt/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':systemTests:test'.
> There were failing tests. See the report at: file:///Users/angorya/Projects/jfx3/jfx/rt/tests/system/build/reports/tests/test/index.html

* Try:
> Run with --scan to get full insights from a Build Scan (powered by Develocity).

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/9.3.0/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 1m 14s
256 actionable tasks: 125 executed, 131 up-to-date
dhcp-10-89-197-66:rt angorya$ git status
On branch pull/2068

yes, macOS 26.2
the small difference is probably due to the color space, I think we had similar issues before.

also, on mac (edit: in light mode), I don't see the white background.  what I do see is the background flickering momentarily to black before going to the set color, here is the test code (I might be doing something wrong though):

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/Stage_Background_8377426.java

In the dark mode, I do see the screen flickering to white before going to the set color, using the same test with lighter color:

        sc.setFill(Color.rgb(255, 255, 255, 0.2));


(the master branch simply goes full white w/o flicker in the dark mode)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2068#issuecomment-3880473703
PR Comment: https://git.openjdk.org/jfx/pull/2068#issuecomment-3880564753
PR Comment: https://git.openjdk.org/jfx/pull/2068#issuecomment-3880582488

From vdyakov at openjdk.org  Wed Feb 11 09:55:42 2026
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 11 Feb 2026 09:55:42 GMT
Subject: RFR: 8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4
In-Reply-To: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
References: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
Message-ID: <z-ufwtcBdnSlIkwCydlwEllvnRgcThngMMGwLwg0W8s=.11528aa8-a4fe-45b2-a9b6-6e37053d122a@github.com>

On Wed, 4 Feb 2026 16:15:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates webkit to v2.50.4. Verified build and sanity on mac, windows and linux platforms. No issue seen.

@tiainen please review

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2063#issuecomment-3879474285

From mstrauss at openjdk.org  Wed Feb 11 09:55:41 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Feb 2026 09:55:41 GMT
Subject: RFR: 8377426: Adjust scene background to color scheme
In-Reply-To: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
References: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
Message-ID: <n0H3ou4-KQNYuRV_yn0p1M0majXUjHeeHa7yuom_Bdc=.edde9b4d-d03c-46cd-888d-1a3c2a80757d@github.com>

On Sun, 8 Feb 2026 03:30:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a non-opaque scene fill color is used with a stage style other than `StageStyle.TRANSPARENT`, the actual fill color is always white. This doesn't work well when the scene uses a dark color scheme. A practical solution is to allow non-opaque scene fill colors, and blend them on top of a white or black background (depending on color scheme) to derive an opaque color that adapts intuitively to the color scheme.
> 
> To test this, simply create a scene that uses a non-opaque fill color and observe the scene background when the color scheme is changed.
> 
> This PR includes a system test, run it with:
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.SceneFillTest.testSceneFill

It seems like the sampled color is off by a tiny bit. Are you running the test on macOS? I wonder why the rendered colors would _almost_ match, but be ever-so-slightly different compared to Windows.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2068#issuecomment-3880514478

From mstrauss at openjdk.org  Wed Feb 11 09:57:04 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Feb 2026 09:57:04 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <FVBgo_14d0_j0C7-HdJzX_JPZHBuDfYTkX7Xv2mXRLs=.c84c2e9a-7b91-4ff6-a531-93ab760d5242@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
 <FVBgo_14d0_j0C7-HdJzX_JPZHBuDfYTkX7Xv2mXRLs=.c84c2e9a-7b91-4ff6-a531-93ab760d5242@github.com>
Message-ID: <XIfXjA2bm_5LKNNeF1ftVditVYD-yZ4b7GCoJGjxNTc=.3172e5c5-5279-48a0-adaf-cab6c404e5c2@github.com>

On Tue, 10 Feb 2026 16:49:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The JavaFX CSS spec states (under <number>):
> 
> ```
> Real numbers and integers are specified in decimal notation only. ... A <number> can either be an <integer>, or it can be zero or more digits followed by a dot (.) followed by one or more digits. Both integers and real numbers may be preceded by a "-" or "+" to indicate the sign. -0 is equivalent to 0 and is not a negative number.
> 
> [+|-]? [[0-9]+|[0-9]*"."[0-9]+]
> ```
> 
> it looks to me like exponential notation should not be supported.
> 

In the interest of not being different just for the sake of it, we should probably change this specification and use the W3C definition of a number everywhere. Not terribly important (no one uses E notation anyway), but better be consistent.

> Mandatory disclaimer: W3C is not a real standard.

[5.8 billion](https://sqmagazine.co.uk/web-browser-usage-statistics/#Web-Browser-Market-Size-Growth-2018%E2%80%932025) web browser installations disagree. What fraction of a fraction of a percent of this number is JavaFX again? W3C's baseline compatibility standard is as good as any standard can possibly be. There are no other CSS specifications of any significance whatsoever.

> I am not sure if we want to change the CSS spec to allow scientific notation in all the s, I don't even sure we want to add this support in `Color.web()`. If we do though, I think we would need to update the javadoc and possibly the CSS Reference, right?

Right now, the situation is a bit inconsistent:
* Doesn't parse: `rgb(1E2, 0, 0)`
* Parses: `rgb(1E2%, 0, 0)`
* Doesn't parse: `rgb(1E2%, 100.0, 100)`
* Parses: `rgb(1E2%, 100, 100)`

JavaFX contradicts its own specification, but the specification is (and has always been) wrong anyway.

> modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 405:
> 
>> 403:         if (colorString.regionMatches(true, 0, "#", 0, 1)) {
>> 404:             offset = 1;
>> 405:         } else if (colorString.regionMatches(true, 0, "0x", 0, 2)) {
> 
> interestingly, while the code (both old and new) ignores case, the javadoc says nothing about case sensitivity.

It does say that it parses a CSS color string, and CSS is case-insensitive.

> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssNumberParserTest.java line 40:
> 
>> 38:     @Test
>> 39:     public void parseIntegerAndSignedInteger() {
>> 40:         assertEquals(0.0, parseDouble("0"), 0.0);
> 
> The JavaFX CSS spec also states
> 
> 
> -0 is equivalent to 0 and is not a negative number.
> 
> 
> How should we test this?

On the JVM, `-0 == 0`. It seems to me that this sentence just spells it out, doesn't it?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3879937950
PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3880451384
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2788966646
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2789556392

From angorya at openjdk.org  Wed Feb 11 09:56:44 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Feb 2026 09:56:44 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
Message-ID: <FVBgo_14d0_j0C7-HdJzX_JPZHBuDfYTkX7Xv2mXRLs=.c84c2e9a-7b91-4ff6-a531-93ab760d5242@github.com>

On Tue, 10 Feb 2026 15:09:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Color.web(string, double) parses a color string by creating substrings of the input. These string allocations can be removed.
>> 
>> There are no new tests for the `Color` class, since the existing tests already cover all relevant code paths.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSS-compliant double parser

The JavaFX CSS spec states (under <number>):


Real numbers and integers are specified in decimal notation only. ... A <number> can either be an <integer>, or it can be zero or more digits followed by a dot (.) followed by one or more digits. Both integers and real numbers may be preceded by a "-" or "+" to indicate the sign. -0 is equivalent to 0 and is not a negative number.

[+|-]? [[0-9]+|[0-9]*"."[0-9]+]


it looks to me like exponential notation should not be supported.

Mandatory disclaimer: W3C is not a real standard.

I am not sure if we want to change the CSS spec to allow scientific notation in all the <number>s, I don't even sure we want to add this support in `Color.web()`.  If we do though, I think we would need to update the javadoc and possibly the CSS Reference, right?

I must admit I don't know how much changes in `Color.web()` impact CSS parsing.
For example, it looks like `Color.web()` is being called from `CssParser.colorValueOfString(String)` but a simple css like `-fx-background-color: rgb(1);` won't trigger that code.

it's not a real standard in a sense that it is an attempt to write a spec for something that every browser manufacturer want to change to make their browser "better".  maybe the situation changed recently, I don't know.

But I do agree with you - the majority of developers are familiar with it, so it might make sense to adapt in some cases (while keeping in mind possible regressions).

> JavaFX contradicts its own specification, but the specification is (and has always been) wrong anyway.

This is hilarious and concerning at the same time.  I wonder whether we need to update the javadoc / create a CSR since we are changing the behavior.  What do you think?

modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 437:

> 435: 
> 436:             if (len == 3) {
> 437:                 r = Integer.parseInt(colorString, offset, offset + 1, 16);

would a switch statement be better in this case (e.g. case when len == 1)?

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssNumberParserTest.java line 40:

> 38:     @Test
> 39:     public void parseIntegerAndSignedInteger() {
> 40:         assertEquals(0.0, parseDouble("0"), 0.0);

The JavaFX CSS spec also states


-0 is equivalent to 0 and is not a negative number.


How should we test this?

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssNumberParserTest.java line 79:

> 77:         assertNumberFormatException("1 ");
> 78:         assertNumberFormatException("xx1e2yy", 2, 6); // slice is "1e2y"
> 79:     }

maybe add another test for malformed numbers such as `++0`, `1e--2`, etc.?

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssNumberParserTest.java line 270:

> 268:         return rawBits >= 0 ? rawBits : (0x8000_0000_0000_0000L - rawBits);
> 269:     }
> 270: }

missing newline

-------------

PR Review: https://git.openjdk.org/jfx/pull/2069#pullrequestreview-3780071461
PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3880094916
PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3880191468
PR Comment: https://git.openjdk.org/jfx/pull/2069#issuecomment-3880669134
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2789907975
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2789129871
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2789098613
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2788929245

From angorya at openjdk.org  Wed Feb 11 09:57:23 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Feb 2026 09:57:23 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <XIfXjA2bm_5LKNNeF1ftVditVYD-yZ4b7GCoJGjxNTc=.3172e5c5-5279-48a0-adaf-cab6c404e5c2@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
 <FVBgo_14d0_j0C7-HdJzX_JPZHBuDfYTkX7Xv2mXRLs=.c84c2e9a-7b91-4ff6-a531-93ab760d5242@github.com>
 <XIfXjA2bm_5LKNNeF1ftVditVYD-yZ4b7GCoJGjxNTc=.3172e5c5-5279-48a0-adaf-cab6c404e5c2@github.com>
Message-ID: <RuCwOmE3tFIc67cLZ39mJZb9S1DbW3TfAjVDxDBzsyo=.59aa2e4d-a0e1-4109-ab90-58b646d57ce9@github.com>

On Tue, 10 Feb 2026 18:25:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssNumberParserTest.java line 40:
>> 
>>> 38:     @Test
>>> 39:     public void parseIntegerAndSignedInteger() {
>>> 40:         assertEquals(0.0, parseDouble("0"), 0.0);
>> 
>> The JavaFX CSS spec also states
>> 
>> 
>> -0 is equivalent to 0 and is not a negative number.
>> 
>> 
>> How should we test this?
>
> On the JVM, `-0 == 0`. It seems to me that this sentence just spells it out, doesn't it?

I don't know.  The new parser parses "-0.0" as -0.0, and while (-0.0 == 0.0), the result of some other operations is different (1/-0.0 = -Infinity).

Does it constitutes a regression risk for applications?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2789725766

From mstrauss at openjdk.org  Wed Feb 11 09:57:31 2026
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 11 Feb 2026 09:57:31 GMT
Subject: RFR: 8377427: Reduce substring allocations in Color.web(String,
 double) [v2]
In-Reply-To: <RuCwOmE3tFIc67cLZ39mJZb9S1DbW3TfAjVDxDBzsyo=.59aa2e4d-a0e1-4109-ab90-58b646d57ce9@github.com>
References: <CzOjzqiRb-1RoPkyCP_S11zE3nFWBd-2_l6z05G3BYk=.e300539c-a044-4f43-ba45-7d784e9614e7@github.com>
 <IgMufgNGy67cwydVTk235KV7E2Xeh1b-87fMiqGI5Jc=.ab7c82ac-ad93-4325-95d0-6096aa01308c@github.com>
 <FVBgo_14d0_j0C7-HdJzX_JPZHBuDfYTkX7Xv2mXRLs=.c84c2e9a-7b91-4ff6-a531-93ab760d5242@github.com>
 <XIfXjA2bm_5LKNNeF1ftVditVYD-yZ4b7GCoJGjxNTc=.3172e5c5-5279-48a0-adaf-cab6c404e5c2@github.com>
 <RuCwOmE3tFIc67cLZ39mJZb9S1DbW3TfAjVDxDBzsyo=.59aa2e4d-a0e1-4109-ab90-58b646d57ce9@github.com>
Message-ID: <-96rIqTYIKGvVmubGvsZgD9qcAVrrf6S9RQ-lEepxZo=.3304dcb2-f36c-4253-bf5b-718f5c26bd1f@github.com>

On Tue, 10 Feb 2026 19:05:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> On the JVM, `-0 == 0`. It seems to me that this sentence just spells it out, doesn't it?
>
> I don't know.  The new parser parses "-0.0" as -0.0, and while (-0.0 == 0.0), the result of some other operations is different (1/-0.0 = -Infinity).
> 
> Does it constitutes a regression risk for applications?

`CssNumberParser` parses "-0" correctly as -0, just like `Double.parseDouble()` currently does. The existing code in `Color` is unchanged.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2790083018

From angorya at openjdk.org  Wed Feb 11 09:57:21 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Feb 2026 09:57:21 GMT
Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse
 button is none [v4]
In-Reply-To: <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com>
References: <dADoFJEJtoFxB_H0lsXfbPTWSnATO2ZhMxytsYc81tc=.ec3b88c9-79fe-4a61-a14d-5f160b822d74@github.com>
 <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com>
Message-ID: <oYn9mR9kuGBdtvJE6QYLcbM95s4J0nM7D5eZx3G8I-4=.0be0157f-5344-4f89-981b-96dcda3dd21c@github.com>

On Tue, 13 Jan 2026 18:04:40 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

>> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point
>
> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Thank you for adding a test!

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2034#pullrequestreview-3781102756

From crschnick at openjdk.org  Wed Feb 11 09:57:36 2026
From: crschnick at openjdk.org (Christopher Schnick)
Date: Wed, 11 Feb 2026 09:57:36 GMT
Subject: Integrated: 8375070: NPE in Scene.ClickGenerator::preProcess when
 mouse button is none
In-Reply-To: <dADoFJEJtoFxB_H0lsXfbPTWSnATO2ZhMxytsYc81tc=.ec3b88c9-79fe-4a61-a14d-5f160b822d74@github.com>
References: <dADoFJEJtoFxB_H0lsXfbPTWSnATO2ZhMxytsYc81tc=.ec3b88c9-79fe-4a61-a14d-5f160b822d74@github.com>
Message-ID: <tL7k0XzGda5qOJ-uFchcM_bG0uHeeqcw4UXiwZ3oL80=.73f24e02-4f2e-4cee-b075-1374d34668e1@github.com>

On Mon, 12 Jan 2026 22:07:16 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point

This pull request has now been integrated.

Changeset: edc7dee9
Author:    Christopher Schnick <crschnick at openjdk.org>
Committer: Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/edc7dee91c1a3d8418d5f3d2eaf02e3b9ddbd12a
Stats:     16 lines in 2 files changed: 13 ins; 0 del; 3 mod

8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none

Reviewed-by: mstrauss, angorya

-------------

PR: https://git.openjdk.org/jfx/pull/2034

From angorya at openjdk.org  Wed Feb 11 09:57:32 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Feb 2026 09:57:32 GMT
Subject: RFR: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2 [v4]
In-Reply-To: <GZfiVfOZDfSjIKyMpdjkZjUfihELptEOs-5YKShJ470=.8eae1ba4-debb-4fd1-b7b0-cd1b28d1da99@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
 <oiHlb6j3yI0JaVAD5v_frOwOy3TiA08Bxa7K-M7eOR8=.70d5d2a0-c78f-4b5f-bfd9-1814f3f3cb3c@github.com>
 <GZfiVfOZDfSjIKyMpdjkZjUfihELptEOs-5YKShJ470=.8eae1ba4-debb-4fd1-b7b0-cd1b28d1da99@github.com>
Message-ID: <cQXaFO3AFciH-s6iww8GMOrub0TA8ooBXi0pVTpL0QY=.b30bb50f-48ba-4565-9eb5-abfe60e853be@github.com>

On Tue, 10 Feb 2026 10:40:23 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove pointer casting and revert unneeded changes
>
> Since this PR only touches code inside the native-prism-es2/ios subdirectory, one Approval should be enough -- unless @kevinrushforth  or @arapte or @andy-goryachev-oracle disagree?

@johanvos I don't think we can meaningfully review the iOS code here so it's probably up to you (the changes lgtm)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2064#issuecomment-3879641738

From jpereda at openjdk.org  Wed Feb 11 09:57:43 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 11 Feb 2026 09:57:43 GMT
Subject: Integrated: 8377185: [iOS] Native code compiler warnings and error
 building libprism_es2
In-Reply-To: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
References: <1wwvha8HLj1O6c84BR6I8QxY1PUZ2FYlOJh7ONItXcY=.efcc83c4-6d24-441c-ad72-32f14564b6f2@github.com>
Message-ID: <l4qx1b4z1i8urEYdFOJVrvsXA2UXWFrQN8TI6aJ5Jyw=.38288dcc-ec8f-4e9f-b3b7-8342045928ef@github.com>

On Thu, 5 Feb 2026 14:08:17 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes the errors and some warnings that are thrown when building prism_es2 for iOS using clang.

This pull request has now been integrated.

Changeset: 886edfdc
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/886edfdcc82eb9cc7b4aa2460f6b98031c750665
Stats:     16 lines in 5 files changed: 0 ins; 4 del; 12 mod

8377185: [iOS] Native code compiler warnings and error building libprism_es2

Reviewed-by: jvos

-------------

PR: https://git.openjdk.org/jfx/pull/2064

From jpereda at openjdk.org  Wed Feb 11 12:35:58 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 11 Feb 2026 12:35:58 GMT
Subject: RFR: 8377350: [iOS] Add support for UIWindowScene
Message-ID: <-uXW-Px4xbWQcdxVyWjXO3_0FEkh-PRysQzeoACOPmk=.3084633d-a496-430d-836c-ce44342cd148@github.com>

This PR adds support for iOS native window scene, which was added some time ago starting iOS 13 (in 2019).

Current iOS development requires iOS SDK 26, and minimum deployment target is set to iOS 15 (meaning that apps will run on all devices with iOS 15 or greater).

It is safe then to not include the safe-guard `if (@available(iOS 13.0, *)) {...}`, which will make the code more complex.

Adding the native UIScene and UIWindowScene APIs follows the Apple standards, but as a fallback, the deprecated API is still kept there (`keyWindow` was deprecated starting iOS 13, and `initWithFrame:` was deprecated starting iOS 26). This is for a follow-up issue.

Note: This patch doesn't really add support for multiple windows, as this would require more complex changes.

-------------

Commit messages:
 - update copyright
 - Add support for iOS native window scene

Changes: https://git.openjdk.org/jfx/pull/2072/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377350
  Stats: 21 lines in 1 file changed: 13 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/2072.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2072/head:pull/2072

PR: https://git.openjdk.org/jfx/pull/2072

From jvos at openjdk.org  Wed Feb 11 12:38:58 2026
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 11 Feb 2026 12:38:58 GMT
Subject: RFR: 8377350: [iOS] Add support for UIWindowScene
In-Reply-To: <-uXW-Px4xbWQcdxVyWjXO3_0FEkh-PRysQzeoACOPmk=.3084633d-a496-430d-836c-ce44342cd148@github.com>
References: <-uXW-Px4xbWQcdxVyWjXO3_0FEkh-PRysQzeoACOPmk=.3084633d-a496-430d-836c-ce44342cd148@github.com>
Message-ID: <S15WGZc-sBfdkNJMxH2yMR48mISV13nYmI_iNLFsPjo=.9f8ffa2f-b17d-44cc-a87c-24a1350f8b9a@github.com>

On Wed, 11 Feb 2026 12:29:41 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds support for iOS native window scene, which was added some time ago starting iOS 13 (in 2019).
> 
> Current iOS development requires iOS SDK 26, and minimum deployment target is set to iOS 15 (meaning that apps will run on all devices with iOS 15 or greater).
> 
> It is safe then to not include the safe-guard `if (@available(iOS 13.0, *)) {...}`, which will make the code more complex.
> 
> Adding the native UIScene and UIWindowScene APIs follows the Apple standards, but as a fallback, the deprecated API is still kept there (`keyWindow` was deprecated starting iOS 13, and `initWithFrame:` was deprecated starting iOS 26). This is for a follow-up issue.
> 
> Note: This patch doesn't really add support for multiple windows, as this would require more complex changes.

modules/javafx.graphics/src/main/native-glass/ios/GlassWindow.m line 834:

> 832:             GLASS_LOG("SCREEN: %@", screen);
> 833:             CGRect applicationFrame = [screen bounds];
> 834:             GLASS_LOG("FRAME: %.1f %.1f", applicationFrame.size.width, applicationFrame.size.height);

Aren't the dimensions printed when you print the "object" using @ ?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2072#discussion_r2793054687

From jpereda at openjdk.org  Wed Feb 11 12:47:52 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 11 Feb 2026 12:47:52 GMT
Subject: RFR: 8377350: [iOS] Add support for UIWindowScene
In-Reply-To: <S15WGZc-sBfdkNJMxH2yMR48mISV13nYmI_iNLFsPjo=.9f8ffa2f-b17d-44cc-a87c-24a1350f8b9a@github.com>
References: <-uXW-Px4xbWQcdxVyWjXO3_0FEkh-PRysQzeoACOPmk=.3084633d-a496-430d-836c-ce44342cd148@github.com>
 <S15WGZc-sBfdkNJMxH2yMR48mISV13nYmI_iNLFsPjo=.9f8ffa2f-b17d-44cc-a87c-24a1350f8b9a@github.com>
Message-ID: <wWisxZWADRzno2GNQqiCX-F1pfo09fokUA1eGUgfa8U=.b70f30b2-ebf3-4fda-bd10-60ec008e679a@github.com>

On Wed, 11 Feb 2026 12:36:13 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> This PR adds support for iOS native window scene, which was added some time ago starting iOS 13 (in 2019).
>> 
>> Current iOS development requires iOS SDK 26, and minimum deployment target is set to iOS 15 (meaning that apps will run on all devices with iOS 15 or greater).
>> 
>> It is safe then to not include the safe-guard `if (@available(iOS 13.0, *)) {...}`, which will make the code more complex.
>> 
>> Adding the native UIScene and UIWindowScene APIs follows the Apple standards, but as a fallback, the deprecated API is still kept there (`keyWindow` was deprecated starting iOS 13, and `initWithFrame:` was deprecated starting iOS 26). This is for a follow-up issue.
>> 
>> Note: This patch doesn't really add support for multiple windows, as this would require more complex changes.
>
> modules/javafx.graphics/src/main/native-glass/ios/GlassWindow.m line 834:
> 
>> 832:             GLASS_LOG("SCREEN: %@", screen);
>> 833:             CGRect applicationFrame = [screen bounds];
>> 834:             GLASS_LOG("FRAME: %.1f %.1f", applicationFrame.size.width, applicationFrame.size.height);
> 
> Aren't the dimensions printed when you print the "object" using @ ?

No, `CGRect` is a struct, and you get this warning:

warning: format specifies type 'id' but the argument has type 'CGRect' (aka 'struct CGRect') [-Wformat]

which can be safely ignored of course, but then the logs won't show a null value:

FRAME: (null)

and that's why I applied the change.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2072#discussion_r2793088877

From sykora at openjdk.org  Wed Feb 11 13:32:48 2026
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 11 Feb 2026 13:32:48 GMT
Subject: RFR: 8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4
In-Reply-To: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
References: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
Message-ID: <84RiLQDbxn-gcBltOFnY7v5Gye3hrPEtZA3LgJ3oJ9I=.8cc61b42-f221-430b-a1b0-2b6aa38551c2@github.com>

On Wed, 4 Feb 2026 16:15:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates webkit to v2.50.4. Verified build and sanity on mac, windows and linux platforms. No issue seen.

All builds went fine.

-------------

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/2063#pullrequestreview-3784833839

From jvos at openjdk.org  Wed Feb 11 14:22:03 2026
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 11 Feb 2026 14:22:03 GMT
Subject: RFR: 8377350: [iOS] Add support for UIWindowScene
In-Reply-To: <-uXW-Px4xbWQcdxVyWjXO3_0FEkh-PRysQzeoACOPmk=.3084633d-a496-430d-836c-ce44342cd148@github.com>
References: <-uXW-Px4xbWQcdxVyWjXO3_0FEkh-PRysQzeoACOPmk=.3084633d-a496-430d-836c-ce44342cd148@github.com>
Message-ID: <fU20_Mh3Aea7Wzj19zRY3pphGPG7J1HR1PQmaGm7wYw=.2501e84b-c851-45b0-8220-cb9ffae15d90@github.com>

On Wed, 11 Feb 2026 12:29:41 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds support for iOS native window scene, which was added some time ago starting iOS 13 (in 2019).
> 
> Current iOS development requires iOS SDK 26, and minimum deployment target is set to iOS 15 (meaning that apps will run on all devices with iOS 15 or greater).
> 
> It is safe then to not include the safe-guard `if (@available(iOS 13.0, *)) {...}`, which will make the code more complex.
> 
> Adding the native UIScene and UIWindowScene APIs follows the Apple standards, but as a fallback, the deprecated API is still kept there (`keyWindow` was deprecated starting iOS 13, and `initWithFrame:` was deprecated starting iOS 26). This is for a follow-up issue.
> 
> Note: This patch doesn't really add support for multiple windows, as this would require more complex changes.

Looks good. This PR only touches ios-specific files, and does not affect any other platform.

-------------

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2072#pullrequestreview-3785114637

From mfox at openjdk.org  Wed Feb 11 17:07:43 2026
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 11 Feb 2026 17:07:43 GMT
Subject: RFR: 8377426: Adjust scene background to color scheme
In-Reply-To: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
References: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
Message-ID: <NtfjdvQUP1gdOynoUR9XVoplREtujEQEDcsgWfXcDEc=.2614717d-d486-4507-959d-6a838819121f@github.com>

On Sun, 8 Feb 2026 03:30:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a non-opaque scene fill color is used with a stage style other than `StageStyle.TRANSPARENT`, the actual fill color is always white. This doesn't work well when the scene uses a dark color scheme. A practical solution is to allow non-opaque scene fill colors, and blend them on top of a white or black background (depending on color scheme) to derive an opaque color that adapts intuitively to the color scheme.
> 
> To test this, simply create a scene that uses a non-opaque fill color and observe the scene background when the color scheme is changed.
> 
> This PR includes a system test, run it with:
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.SceneFillTest.testSceneFill

When writing a value to the screen and reading it back the components can shift a bit. There's a utility for comparing two colors (assertColorEquals) that allows for a tolerance when comparing the components. You can see sample code for this in SRGBTest.java.

JavaFX specifies colors in the sRGB space which employs a gamma (power) curve. For any given color component Prism presumably converts it to a linear space, performs blending operations, converts back to sRGB, then rounds the result to a byte to hand it off to the OS. Most Macs displays don't use sRGB natively so the byte then gets converted to the display's color space using more math and float <=> byte conversions. Then when the Robot reads the color back a bunch of this process is reversed.

This PR is blending two colors in the sRGB space instead of a linear space. That's a little odd but it seems that other parts of the system do this (I see the Color.interpolate method works in sRGB) so maybe we'll just let it pass.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2068#issuecomment-3885754039

From hmeda at openjdk.org  Wed Feb 11 17:14:03 2026
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 11 Feb 2026 17:14:03 GMT
Subject: Integrated: 8377099: Additional WebKit 623.1 fixes from WebKitGTK
 2.50.4
In-Reply-To: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
References: <XhT8scnqDBMCpbLaQfoHtPe0n0uJoAeuAIB3tbHS774=.50420ecb-2da7-4f13-8102-7e4f41ab9160@github.com>
Message-ID: <PcdBXJChLSb5QMg9XzapkwpVQn82Zy20JCASXkhoI7c=.35369034-5a18-4360-81bf-ed88e979eef4@github.com>

On Wed, 4 Feb 2026 16:15:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates webkit to v2.50.4. Verified build and sanity on mac, windows and linux platforms. No issue seen.

This pull request has now been integrated.

Changeset: 7f012bab
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7f012babb1d342ded5e53b15ce57030a2ad40668
Stats:     692 lines in 75 files changed: 467 ins; 72 del; 153 mod

8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4

Reviewed-by: kcr, sykora

-------------

PR: https://git.openjdk.org/jfx/pull/2063

From mfox at openjdk.org  Wed Feb 11 17:29:25 2026
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 11 Feb 2026 17:29:25 GMT
Subject: RFR: 8377426: Adjust scene background to color scheme
In-Reply-To: <KrTFVDIVIsZPpCQ5m3B03Z9tlr0upzSDQbdvno9-jpE=.515f3301-80f8-40b7-a557-0f5ecfb5e00e@github.com>
References: <bHAQRKxnISU-3wwtzH0GdSkNkKb9QkaINOOXEjMtRHc=.fc304a35-1f01-4395-b519-c883515b1a1f@github.com>
 <KrTFVDIVIsZPpCQ5m3B03Z9tlr0upzSDQbdvno9-jpE=.515f3301-80f8-40b7-a557-0f5ecfb5e00e@github.com>
Message-ID: <mp6YYdu25n5KrZ-cJdGwHjhq9TvyU-BLiT3YG6I_OHY=.30ad5b52-0813-40e8-a1e2-6edf76055045@github.com>

On Tue, 10 Feb 2026 20:38:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> In the dark mode, I do see the screen flickering to white before going to the set color, using the same test with lighter color:
> 
> ```
>         sc.setFill(Color.rgb(255, 255, 255, 0.2));
> ```

Good catch. When the stage is first shown JavaFX takes the scene's fill color and passes it off to the OS to become the window's background color. In the process it throws away the alpha component so here it's setting the background to white. That's what you'll see between the time the window is first made visible and when the rendering thread delivers pixels to the window. You'll also see flashes of the background color while resizing the window. See the calls to platformWindow.setBackground in WindowStage.java.

The Windows code throws this information away. macOS and Linux forward the color on to the platform. Fun fact: you can use this feature to tint the title bar on macOS.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2068#issuecomment-3885866849

From angorya at openjdk.org  Wed Feb 11 19:55:28 2026
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 11 Feb 2026 19:55:28 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
Message-ID: <grV9d9wPheY10bPBlgvT8BFsaA93M8HiVcfV4h2J92M=.6f359bc3-a2b6-4cea-b3d7-60701587871f@github.com>

On Tue, 25 Nov 2025 18:58:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> This enhancement allows `Stage` to be placed on the screen similar to a popup window, where a user-specified positioning anchors defines a point on the stage that should coincide with a given location on the screen. For this purpose, the following new methods are added to `Stage`:
> 
> 
> public class Stage {
>     public void relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);
>     public void relocate(AnchorPoint screenAnchor, Insets screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
>     public void relocate(Screen, AnchorPoint screenAnchor, Insets screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
> }
> 
> 
> ## AnchorPoint
> `AnchorPoint` is a point that is either specified in absolute coordinates, or relative to the screen or stage:
> 
> var anchor1 = AnchorPoint.proportional(0.5, 0.5); // center of the screen/stage
> var anchor2 = AnchorPoint.absolute(100, 100); // absolute coordinates within screen/stage
> 
> 
> For example, a stage that sits flush with the bottom-right corner of the screen can be shown as follows:
> 
> var screenAnchor = AnchorPoint.proportional(1, 1); // or use the AnchorPoint.BOTTOM_RIGHT constant
> var stageAnchor = AnchorPoint.proportional(1, 1);
> stage.relocate(screenAnchor, stageAnchor);
> stage.show();
> 
> 
> ## AnchorPolicy
> `AnchorPolicy` controls how the anchor may be adjusted when the preferred placement doesn't fit within the screen bounds:
> 
> 
> public enum AnchorPolicy {
>     FIXED,
>     FLIP_HORIZONTAL,
>     FLIP_VERTICAL,
>     AUTO
> }
> 
> 
> * `FIXED`: always use the provided anchor; only adjust the resulting position to fit within the screen.
> * `FLIP_HORIZONTAL`: if the preferred placement violates horizontal constraints, try a horizontally flipped anchor (e.g. top-left to top-right) before falling back to the original anchor.
> * `FLIP_VERTICAL`: likewise for vertical constraints.
> * `AUTO`: automatically choose the most suitable flip:
>    if only horizontal constraints are violated, acts like `FLIP_HORIZONTAL`;
>    if only vertical constraints are violated, acts like `FLIP_VERTICAL`;
>    if both are violated, try a diagonally flipped anchor (both axes) and pick the placement that requires the least adjustment.
> 
> This is useful for popup-like behavior where you have a preferred "opening direction", but want the window to flip to the opposite side of the reference point when there isn?t enough space (e.g. "prefer below, but open above if below doesn?t fit").
> 
> ### PopupWindow support
> The new `PopupWindow.anchorPolicy` property adds the same "flip the anchor when it...

@mstr2 do you want to reopen this PR?  I think it'll be very useful.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1986#issuecomment-3886706303

From jpereda at openjdk.org  Wed Feb 11 20:57:06 2026
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 11 Feb 2026 20:57:06 GMT
Subject: RFR: 8377706: [iOS] UI API called on a background thread: UIView layer
Message-ID: <o9KqfSiPGcWfdIXoEOoivD_vUQCKtf3E18QNVs0sdnM=.2cea88ed-fe31-4d06-a271-40a0443f2678@github.com>

This PR adds a thread check to verify that native iOS UI code runs on the main thread, in a similar way as how `(void)setFrame:(CGRect)boundsRect` calls `_setBounds()`.

-------------

Commit messages:
 - rename function
 - Move native iOS UI code to main thread

Changes: https://git.openjdk.org/jfx/pull/2073/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2073&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377706
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/2073.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2073/head:pull/2073

PR: https://git.openjdk.org/jfx/pull/2073

From hmeda at openjdk.org  Thu Feb 12 07:12:30 2026
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 12 Feb 2026 07:12:30 GMT
Subject: [jfx26u] RFR: 8377099: Additional WebKit 623.1 fixes from WebKitGTK
 2.50.4
Message-ID: <8LwwmQg-4RkBcbKXDvgjdlMOXLjelEQ208KnapLzEAE=.5d5fdfd1-8633-458f-b915-cd76d1ab674d@github.com>

Clean Backport

-------------

Commit messages:
 - Backport 7f012babb1d342ded5e53b15ce57030a2ad40668

Changes: https://git.openjdk.org/jfx26u/pull/8/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx26u&pr=8&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377099
  Stats: 692 lines in 75 files changed: 467 ins; 72 del; 153 mod
  Patch: https://git.openjdk.org/jfx26u/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/8/head:pull/8

PR: https://git.openjdk.org/jfx26u/pull/8

From hmeda at openjdk.org  Thu Feb 12 07:14:54 2026
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 12 Feb 2026 07:14:54 GMT
Subject: [jfx26u] Integrated: 8377099: Additional WebKit 623.1 fixes from
 WebKitGTK 2.50.4
In-Reply-To: <8LwwmQg-4RkBcbKXDvgjdlMOXLjelEQ208KnapLzEAE=.5d5fdfd1-8633-458f-b915-cd76d1ab674d@github.com>
References: <8LwwmQg-4RkBcbKXDvgjdlMOXLjelEQ208KnapLzEAE=.5d5fdfd1-8633-458f-b915-cd76d1ab674d@github.com>
Message-ID: <2znhWIK5YpyqlR1eK0i0Iwc5zfCdD-ynHC3tBoUecZ8=.d7099d83-86f4-458c-9766-a6ef03050e30@github.com>

On Thu, 12 Feb 2026 07:04:52 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: 000879c1
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx26u/commit/000879c1b1bcb4ffd7d5f49c334782610ce26b0c
Stats:     692 lines in 75 files changed: 467 ins; 72 del; 153 mod

8377099: Additional WebKit 623.1 fixes from WebKitGTK 2.50.4

Backport-of: 7f012babb1d342ded5e53b15ce57030a2ad40668

-------------

PR: https://git.openjdk.org/jfx26u/pull/8