From arapte at openjdk.org  Mon Dec  1 08:54:13 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 1 Dec 2025 08:54:13 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset [v3]
In-Reply-To: <3sUDDeRx4lDjC_zky1Ktckb2Fj6Kmn3YxSt4CbpiBEk=.d0a90b74-b331-4977-9c7d-e7619fceeced@github.com>
References: <WhQxKkSqouIsB25qSiDzg2i-HAJpLEiEHMKKx8KZ8r0=.f168f6d0-9e60-4bcc-a891-bdc8e4e0201d@github.com>
 <3sUDDeRx4lDjC_zky1Ktckb2Fj6Kmn3YxSt4CbpiBEk=.d0a90b74-b331-4977-9c7d-e7619fceeced@github.com>
Message-ID: <-jo5DEwkUoFhC7pFvp91GbYw6dCOVO5QSsg94Lj-MUk=.bca14e2e-5bd3-4e41-837a-e75257838f2f@github.com>

On Fri, 28 Nov 2025 15:50:23 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because the skin marks the button cell as ?empty? when the value becomes null.
>> With the fix clearing the ComboBox value re-shows the prompt text.
>> Tested using the code present in the bug.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test

lgtm+..

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1989#pullrequestreview-3523856091

From arapte at openjdk.org  Mon Dec  1 10:31:50 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 1 Dec 2025 10:31:50 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
Message-ID: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>

Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)

Under this change, there are two factors that affect our zip files.
1. Files have fixed timestamps (timestamps depends on the archive type).
2. File order in the archive is now deterministic.
Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.

the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.

Verified that for all files extracted from generated zip files:
1. Timestamp is now not fixed, and reflects the CREATION date.
2. The file permissions are unchanged.

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

Commit messages:
 - File timestamp

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

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

From zelmidaoui at openjdk.org  Mon Dec  1 11:55:14 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 1 Dec 2025 11:55:14 GMT
Subject: RFR: 8296653: ComboBox promptText is not displayed when the value
 is reset [v3]
In-Reply-To: <3sUDDeRx4lDjC_zky1Ktckb2Fj6Kmn3YxSt4CbpiBEk=.d0a90b74-b331-4977-9c7d-e7619fceeced@github.com>
References: <WhQxKkSqouIsB25qSiDzg2i-HAJpLEiEHMKKx8KZ8r0=.f168f6d0-9e60-4bcc-a891-bdc8e4e0201d@github.com>
 <3sUDDeRx4lDjC_zky1Ktckb2Fj6Kmn3YxSt4CbpiBEk=.d0a90b74-b331-4977-9c7d-e7619fceeced@github.com>
Message-ID: <P6IF-R913WChBoKXhb_VQvIr858l5Qs2n9kBvli-Va4=.58b42507-7f78-4257-813e-bd01fcb33014@github.com>

On Fri, 28 Nov 2025 15:50:23 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because the skin marks the button cell as ?empty? when the value becomes null.
>> With the fix clearing the ComboBox value re-shows the prompt text.
>> Tested using the code present in the bug.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test

Thanks for the reviews

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

PR Comment: https://git.openjdk.org/jfx/pull/1989#issuecomment-3596114947

From zelmidaoui at openjdk.org  Mon Dec  1 11:55:15 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 1 Dec 2025 11:55:15 GMT
Subject: Integrated: 8296653: ComboBox promptText is not displayed when the
 value is reset
In-Reply-To: <WhQxKkSqouIsB25qSiDzg2i-HAJpLEiEHMKKx8KZ8r0=.f168f6d0-9e60-4bcc-a891-bdc8e4e0201d@github.com>
References: <WhQxKkSqouIsB25qSiDzg2i-HAJpLEiEHMKKx8KZ8r0=.f168f6d0-9e60-4bcc-a891-bdc8e4e0201d@github.com>
Message-ID: <1a8IpDZ5RuQ4ty79TWZTjNxUMSaDu8DfkDwH_pkb8AU=.bf9971bb-5622-4129-b17b-f7f8c5da9678@github.com>

On Wed, 26 Nov 2025 16:11:52 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurred because the skin marks the button cell as ?empty? when the value becomes null.
> With the fix clearing the ComboBox value re-shows the prompt text.
> Tested using the code present in the bug.

This pull request has now been integrated.

Changeset: 3043e91b
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3043e91b241e0307f01d3376b7549663f6df6f7c
Stats:     36 lines in 2 files changed: 36 ins; 0 del; 0 mod

8296653: ComboBox promptText is not displayed when the value is reset

Reviewed-by: arapte, mhanl

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

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

From zelmidaoui at openjdk.org  Mon Dec  1 12:44:06 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 1 Dec 2025 12:44:06 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode
In-Reply-To: <3OAXiv2TJygQrlInQuFiqq1RQWkEKKZdgEdD6e4-ma8=.dc7805f8-ef33-41c7-b21f-bf517aaad4cd@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
 <3OAXiv2TJygQrlInQuFiqq1RQWkEKKZdgEdD6e4-ma8=.dc7805f8-ef33-41c7-b21f-bf517aaad4cd@github.com>
Message-ID: <uq5R31n-91jjJlBqVyneb47WKKczj6_9GapfPHgQRPQ=.243bfe36-ea31-4565-b8de-2c6173eeced4@github.com>

On Wed, 26 Nov 2025 21:12:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> @Ziad-Mid do you think this fix is independent of ([JDK-8318095](https://bugs.openjdk.org/browse/JDK-8318095)

I am checking the JDK-8318095 with more tests, but a first thought they look independant to me. I will check both and let you know.

> Can this be tested with a JUnit Test? 

I am working on a JUnit Test for this bug as suggested .

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

PR Comment: https://git.openjdk.org/jfx/pull/1988#issuecomment-3596360142

From kcr at openjdk.org  Mon Dec  1 13:25:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 13:25:05 GMT
Subject: RFR: 8372453: [macOS] Iconifying owner may not iconify owned
 window
In-Reply-To: <m01gA3GDO_4TGce4ktP39QHP8YLVUhtAMa1V_cnpcR0=.c290f5e6-e938-437f-8bb8-737a5b776436@github.com>
References: <lXK1QKhf16dWK8-RxKnuOCvglyAqfCjQVH4aCreZSHE=.2ab48e2f-e9f5-4629-8789-0d70ad90a5ed@github.com>
 <m01gA3GDO_4TGce4ktP39QHP8YLVUhtAMa1V_cnpcR0=.c290f5e6-e938-437f-8bb8-737a5b776436@github.com>
Message-ID: <Ml-n3QEKgGHOf7HnvELpOS1K6E7PkQ7l9BSQ1RHgsFM=.d4878082-89cc-4523-85ea-ba168427d534@github.com>

On Wed, 26 Nov 2025 21:35:08 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> In the macOS glass code an owned window is referred to as a child window and its owner is referred to as the parent. When a parent is iconified the glass code "iconifies" its children which is to say it hides them. Under the right circumstances the children may get ordered back to the front and made visible almost immediately.
>> 
>> Details are in the bug report but when a window is iconified it may trigger the OS to notify every window that its NSScreen has changed (yes, this is weird). This causes reorderChildWindows to be called on the newly iconified parent and the process of re-ordering the child windows can cause hidden windows to be made visible. For some reason the NSScreen strangeness only happens if "System Settings > Desktop & Dock > Minimize windows into application icon" is turned OFF. This is not the first time we've encountered this, see [JDK-8353902](https://bugs.openjdk.org/browse/JDK-8353902)
>> 
>> This PR fixes the problem in two ways. If reorderChildWindows is called on an iconified window it does nothing. If one of the child windows is hidden it is not re-ordered since that might make it visible.
>
> I've been testing on macOS 15 so maybe Apple fixed this in 26. When I finally make peace with Liquid Glass and install 26 I'll do some additional testing.

@beldenfox Would you be willing to backport this to `jfx25u`? If so, navigate to commit 6234c07e0e7ef84145e8a17407bf983ddba13d05 and enter `/backport jfx25u` as a comment and follow the instructions. If you're not able to, I'll get someone else to backport it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1985#issuecomment-3596529907

From kcr at openjdk.org  Mon Dec  1 14:42:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 14:42:54 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
References: <wf49A9Cv05TOHVrHB13numUo2qfwyrg-UnvUbc1JS6M=.26a864df-3429-43fb-85e9-a9e0b52eb7bc@github.com>
 <Vg6y2XoT0s-zXM6hI3Lcas6VXGhCouWGHHb9DACRSLQ=.a36939a5-8fe7-4309-933e-959336a92e57@github.com>
 <C-fprMy8fhJH4o7kSvcD9w4-E1547ARZcofiKykNzzo=.5d8f67ed-4624-4f37-a17a-d55baddb1232@github.com>
 <CC-SPDELW9jsPu3evQb0V5gZT5czmB5eB_MyQ_zE3d4=.6936067a-2342-4153-ba78-5c6b2f7a4df3@github.com>
 <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
Message-ID: <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>

On Thu, 27 Nov 2025 11:06:42 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > However, I also note that with this patch, even `gradle all` doesn't create `build/publications`. Consider adding a dependency to either `gradle sdk` or, more likely, `gradle all` so that still creates `build/publications`.
> 
> Thanks for testing! Just so we have a common understanding: Depending on the `all` task seems to be a better choice than `sdk`? I guess because then we are sure that everything did run before, right?

Either is fine, but having the `all` task depend on it seems a better choice (the fact that the `sdk` task currently depends on it seems somewhat arbitrary).

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3596901343

From jgneff at openjdk.org  Mon Dec  1 16:01:49 2025
From: jgneff at openjdk.org (John Neffenger)
Date: Mon, 1 Dec 2025 16:01:49 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
In-Reply-To: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
Message-ID: <gMoMhFqplMmePYzT2Z6GnkAsGrVyCzdjlyB-_HA-8SE=.abde6e60-590d-4db0-8129-b878519d3f62@github.com>

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)
> 
> Under this change, there are two factors that affect our zip files.
> 1. Files have fixed timestamps (timestamps depends on the archive type).
> 2. File order in the archive is now deterministic.
> Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.
> 
> the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.
> 
> Verified that for all files extracted from generated zip files:
> 1. Timestamp is now not fixed, and reflects the CREATION date.
> 2. The file permissions are unchanged.

Why don't we instead start building JavaFX in a reproducible manner? I've been creating reproducible [builds of JavaFX][1] for years now (with the caveat of [this bug][2]). Those builds have over 2,000 active users without any reported problems. I set the following environment variable before calling `gradlew`:


# Sets the environment variable for reproducible builds
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH


Doing so now can only help Johan's efforts to replace the Gradle build with its JDK-based alternative.

[1]: https://snapcraft.io/openjfx
[2]: https://bugs.openjdk.org/browse/JDK-8307082

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

PR Comment: https://git.openjdk.org/jfx/pull/1993#issuecomment-3597360213

From kcr at openjdk.org  Mon Dec  1 16:38:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 16:38:01 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
In-Reply-To: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
Message-ID: <crnhyXRzqrQs45P0R3PK8KLlNAvNFLmwLVpN9wdcfoU=.603e2543-aa22-4acb-a917-91c71368c0e0@github.com>

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)
> 
> Under this change, there are two factors that affect our zip files.
> 1. Files have fixed timestamps (timestamps depends on the archive type).
> 2. File order in the archive is now deterministic.
> Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.
> 
> the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.
> 
> Verified that for all files extracted from generated zip files:
> 1. Timestamp is now not fixed, and reflects the CREATION date.
> 2. The file permissions are unchanged.

It isn't an either-or. Since we aren't going to require the setting of SOURCE_DATE_EPOCH, we need to fix the timestamps when it isn't set.

Separately, it would be a good idea to start using it for our builds. I'll file an RFE to do that. Perhaps it's worth considering for JavaFX 27 (so that we start using it early in the release cycle).

> SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)

We wouldn't do it exactly as you suggest for a number of reasons, but as part of using it for our build, we would publish the `SOURCE_DATE_EPOCH` that we used.

@arapte Have you tested this with `SOURCE_DATE_EPOCH` to ensure no regressions in that mode?

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1993#issuecomment-3597566723

From angorya at openjdk.org  Mon Dec  1 17:23:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 17:23:49 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v9]
In-Reply-To: <QwQJ8Ctc3RSVbAeRRaDyMm-MBYjYSlJMC22I_F-cL_M=.4ba69235-b7e0-40f9-abc5-085df8cbcd6d@github.com>
References: <w1BA5TKZERJD_3f7f9pLxq_JzT4YuTybzLb9cpNHqn0=.f7103c02-e8c6-4826-8b3c-64c206b0c811@github.com>
 <QwQJ8Ctc3RSVbAeRRaDyMm-MBYjYSlJMC22I_F-cL_M=.4ba69235-b7e0-40f9-abc5-085df8cbcd6d@github.com>
Message-ID: <k2pNWVcr1vOrz7QilX_lMfzDnbNdE2TT2ZlmZjhNcO0=.f90a1acf-225d-4ac4-ab25-4d04acbd99db@github.com>

On Thu, 27 Nov 2025 12:46:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> <img src="https://github.com/user-attachments/assets/73aac0d4-0185-47c5-8791-bdb247eb69c8" width="400"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1977#pullrequestreview-3526151437

From lkostyra at openjdk.org  Mon Dec  1 17:28:46 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 1 Dec 2025 17:28:46 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v70]
In-Reply-To: <xUE2StUyDV6ygK8wkCa-kmKvaKDQH1vB-XN20dZa0Ms=.c8562511-21a8-46dc-aea0-300ca2bcc1b4@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <xUE2StUyDV6ygK8wkCa-kmKvaKDQH1vB-XN20dZa0Ms=.c8562511-21a8-46dc-aea0-300ca2bcc1b4@github.com>
Message-ID: <YnASUFd2eMSicgjYrZJW94aUxqzVQlLMs20qQI3ivJc=.a426b482-6623-45e3-b8ea-c7b726b5532f@github.com>

On Tue, 11 Nov 2025 11:49:21 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 84 commits:
> 
>  - 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
>  - Revert "8367898: Skip StageFocusTest on Linux"
>    
>    This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
>  - Merge branch 'master' into 8354943
>  - Remove unused imports
>  - - Fix StageOwnershipTest label + minor adjustments
>  - ... and 74 more: https://git.openjdk.org/jfx/compare/013e55b1...7871e08b

Marked as reviewed by lkostyra (Reviewer).

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

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

From mfox at openjdk.org  Mon Dec  1 18:03:18 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 1 Dec 2025 18:03:18 GMT
Subject: RFR: 8326428: [Linux] UI scaling factor cannot be fractional when
 using KDE
Message-ID: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>

The standard way to determine the user interface scaling factor on Linux is to consult the reported monitor DPI and divide by 96 (which is also the way it's done on Windows). This allows the scaling factor to vary per-monitor and also achieve fractional values.

Before this became the standard the Gnome toolkit communicated the scaling factor using the "GDK_SCALE" environment variable or the "org.gnome.desktop.interface" "scaling-factor" gsetting. These were always integer values (no fractional scaling) and applied to all monitors. They became the de-facto way of communicating the scaling factor and were picked  by various toolkits including JavaFX. They are now obsolete within Gnome.

JavaFX will compute correct per-monitor scaling factors if GDK_SCALE and "scaling-factor" aren't set. Gnome no longer sets these but unfortunately the KDE desktop does in an attempt to get certain apps to scale (one bug report specifically called out IntelliJ). In KDE for Ubuntu 24 the "scaling-factor" is always set to the floor of the actual scaling factor which is preventing JavaFX from computing fractional scales. Either setting will prevent JavaFX from computing per-monitor scales.

This PR changes the priority of the ui scale tests. As always, the JavaFX "glass.gtk.uiScale" setting takes precedence. If that's not set the system uses the scaling computed based on the monitor DPI. It only consults the legacy settings if the reported DPI is 96.

Ignoring GDK_SCALE is problematic since there are certainly users who use this as a convenient way to influence JavaFX (if only to work around this bug). If we want to provide an environment variable for them we should create our own and not rely on the legacy variables of other toolkits.

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

Commit messages:
 - Prioritize DPI-based scaling factor over legacy global variables

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

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

From mfox at openjdk.org  Mon Dec  1 18:56:05 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 1 Dec 2025 18:56:05 GMT
Subject: [jfx25u] RFR: 8372453: [macOS] Iconifying owner may not iconify owned
 window
Message-ID: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>

8372453: [macOS] Iconifying owner may not iconify owned window

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

Commit messages:
 - Backport 6234c07e0e7ef84145e8a17407bf983ddba13d05

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

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

From kcr at openjdk.org  Mon Dec  1 19:05:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 19:05:08 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
In-Reply-To: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
Message-ID: <TFfMBF0u8t7BCSguLMH6DJ0iZDKAIzkMZr6rO4rTQv0=.88c570eb-fa6e-49ee-8f74-f256c16a579a@github.com>

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)
> 
> Under this change, there are two factors that affect our zip files.
> 1. Files have fixed timestamps (timestamps depends on the archive type).
> 2. File order in the archive is now deterministic.
> Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.
> 
> the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.
> 
> Verified that for all files extracted from generated zip files:
> 1. Timestamp is now not fixed, and reflects the CREATION date.
> 2. The file permissions are unchanged.

All testing looks good, including with / without `SOURCE_DATE_EPOCH`.

Please confirm that you have done a CI build.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1993#pullrequestreview-3526547012

From kcr at openjdk.org  Mon Dec  1 19:07:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 19:07:04 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene
In-Reply-To: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
Message-ID: <cqylvScypkgCGDXDSEFSTYKoLxTMsOOj5x5phLCUUtg=.f2f9333d-fdfb-451f-ae7f-99da0c9b9fc2@github.com>

On Sun, 30 Nov 2025 03:25:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
> 
> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
> 
> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
> 
> 
> public class ZeroSizeSubScene extends Application {
> 
>     @Override
>     public void start(Stage stage) {
>         var rect = new Rectangle(50, 50, Color.RED);
>         var subScene = new SubScene(new Group(rect), 100, 100);
>         subScene.setFill(Color.GRAY);
> 
>         // Also try a perspective camera:
>         //
>         // var camera = new PerspectiveCamera();
>         // camera.setRotate(45);
>         // camera.setTranslateX(-20);
>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>         // subScene.setCamera(camera);
> 
>         class MyButton extends Button {
>             public MyButton(String text, double width, double height) {
>                 super(text);
>                 setOnAction(_ -> {
>                     var timeline = new Timeline(
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
> 
>                     timeline.setOnFinished(_ -> {
>                         Point2D p0 = rect.localToScreen(0, 0);
>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>                     });
> 
>                     timeline.play();
>                 });
>             }
>         }
> 
>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
> 
>         var root = new VBox(5,
>             subScene,
>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>             new MyButton("Size: 100x100", 100, 100),
>             new MyButton("Size: 10x10", 10, 10),
>             new MyButton("Size: 100x0", 100, 0),
>             new MyButton("Size: 0x100", 0, 100),
>             new MyButton("Size: 0x0", 0, 0)
>         );
> 
>         S...

I took a quick look and it seems reasonable. I'll let others formally review it, though.

Reviewers: @arapte @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1992#issuecomment-3598407188

From kcr at openjdk.org  Mon Dec  1 19:10:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 19:10:00 GMT
Subject: RFR: 8326428: [Linux] UI scaling factor cannot be fractional when
 using KDE
In-Reply-To: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
References: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
Message-ID: <5R-UH898_zME00Q6aEf4nMkREJw7OsgVnJ_MQfNutS8=.97b3a509-7906-43b2-b520-9c87b7e86582@github.com>

On Mon, 1 Dec 2025 17:57:30 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The standard way to determine the user interface scaling factor on Linux is to consult the reported monitor DPI and divide by 96 (which is also the way it's done on Windows). This allows the scaling factor to vary per-monitor and also achieve fractional values.
> 
> Before this became the standard the Gnome toolkit communicated the scaling factor using the "GDK_SCALE" environment variable or the "org.gnome.desktop.interface" "scaling-factor" gsetting. These were always integer values (no fractional scaling) and applied to all monitors. They became the de-facto way of communicating the scaling factor and were picked  by various toolkits including JavaFX. They are now obsolete within Gnome.
> 
> JavaFX will compute correct per-monitor scaling factors if GDK_SCALE and "scaling-factor" aren't set. Gnome no longer sets these but unfortunately the KDE desktop does in an attempt to get certain apps to scale (one bug report specifically called out IntelliJ). In KDE for Ubuntu 24 the "scaling-factor" is always set to the floor of the actual scaling factor which is preventing JavaFX from computing fractional scales. Either setting will prevent JavaFX from computing per-monitor scales.
> 
> This PR changes the priority of the ui scale tests. As always, the JavaFX "glass.gtk.uiScale" setting takes precedence. If that's not set the system uses the scaling computed based on the monitor DPI. It only consults the legacy settings if the reported DPI is 96.
> 
> Ignoring GDK_SCALE is problematic since there are certainly users who use this as a convenient way to influence JavaFX (if only to work around this bug). If we want to provide an environment variable for them we should create our own and not rely on the legacy variables of other toolkits.

Reviewers: @lukostyra @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1994#issuecomment-3598417881

From angorya at openjdk.org  Mon Dec  1 19:15:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 19:15:19 GMT
Subject: RFR: 8092379: GridPane should not render extra gaps when entire
 rows or columns are unmanaged [v4]
In-Reply-To: <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
Message-ID: <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>

On Sat, 29 Nov 2025 20:51:38 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fixes a long standing bug with `GridPane` where unmanaged nodes would still result in gaps being added between rows/columns even though nothing is rendered there.  Take the following grid where dashes and pipes represent the vgaps and hgaps:
>> 
>> |            |0| |1|
>> |--------|---|---|---|
>> |0  |A|||B|
>> |    |-|||-|
>> |1  |C|||D|
>> |    |-|||-|
>> |2  |E|||F|
>> 
>> Now, when both C and D are set to unmanaged (and invisible) the grid will **still** render the gaps:
>> 
>> |            |0| |1|
>> |--------|---|---|---|
>> |0  |A|||B|
>> |    |-|||-|
>> |1  |||||
>> |    |-|||-|
>> |2  |E|||F|
>> 
>> Instead it should collapse the gap between row 0 and 2:
>> 
>> |            |0| |1|
>> |--------|---|---|---|
>> |0  |A|||B|
>> |    |-|||-|
>> |2  |E|||F|
>> 
>> There are at least two relevant issues in JBS:
>> - A request to let the user show and hide rows and columns: https://bugs.openjdk.org/browse/JDK-8136901
>>   - This can now be done by setting the relevant row/columns items to unmanaged without having to restructure the grid (assuming the complaint was that otherwise there'd be visible extra gaps for each hidden row)
>> - A request for another mode to skip gaps when entire rows/columns are unmanaged: https://bugs.openjdk.org/browse/JDK-8092379
>>   - This should not be a mode, but the standard, as unmanaged nodes should not affect the outcome of the grid layout
>> 
>> Screenshots
>> 
>> Simple application which can hide row 3:
>> 
>> <img width="443" height="491" alt="image" src="https://github.com/user-attachments/assets/0342dba3-cd1c-4d9e-9451-e9c8c628b2e2" />
>> 
>> Correct behavior when row 3 is hidden:
>> 
>> <img width="443" height="408" alt="image" src="https://github.com/user-attachments/assets/c7c54414-6a03-43e4-b733-21d0b251d729" />
>> 
>> Behavior before this fix (note the double gap **and** extra grid line):
>> 
>> <img width="443" height="453" alt="image" src="https://github.com/user-attachments/assets/f357e68a-e950-42e7-890b-91a78e194dd0" />
>
> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   When all nodes starting in a row or column are unmanaged, skip gap

Looks good.

I've updated the standalone Monkey Tester to add a couple of layout scenarios to the GridPane page.

modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 2635:

> 2633: 
> 2634:         private void setMaxSize(int position, double size) {
> 2635:             singleSizes[position] = Math.max(singleSizes[position], size);

I don't know why github shows this as a change.
Unused `setMultiSize()` has been removed which is ok.

modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 2640:

> 2638:         private Iterable<Entry<Interval, Double>> multiSizes() {
> 2639:             if (multiSizes == null) {
> 2640:                 return Collections.emptyList();

unrelated change, and probably gets inlined anyway.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1990#pullrequestreview-3526569032
PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2578295713
PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2578297744

From angorya at openjdk.org  Mon Dec  1 19:16:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 19:16:09 GMT
Subject: [jfx25u] RFR: 8372453: [macOS] Iconifying owner may not iconify
 owned window
In-Reply-To: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
References: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
Message-ID: <2JQFLnbUFZ26ftis3vWAzv7ceiulqk-zhnlVy6aazvc=.65623e6e-9c58-4b23-8624-99954ef30716@github.com>

On Mon, 1 Dec 2025 18:49:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

> 8372453: [macOS] Iconifying owner may not iconify owned window

Why did macOS x64 GHA build fail?

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

PR Comment: https://git.openjdk.org/jfx25u/pull/38#issuecomment-3598441307

From mfox at openjdk.org  Mon Dec  1 19:31:06 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 1 Dec 2025 19:31:06 GMT
Subject: [jfx25u] RFR: 8372453: [macOS] Iconifying owner may not iconify
 owned window
In-Reply-To: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
References: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
Message-ID: <CLbW0Ip4A6T1CN2Q08OR_rnFr6Kf63Z-QzbNjBPt74U=.d945c4e0-98bf-4503-b95d-60af243ab580@github.com>

On Mon, 1 Dec 2025 18:49:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

> 8372453: [macOS] Iconifying owner may not iconify owned window

Failure seems unrelated to the source change which compiled successfully.

>  Could not resolve all files for configuration ':swt:compileClasspath'.
> Could not resolve :org.eclipse.swt.cocoa.macosx.x86_64_3.124.200.v20231113-1355.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/38#issuecomment-3598495012

From kcr at openjdk.org  Mon Dec  1 19:32:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 19:32:06 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v9]
In-Reply-To: <QwQJ8Ctc3RSVbAeRRaDyMm-MBYjYSlJMC22I_F-cL_M=.4ba69235-b7e0-40f9-abc5-085df8cbcd6d@github.com>
References: <w1BA5TKZERJD_3f7f9pLxq_JzT4YuTybzLb9cpNHqn0=.f7103c02-e8c6-4826-8b3c-64c206b0c811@github.com>
 <QwQJ8Ctc3RSVbAeRRaDyMm-MBYjYSlJMC22I_F-cL_M=.4ba69235-b7e0-40f9-abc5-085df8cbcd6d@github.com>
Message-ID: <DE4jZS7Rp5wqKMEb4L2rjtf1spL5PYSMVvl7q1Mwjco=.400fc2d9-1dc9-4371-a89c-cbea653e003f@github.com>

On Thu, 27 Nov 2025 12:46:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> <img src="https://github.com/user-attachments/assets/73aac0d4-0185-47c5-8791-bdb247eb69c8" width="400"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Latest doc changes look good.

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

PR Review: https://git.openjdk.org/jfx/pull/1977#pullrequestreview-3526631435

From kcr at openjdk.org  Mon Dec  1 19:50:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Dec 2025 19:50:07 GMT
Subject: [jfx25u] RFR: 8372453: [macOS] Iconifying owner may not iconify
 owned window
In-Reply-To: <CLbW0Ip4A6T1CN2Q08OR_rnFr6Kf63Z-QzbNjBPt74U=.d945c4e0-98bf-4503-b95d-60af243ab580@github.com>
References: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
 <CLbW0Ip4A6T1CN2Q08OR_rnFr6Kf63Z-QzbNjBPt74U=.d945c4e0-98bf-4503-b95d-60af243ab580@github.com>
Message-ID: <RyHi9WHwcP2eSP-xncMTndsIhf1xaTk70trbHIFCsI0=.71a826b3-f1a7-4ccc-950a-2c12947329c0@github.com>

On Mon, 1 Dec 2025 19:28:17 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Failure seems unrelated to the source change which compiled successfully.
> 
> > Could not resolve all files for configuration ':swt:compileClasspath'.
> > Could not resolve :org.eclipse.swt.cocoa.macosx.x86_64_3.124.200.v20231113-1355.

Definitely unrelated. I triggered a rerun of the GHA build for sanity testing.

@beldenfox Can you request Maintainer approval using the `/approval request` Skara PR command? I'll then approve it.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/38#issuecomment-3598561760

From andy.goryachev at oracle.com  Mon Dec  1 20:10:25 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 1 Dec 2025 20:10:25 +0000
Subject: Some feature requests/improvement suggestions for the JavaFX Font
 API
In-Reply-To: <CAJL5A3=O9zpgbi35ah6bgN7OT1j=NrHp1Ouc_3TOZpsiLc3pnw@mail.gmail.com>
References: <CAJL5A3mM7A_nJTPzduzZoqiPgAaQMLcOrY_zWOj+y-pmqWXnpg@mail.gmail.com>
 <CAJL5A3=O9zpgbi35ah6bgN7OT1j=NrHp1Ouc_3TOZpsiLc3pnw@mail.gmail.com>
Message-ID: <CY8PR10MB7265877D05406928E53C98B8E5DBA@CY8PR10MB7265.namprd10.prod.outlook.com>

We do care.

Presently, there is a number of tickets in JBS complaining about fonts, for example


JDK-8344037<https://bugs.openjdk.org/browse/JDK-8344037> Font.loadFont() loads light/thin fonts as fonts with distinct families.

JDK-8087799<https://bugs.openjdk.org/browse/JDK-8087799> Unable to choose semibold fonts using CSS font-weight

JDK-8310565<https://bugs.openjdk.org/browse/JDK-8310565> [macos]When setting the font family for text, the Regular font is not being used

JDK-8209435<https://bugs.openjdk.org/browse/JDK-8209435> [macOS] Text with bold font weight rendered as normal text when TTC font is used

JDK-8310663<https://bugs.openjdk.org/browse/JDK-8310663> CSS parser can read all the font related properties, except for some font-family

JDK-8088391<https://bugs.openjdk.org/browse/JDK-8088391> javafx.scene.text.Font broken for families with more weights than Regular & Bold; especially on Mac

JDK-8190855<https://bugs.openjdk.org/browse/JDK-8190855> The text will be invisible when choosing different fonts of "Noto Sans" type

JDK-8176835<https://bugs.openjdk.org/browse/JDK-8176835> [macosx] System font cannot be boldened

JDK-8088257<https://bugs.openjdk.org/browse/JDK-8088257> support for both English and native font names

JDK-8089128<https://bugs.openjdk.org/browse/JDK-8089128> Font.getFontNames() sometimes returns duplicated font names.

JDK-8089450<https://bugs.openjdk.org/browse/JDK-8089450> Inconsistent naming for fonts in the 'Tahoma' family.

JDK-8090423<https://bugs.openjdk.org/browse/JDK-8090423> [Font] Support Font Weights other than Bold and Regular, like Light

JDK-8090628<https://bugs.openjdk.org/browse/JDK-8090628> Font - add getters for weight and posture

JDK-8092264<https://bugs.openjdk.org/browse/JDK-8092264> Support and document use of more fonts variants

(There might be more, I just did a quick query)

Are there any issues listed below that might be missing from JBS?

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Glavo <zjx001202 at gmail.com>
Date: Friday, November 28, 2025 at 07:10
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Some feature requests/improvement suggestions for the JavaFX Font API

Does anyone care about these issues?

Glavo

On Mon, Jul 21, 2025 at 2:29?AM Glavo <zjx001202 at gmail.com<mailto:zjx001202 at gmail.com>> wrote:
Hi,

We noticed that the Font API had many bugs and inconsistencies, and was missing a lot of functionality.
Unfortunately, I don't have enough knowledge in this field to solve them.
So I'm making some feature requests/improvement suggestions on this to see if anyone is interested.

1. Unify the meaning of "font family".

Currently "font family" has different meanings on different platforms:

  *   On Windows, it usually means the localized name of the font family name (nameID=1);
  *   On Linux,  it usually means the non-localized font family name (nameID=1, langID=0x0);
  *   On macOS,  it usually means the non-localized typographical family name (nameID=16, langID=0x0).

This inconsistency makes the behavior of the program confusing and it is impossible to know what will happen without testing on multiple platforms.

I want JavaFX to use the non-localized typographical family name (nameID=16, langID=0x0) on all platforms.
The reason is that the font family name (nameID=1) of many fonts actually contains the font style information,
and using it makes it difficult for us to select font style.

For example, if we want to get JetBrains Mono Bold on Windows, we need to use Font.font("JetBrains Mono", FontWeight.BOLD, 13),
but to get JetBrains Mono ExtraBold, we need to use Font.font("JetBrains Mono ExtraBold", FontWeight.NORMAL, 13).
This is really frustrating :(

Additionally, I encountered a bug on macOS that prevented me from selecting the font weight.
I explained this issue in a previous email: https://mail.openjdk.org/pipermail/openjfx-dev/2025-July/055417.html

2. Make Font.font(String) accept both font name and font family name.

I wish Font.font(String) could accept more names than just the font family name.

As mentioned in the previous section, the current concept of font family names in JavaFX is confusing and often contains font style information.
Therefore, it is very difficult to use the Font.font(String) in the correct way.
If it would accept a variety of font names, both localized and non-localized, it would be less difficult to use.

3. Add more methods to get font localized names

I would like to get these methods in Font class to get the localized name of the font:

  *   static Map<Locale, String> getLocalizedFamilyNames(String family)
  *   static String getLocalizedFamilyName(String family, Locale locale)
  *   static String getLocalizedFontNames(Locale locale)
  *   static String getLocalizedFontNames(String family, Locale locale)
  *   Map<Locale, String> getLocalizedNames()
  *   String getLocalizedName(Locale locale)
  *   Map<Locale, String> getLocalizedFamily()
  *   String getLocalizedFamily(Locale locale)

4. More methods for handling font styles

Right now we can only use FontWeight and FontPosture to select a font style when looking up a font,
but the only way to get the style from a given Font object is Font::getStyle(), which is very asymmetrical.

I would like to get these methods to handle font styles:

  *   static List<String> getStyles(String family)
  *   static Font font(String family, String style)
  *   FontWeight getWeight()
  *   FontPosture getPosture()

5. Support fallback fonts and CSS font list for UI controls
6. Provides a way to control the typographic features of fonts
      Refer to Flutter's FontFeature class: https://api.flutter.dev/flutter/dart-ui/FontFeature-class.html

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251201/d79ea368/attachment-0001.htm>

From angorya at openjdk.org  Mon Dec  1 21:12:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 21:12:17 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene
In-Reply-To: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
Message-ID: <RrovhL0RnjK0svxOOLJ8i3_Txpg92MZGv5OTQpHWJL4=.f4764976-0416-4431-9cc5-d6c93eda60db@github.com>

On Sun, 30 Nov 2025 03:25:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
> 
> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
> 
> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
> 
> 
> public class ZeroSizeSubScene extends Application {
> 
>     @Override
>     public void start(Stage stage) {
>         var rect = new Rectangle(50, 50, Color.RED);
>         var subScene = new SubScene(new Group(rect), 100, 100);
>         subScene.setFill(Color.GRAY);
> 
>         // Also try a perspective camera:
>         //
>         // var camera = new PerspectiveCamera();
>         // camera.setRotate(45);
>         // camera.setTranslateX(-20);
>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>         // subScene.setCamera(camera);
> 
>         class MyButton extends Button {
>             public MyButton(String text, double width, double height) {
>                 super(text);
>                 setOnAction(_ -> {
>                     var timeline = new Timeline(
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
> 
>                     timeline.setOnFinished(_ -> {
>                         Point2D p0 = rect.localToScreen(0, 0);
>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>                     });
> 
>                     timeline.play();
>                 });
>             }
>         }
> 
>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
> 
>         var root = new VBox(5,
>             subScene,
>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>             new MyButton("Size: 100x100", 100, 100),
>             new MyButton("Size: 10x10", 10, 10),
>             new MyButton("Size: 100x0", 100, 0),
>             new MyButton("Size: 0x100", 0, 100),
>             new MyButton("Size: 0x0", 0, 0)
>         );
> 
>         S...

modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 1626:

> 1624:         assertEquals(minY, b.getMinY(), 0.0005);
> 1625:         assertEquals(width, b.getWidth(), 0.0005);
> 1626:         assertEquals(height, b.getHeight(), 0.0005);

maybe we could declare a static constant EPSILON and use it at least in the modified tests?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1992#discussion_r2578676230

From angorya at openjdk.org  Mon Dec  1 21:39:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 21:39:00 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene
In-Reply-To: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
Message-ID: <UyI6sNrqoDYwdAF6Vf09Xj19lw5RYT1Aqgqh0Cg3SFk=.46a1b1b8-d916-4371-bf72-c703cdf616c4@github.com>

On Sun, 30 Nov 2025 03:25:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
> 
> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
> 
> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
> 
> 
> public class ZeroSizeSubScene extends Application {
> 
>     @Override
>     public void start(Stage stage) {
>         var rect = new Rectangle(50, 50, Color.RED);
>         var subScene = new SubScene(new Group(rect), 100, 100);
>         subScene.setFill(Color.GRAY);
> 
>         // Also try a perspective camera:
>         //
>         // var camera = new PerspectiveCamera();
>         // camera.setRotate(45);
>         // camera.setTranslateX(-20);
>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>         // subScene.setCamera(camera);
> 
>         class MyButton extends Button {
>             public MyButton(String text, double width, double height) {
>                 super(text);
>                 setOnAction(_ -> {
>                     var timeline = new Timeline(
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
> 
>                     timeline.setOnFinished(_ -> {
>                         Point2D p0 = rect.localToScreen(0, 0);
>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>                     });
> 
>                     timeline.play();
>                 });
>             }
>         }
> 
>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
> 
>         var root = new VBox(5,
>             subScene,
>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>             new MyButton("Size: 100x100", 100, 100),
>             new MyButton("Size: 10x10", 10, 10),
>             new MyButton("Size: 100x0", 100, 0),
>             new MyButton("Size: 0x100", 0, 100),
>             new MyButton("Size: 0x0", 0, 0)
>         );
> 
>         S...

Looks good on macOS.

modules/javafx.graphics/src/main/java/javafx/scene/Camera.java line 339:

> 337:         // and height to ulp(1), guaranteeing non-zero view dimensions while keeping the clamp very small.
> 338:         //
> 339:         this.viewWidth = Math.max(Math.ulp(1.0), width);

minor suggestion: create a private static function (`safeSize` ?) with the comment explaining why.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1992#pullrequestreview-3527148686
PR Review Comment: https://git.openjdk.org/jfx/pull/1992#discussion_r2578790529

From mstrauss at openjdk.org  Mon Dec  1 22:08:27 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 1 Dec 2025 22:08:27 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
Message-ID: <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>

> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
> 
> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
> 
> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
> 
> 
> public class ZeroSizeSubScene extends Application {
> 
>     @Override
>     public void start(Stage stage) {
>         var rect = new Rectangle(50, 50, Color.RED);
>         var subScene = new SubScene(new Group(rect), 100, 100);
>         subScene.setFill(Color.GRAY);
> 
>         // Also try a perspective camera:
>         //
>         // var camera = new PerspectiveCamera();
>         // camera.setRotate(45);
>         // camera.setTranslateX(-20);
>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>         // subScene.setCamera(camera);
> 
>         class MyButton extends Button {
>             public MyButton(String text, double width, double height) {
>                 super(text);
>                 setOnAction(_ -> {
>                     var timeline = new Timeline(
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
> 
>                     timeline.setOnFinished(_ -> {
>                         Point2D p0 = rect.localToScreen(0, 0);
>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>                     });
> 
>                     timeline.play();
>                 });
>             }
>         }
> 
>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
> 
>         var root = new VBox(5,
>             subScene,
>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>             new MyButton("Size: 100x100", 100, 100),
>             new MyButton("Size: 10x10", 10, 10),
>             new MyButton("Size: 100x0", 100, 0),
>             new MyButton("Size: 0x100", 0, 100),
>             new MyButton("Size: 0x0", 0, 0)
>         );
> 
>         S...

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1992/files
  - new: https://git.openjdk.org/jfx/pull/1992/files/3ca281f5..f7c7a3fd

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

  Stats: 29 lines in 1 file changed: 16 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1992.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1992/head:pull/1992

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

From mstrauss at openjdk.org  Mon Dec  1 22:08:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 1 Dec 2025 22:08:28 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <RrovhL0RnjK0svxOOLJ8i3_Txpg92MZGv5OTQpHWJL4=.f4764976-0416-4431-9cc5-d6c93eda60db@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
 <RrovhL0RnjK0svxOOLJ8i3_Txpg92MZGv5OTQpHWJL4=.f4764976-0416-4431-9cc5-d6c93eda60db@github.com>
Message-ID: <ig1QVWCWfH6hkfcOXDUuKHiJygDNKVFMCa0eJI0HSKA=.d971c667-5af5-4ee1-af8f-f879cfa5d532@github.com>

On Mon, 1 Dec 2025 21:09:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 1626:
> 
>> 1624:         assertEquals(minY, b.getMinY(), 0.0005);
>> 1625:         assertEquals(width, b.getWidth(), 0.0005);
>> 1626:         assertEquals(height, b.getHeight(), 0.0005);
> 
> maybe we could declare a static constant EPSILON and use it at least in the modified tests?

Since there are many different epsilons used in this test class, I'd have to call it something specific like `EPSILON_0005`, and at that point, there's little difference between a numeric literal and a constant field. It's a bit like saying "ONE" instead of "1".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1992#discussion_r2578887532

From jhendrikx at openjdk.org  Mon Dec  1 22:12:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 1 Dec 2025 22:12:06 GMT
Subject: RFR: 8092379: GridPane should not render extra gaps when entire
 rows or columns are unmanaged [v4]
In-Reply-To: <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
Message-ID: <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>

On Mon, 1 Dec 2025 19:12:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Looks good.
> 
> I've updated the standalone Monkey Tester to add a couple of layout scenarios to the GridPane page.

Thanks, GridPane is quite a useful layout, but if you want to hide a row or column, it is a huge pain currently (unless you use hgap/vgap of 0) as you need to physically renumber your rows/columns to collapse the extra gaps...

> modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 2635:
> 
>> 2633: 
>> 2634:         private void setMaxSize(int position, double size) {
>> 2635:             singleSizes[position] = Math.max(singleSizes[position], size);
> 
> I don't know why github shows this as a change.
> Unused `setMultiSize()` has been removed which is ok.

It's confusing the start of the diff I think :)

> modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 2640:
> 
>> 2638:         private Iterable<Entry<Interval, Double>> multiSizes() {
>> 2639:             if (multiSizes == null) {
>> 2640:                 return Collections.emptyList();
> 
> unrelated change, and probably gets inlined anyway.

Yeah, could remove, I just made the change because it was giving a raw type warning.

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

PR Comment: https://git.openjdk.org/jfx/pull/1990#issuecomment-3599174832
PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2578892593
PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2578893765

From angorya at openjdk.org  Mon Dec  1 22:39:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 22:39:03 GMT
Subject: RFR: 8092379: GridPane should not render extra gaps when entire
 rows or columns are unmanaged [v4]
In-Reply-To: <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
Message-ID: <GnyYwS_GVArqQKLq1WO6irgEimS2-F_ydLuj6aGNl6w=.a306be70-cfbb-45f0-a013-80c077efec43@github.com>

On Sat, 29 Nov 2025 20:51:38 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fixes a long standing bug with `GridPane` where unmanaged nodes would still result in gaps being added between rows/columns even though nothing is rendered there.  Take the following grid where dashes and pipes represent the vgaps and hgaps:
>> 
>> |            |0| |1|
>> |--------|---|---|---|
>> |0  |A|||B|
>> |    |-|||-|
>> |1  |C|||D|
>> |    |-|||-|
>> |2  |E|||F|
>> 
>> Now, when both C and D are set to unmanaged (and invisible) the grid will **still** render the gaps:
>> 
>> |            |0| |1|
>> |--------|---|---|---|
>> |0  |A|||B|
>> |    |-|||-|
>> |1  |||||
>> |    |-|||-|
>> |2  |E|||F|
>> 
>> Instead it should collapse the gap between row 0 and 2:
>> 
>> |            |0| |1|
>> |--------|---|---|---|
>> |0  |A|||B|
>> |    |-|||-|
>> |2  |E|||F|
>> 
>> There are at least two relevant issues in JBS:
>> - A request to let the user show and hide rows and columns: https://bugs.openjdk.org/browse/JDK-8136901
>>   - This can now be done by setting the relevant row/columns items to unmanaged without having to restructure the grid (assuming the complaint was that otherwise there'd be visible extra gaps for each hidden row)
>> - A request for another mode to skip gaps when entire rows/columns are unmanaged: https://bugs.openjdk.org/browse/JDK-8092379
>>   - This should not be a mode, but the standard, as unmanaged nodes should not affect the outcome of the grid layout
>> 
>> Screenshots
>> 
>> Simple application which can hide row 3:
>> 
>> <img width="443" height="491" alt="image" src="https://github.com/user-attachments/assets/0342dba3-cd1c-4d9e-9451-e9c8c628b2e2" />
>> 
>> Correct behavior when row 3 is hidden:
>> 
>> <img width="443" height="408" alt="image" src="https://github.com/user-attachments/assets/c7c54414-6a03-43e4-b733-21d0b251d729" />
>> 
>> Behavior before this fix (note the double gap **and** extra grid line):
>> 
>> <img width="443" height="453" alt="image" src="https://github.com/user-attachments/assets/f357e68a-e950-42e7-890b-91a78e194dd0" />
>
> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   When all nodes starting in a row or column are unmanaged, skip gap

huge pain, yes, that's why I am still working on https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md

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

PR Comment: https://git.openjdk.org/jfx/pull/1990#issuecomment-3599249915

From angorya at openjdk.org  Mon Dec  1 22:39:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 22:39:05 GMT
Subject: RFR: 8092379: GridPane should not render extra gaps when entire
 rows or columns are unmanaged [v4]
In-Reply-To: <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
 <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
Message-ID: <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>

On Mon, 1 Dec 2025 22:08:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 2640:
>> 
>>> 2638:         private Iterable<Entry<Interval, Double>> multiSizes() {
>>> 2639:             if (multiSizes == null) {
>>> 2640:                 return Collections.emptyList();
>> 
>> unrelated change, and probably gets inlined anyway.
>
> Yeah, could remove, I just made the change because it was giving a raw type warning.

I turned the raw warnings off, the project has thousands of those...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2578953998

From angorya at openjdk.org  Mon Dec  1 22:41:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 22:41:03 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
 <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
Message-ID: <WwOKICmNpmIPVxHR61vE5Jw5x4ZZSp9S_RLovRs4hIw=.080ec6b3-e311-4564-ae86-dfe049b21186@github.com>

On Mon, 1 Dec 2025 22:08:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
>> 
>> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
>> 
>> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
>> 
>> 
>> public class ZeroSizeSubScene extends Application {
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var rect = new Rectangle(50, 50, Color.RED);
>>         var subScene = new SubScene(new Group(rect), 100, 100);
>>         subScene.setFill(Color.GRAY);
>> 
>>         // Also try a perspective camera:
>>         //
>>         // var camera = new PerspectiveCamera();
>>         // camera.setRotate(45);
>>         // camera.setTranslateX(-20);
>>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>>         // subScene.setCamera(camera);
>> 
>>         class MyButton extends Button {
>>             public MyButton(String text, double width, double height) {
>>                 super(text);
>>                 setOnAction(_ -> {
>>                     var timeline = new Timeline(
>>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
>> 
>>                     timeline.setOnFinished(_ -> {
>>                         Point2D p0 = rect.localToScreen(0, 0);
>>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>>                     });
>> 
>>                     timeline.play();
>>                 });
>>             }
>>         }
>> 
>>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
>> 
>>         var root = new VBox(5,
>>             subScene,
>>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>>             new MyButton("Size: 100x100", 100, 100),
>>             new MyButton("Size: 10x10", 10, 10),
>>             new MyButton("Size: 100x0", 100, 0),
>>             ne...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by angorya (Reviewer).

@lukostyra could you please take a look at this on Windows with fractional scale?

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

PR Review: https://git.openjdk.org/jfx/pull/1992#pullrequestreview-3527333662
PR Comment: https://git.openjdk.org/jfx/pull/1992#issuecomment-3599261316

From angorya at openjdk.org  Mon Dec  1 23:03:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Dec 2025 23:03:29 GMT
Subject: [jfx25u] RFR: 8372453: [macOS] Iconifying owner may not iconify
 owned window
In-Reply-To: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
References: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
Message-ID: <Hdjw_BAf9WogeKHW7MM2P65SWpb4TaStz8VRUTUIZtg=.b5c5738c-77ac-4ff1-bbfe-b534913dfb08@github.com>

On Mon, 1 Dec 2025 18:49:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

> 8372453: [macOS] Iconifying owner may not iconify owned window

I approve of the approval request being approved!

:-)

-andy



Confidential- Oracle Internal

From: openjdk[bot] ***@***.***>
Date: Monday, December 1, 2025 at 14:55
To: openjdk/jfx25u ***@***.***>
Cc: Andy Goryachev ***@***.***>, Comment ***@***.***>
Subject: [External] : Re: [openjdk/jfx25u] 8372453: [macOS] Iconifying owner may not iconify owned window (PR #38)

[https://avatars.githubusercontent.com/u/41768318?s=20&v=4]openjdk[bot] left a comment (openjdk/jfx25u#38)<https://urldefense.com/v3/__https://github.com/openjdk/jfx25u/pull/38*issuecomment-3599311324__;Iw!!ACWV5N9M2RV99hQ!Kq_jYn1IaBJgEVjnRS7bYke_LWdpMiuvCIOdWqj4nhHPoh0u43AK_F3ZOE-Wt8_8E2hea0C-qi0PrWyfFUGERfVNTlenYQ$>

@kevinrushforth<https://urldefense.com/v3/__https://github.com/kevinrushforth__;!!ACWV5N9M2RV99hQ!Kq_jYn1IaBJgEVjnRS7bYke_LWdpMiuvCIOdWqj4nhHPoh0u43AK_F3ZOE-Wt8_8E2hea0C-qi0PrWyfFUGERfXu3OBFzA$>
8372453: The approval request has been approved.

?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openjdk/jfx25u/pull/38*issuecomment-3599311324__;Iw!!ACWV5N9M2RV99hQ!Kq_jYn1IaBJgEVjnRS7bYke_LWdpMiuvCIOdWqj4nhHPoh0u43AK_F3ZOE-Wt8_8E2hea0C-qi0PrWyfFUGERfVNTlenYQ$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AZQ34ZFQA2D3DACGHRLTA5337TBPRAVCNFSM6AAAAACNWUUBGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJZGMYTCMZSGQ__;!!ACWV5N9M2RV99hQ!Kq_jYn1IaBJgEVjnRS7bYke_LWdpMiuvCIOdWqj4nhHPoh0u43AK_F3ZOE-Wt8_8E2hea0C-qi0PrWyfFUGERfUfaJxtrg$>.
You are receiving this because you commented.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/38#issuecomment-3599327857

From jhendrikx at openjdk.org  Mon Dec  1 23:07:02 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 1 Dec 2025 23:07:02 GMT
Subject: RFR: 8092379: GridPane should not render extra gaps when entire
 rows or columns are unmanaged [v4]
In-Reply-To: <GnyYwS_GVArqQKLq1WO6irgEimS2-F_ydLuj6aGNl6w=.a306be70-cfbb-45f0-a013-80c077efec43@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <GnyYwS_GVArqQKLq1WO6irgEimS2-F_ydLuj6aGNl6w=.a306be70-cfbb-45f0-a013-80c077efec43@github.com>
Message-ID: <J9VGlSpBpcVBgEk9N2u_vgAx7vTEZY16VYT8F54WqDI=.ba376b85-939e-4ffa-b034-a17169ae7ade@github.com>

On Mon, 1 Dec 2025 22:34:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> huge pain, yes, that's why I am still working on https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md

:-)

I created my own `Flex` layout, which is a combination of HBox + VBox + GridPane.  It basically works by looking at how they are nested.  If you nest multiple horizontal flexes into a vertical flex:

     FlexV
           FlexH [ label , text field ]
           FlexH [ label , text field ]

The above would produce an unaligned mess when the labels are different lengths, just like nesting HBoxes into VBox would.  However, the Flex has a property "aligned" that you can set, and it will affect the layout of any nested flexes of the opposite type.  In this case, if you give the top FlexV this property, the nested horizontal flexes will automatically align as if they were in a grid.

It looks like this in code (in builder form):

        Panes.vflex("form").aligned().nodes(
          Panes.hflex().nodes(
            "Width",
            FX.spinner().editable().value(parameters.width)
          ),
          XPanes.hflex().nodes(
            "Height",
            FX.spinner().editable().value(parameters.height)
          )
        );

I actually only use `GridPane` in my samples, as I'm not ready yet to publish `Flex`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1990#issuecomment-3599330984

From kevin.rushforth at oracle.com  Tue Dec  2 00:08:53 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 1 Dec 2025 16:08:53 -0800
Subject: JavaFX 25.0.2 will be closed for fixes on December 8th
Message-ID: <5900f17c-1164-41a7-9b07-b589a1e095e5@oracle.com>

All,

If you have backports that you want to get into jfx25u for JavaFX 
25.0.2, please do so by Monday, December 8th. Note that approval from 
one of the project leads is needed as outlined in this message [1].

Thanks.

-- Kevin

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


From mfox at openjdk.org  Tue Dec  2 00:12:02 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 2 Dec 2025 00:12:02 GMT
Subject: [jfx25u] Integrated: 8372453: [macOS] Iconifying owner may not iconify
 owned window
In-Reply-To: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
References: <3D02Ix1iTJsADVZJaQMnCFliZvEMMI06fhFdv18jtFg=.f7a0191f-1cfe-4fee-8fde-cda849bf13e5@github.com>
Message-ID: <2pkdM10tCaO6pvZ_Ry0n-uHMriKdHJHND7TbOP51_wo=.6773f70b-93d4-4079-841a-e226be654d3a@github.com>

On Mon, 1 Dec 2025 18:49:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

> 8372453: [macOS] Iconifying owner may not iconify owned window

This pull request has now been integrated.

Changeset: 0dc85f66
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/0dc85f668dadc911c243c13c5e8bba1ec3e0aadb
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8372453: [macOS] Iconifying owner may not iconify owned window

Backport-of: 6234c07e0e7ef84145e8a17407bf983ddba13d05

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

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

From alexander.matveev at oracle.com  Tue Dec  2 01:55:14 2025
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 2 Dec 2025 01:55:14 +0000
Subject: Crash on macOS 26 when playing music file
In-Reply-To: <15ba729c-cc6e-4d04-b520-95fd2b5ba059@oracle.com>
References: <d9136336-449f-4e68-aa38-543b2438eadf@xpipe.io>
 <15ba729c-cc6e-4d04-b520-95fd2b5ba059@oracle.com>
Message-ID: <IA3PR10MB8637A6832E8466480D9623CB99D8A@IA3PR10MB8637.namprd10.prod.outlook.com>

Hi Christopher and Kevin,

I was able to reproduce this issue with FXMediaPlayer and MP3 file when playing via JRT protocol on macOS 26.1 aarch64. Not sure if it is reproducible on x64.

Christopher, do you want to file a bug report for it? Or I can file it myself.

Thanks,
Alexander



Confidential- Oracle Internal

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Tuesday, November 25, 2025 at 8:25?AM
To: Christopher Schnick <crschnick at xpipe.io>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Crash on macOS 26 when playing music file

I was able to play that media file with no problem on macOS 26.1 using
the tests/manual/media/FXMediaPlayer app in the FX repo. I didn't try
with your application.

I can see from the hs_err log you attached, that it is crashing in our
libjfxmedia_avf library in a callback from CoreFoundation.

I was running JDK 25.0.1 and I tried the latest mainline JavaFX (26 ea)
as well as JavaFX 25.0.1. Can you confirm the exact versions of JDK 25
and JavaFX 25 you were running?

-- Kevin


On 11/25/2025 5:07 AM, Christopher Schnick wrote:
> Hello, I encountered a reproducible crash when playing a music file
> with MediaPlayer. This does not occur on older versions of the app
> using an older JDK+JavaFX version on macOS 26.
>
> It crashes with JDK25 and JavaFX 25 for me. Attached is the crash log.
>
> I have not tested this in an isolated reproducer, but I don't see how
> any of my application logic can influence this. If it does not happen
> in an isolated manner, I can investigate what specific changes cause
> it to crash. The music file I tested with is from
> https://github.com/mkpaz/atlantafx/blob/master/sampler/src/main/resources/atlantafx/sampler/media/Beat%20Thee.mp3
> . The project to reproduce the crash is
> https://github.com/xpipe-io/kickstartfx, where you just have to select
> the music player and click on play sample.
>
> Best
> Christopher Schnick
>
> P.S. There is still a message I sent a few days ago in the mailing
> list moderation queue because it was larger than the maximum allowed
> attachment size
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251202/7b9f2a36/attachment-0001.htm>

From duke at openjdk.org  Tue Dec  2 03:52:05 2025
From: duke at openjdk.org (notzed)
Date: Tue, 2 Dec 2025 03:52:05 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented [v2]
In-Reply-To: <novvyQOTAOmynLHd20UHQZwWSH4h8bEWUsSMuQEMBFk=.4b1475b4-b165-4118-9a17-003cd9451cb4@github.com>
References: <oEeosr0F9dXuGNka-SUdBVqtnlzJnV6MiRng3H8iAT8=.a5de9489-6767-467e-9cce-8e0c2518ccfe@github.com>
 <novvyQOTAOmynLHd20UHQZwWSH4h8bEWUsSMuQEMBFk=.4b1475b4-b165-4118-9a17-003cd9451cb4@github.com>
Message-ID: <HKyZ6-S1yqt8ZPqNxO0nFrvjAF0YpG3yrwJqHbaHzTk=.d818747a-86ad-403a-b3a4-7e122621a21f@github.com>

On Tue, 25 Nov 2025 00:33:41 GMT, notzed <duke at openjdk.org> wrote:

>> As discussed on the mailing list.
>> 
>> OpenGL requires an explicit glFinish() to synchronise with the video refresh.  The current usage is incorrect and against the specification.  This patch calls glFinish() after all windows have been drawn following a pulse.
>
> notzed has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8210547 synchronise with OpenGL after the last window is presented

This is for JDK-8210547.

1929 is separate, it doesn't work for me when you have more than 1 window open.  It's effectively just the same as calling glFinish() on every glxSwapBuffers() which just tanks the framerate (and for me whether it uses *SGI or *EXT makes no difference).

I suppose I could see if using glXSwapIntervalEXT() makes a difference here.

FWIW this is what i'm using to test, it intentionally advances on animation pulses rather than using the the timestamp to visualise spurious pulses.  With javafx-25 it goes mental but with the given patch it runs at the right rate but with spurious pulses from the vsyncHint stuff.

BEWARE!  It uses Robot to take over the mouse, ESC/Q or alt-f4 quits.

[Latency.java](https://github.com/user-attachments/files/23870834/Latency.java)

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

PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3600058679

From arapte at openjdk.org  Tue Dec  2 05:44:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 2 Dec 2025 05:44:00 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
In-Reply-To: <TFfMBF0u8t7BCSguLMH6DJ0iZDKAIzkMZr6rO4rTQv0=.88c570eb-fa6e-49ee-8f74-f256c16a579a@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
 <TFfMBF0u8t7BCSguLMH6DJ0iZDKAIzkMZr6rO4rTQv0=.88c570eb-fa6e-49ee-8f74-f256c16a579a@github.com>
Message-ID: <uGG0_hA6_KBnLdX-bVlDI8HK35Tpb1ODXZ9SpyuVots=.cf9ac3fe-6cc6-45f8-aae9-63fc857ae5d5@github.com>

On Mon, 1 Dec 2025 19:02:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> All testing looks good, including with / without SOURCE_DATE_EPOCH.

Thanks for testing with `SOURCE_DATE_EPOCH`, I had not done that.
> Please confirm that you have done a CI build.

Yes Kevin, CI build completed successfully.

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

PR Comment: https://git.openjdk.org/jfx/pull/1993#issuecomment-3600276369

From crschnick at xpipe.io  Tue Dec  2 06:29:24 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 2 Dec 2025 07:29:24 +0100
Subject: Crash on macOS 26 when playing music file
In-Reply-To: <IA3PR10MB8637A6832E8466480D9623CB99D8A@IA3PR10MB8637.namprd10.prod.outlook.com>
References: <d9136336-449f-4e68-aa38-543b2438eadf@xpipe.io>
 <15ba729c-cc6e-4d04-b520-95fd2b5ba059@oracle.com>
 <IA3PR10MB8637A6832E8466480D9623CB99D8A@IA3PR10MB8637.namprd10.prod.outlook.com>
Message-ID: <0856832e-0237-4c8f-9fd3-a3069a7bc655@xpipe.io>

Feel free to file it yourself, that JBS submit form is not fun to use as 
an external reporter.

I want to say that the reproducer project I linked also crashes when 
running ./gradlew run, so not only with JRT. In that case, the resource 
file is located in a dependency jar and not in a runtime image.

On 02/12/2025 2:55 AM, Alexander Matveev wrote:
> Hi Christopher and Kevin,
>
> I was able to reproduce this issue with FXMediaPlayer and MP3 file 
> when playing via JRT protocol on macOS 26.1 aarch64. Not sure if it is 
> reproducible on x64.
>
> Christopher, do you want to file a bug report for it? Or?I can file it 
> myself.
>
> Thanks,
> Alexander
>
> *
>
> Confidential- Oracle Internal
>
> From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Tuesday, November 25, 2025 at 8:25?AM
> *To: *Christopher Schnick <crschnick at xpipe.io>, 
> openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Crash on macOS 26 when playing music file
>
> I was able to play that media file with no problem on macOS 26.1 using
> the tests/manual/media/FXMediaPlayer app in the FX repo. I didn't try
> with your application.
>
> I can see from the hs_err log you attached, that it is crashing in our
> libjfxmedia_avf library in a callback from CoreFoundation.
>
> I was running JDK 25.0.1 and I tried the latest mainline JavaFX (26 ea)
> as well as JavaFX 25.0.1. Can you confirm the exact versions of JDK 25
> and JavaFX 25 you were running?
>
> -- Kevin
>
>
> On 11/25/2025 5:07 AM, Christopher?Schnick wrote:
> > Hello, I encountered a reproducible crash when playing a music file
> > with MediaPlayer. This does not occur on older versions of the app
> > using an older JDK+JavaFX version on macOS 26.
> >
> > It crashes with JDK25 and JavaFX 25 for me. Attached is the crash log.
> >
> > I have not tested this in an isolated reproducer, but I don't see how
> > any of my application logic can influence this. If it does not happen
> > in an isolated manner, I can investigate what specific changes cause
> > it to crash. The music file I tested with is from
> > 
> https://github.com/mkpaz/atlantafx/blob/master/sampler/src/main/resources/atlantafx/sampler/media/Beat%20Thee.mp3
> > . The project to reproduce the crash is
> > https://github.com/xpipe-io/kickstartfx, where you just have to select
> > the music player and click on play sample.
> >
> > Best
> > Christopher Schnick
> >
> > P.S. There is still a message I sent a few days ago in the mailing
> > list moderation queue because it was larger than the maximum allowed
> > attachment size
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251202/eb65ec9a/attachment-0001.htm>

From lkostyra at openjdk.org  Tue Dec  2 11:45:07 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 2 Dec 2025 11:45:07 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented [v2]
In-Reply-To: <HKyZ6-S1yqt8ZPqNxO0nFrvjAF0YpG3yrwJqHbaHzTk=.d818747a-86ad-403a-b3a4-7e122621a21f@github.com>
References: <oEeosr0F9dXuGNka-SUdBVqtnlzJnV6MiRng3H8iAT8=.a5de9489-6767-467e-9cce-8e0c2518ccfe@github.com>
 <novvyQOTAOmynLHd20UHQZwWSH4h8bEWUsSMuQEMBFk=.4b1475b4-b165-4118-9a17-003cd9451cb4@github.com>
 <HKyZ6-S1yqt8ZPqNxO0nFrvjAF0YpG3yrwJqHbaHzTk=.d818747a-86ad-403a-b3a4-7e122621a21f@github.com>
Message-ID: <tWNAS81jLna60OoiBWy0rWcMJJALP37-LeLYW5SovEY=.cd361b48-fe47-4a4f-b2d7-d3c0312fa97b@github.com>

On Tue, 2 Dec 2025 03:49:47 GMT, notzed <duke at openjdk.org> wrote:

> I suppose I could see if using glXSwapIntervalEXT() makes a difference here.

It might be better to switch to `glXSwapIntervalEXT()` then. It seems to be more consistent across all platforms (ie. works on Intel where the others don't for some reason). I'll be waiting for your updates, and I think we can close #1929 then. Thanks for attaching the test program too, it'll come in handy.

Even though these changes are simple, they do go quite deep so we'll need to spend some extra time reviewing and testing them.

A couple of formalities as well:
- PR title must begin with issue number without `JDK-` and followed by a colon
- Text following the issue number must be the same as the JBS issue counterpart

So in this case, PR should be named exactly like #1929 for Skara to properly connect it.

Last but not least, when you update this branch please don't use `git rebase` and force pushes, as it breaks the review tool and makes it harder for us to iteratively review your changes. If you ever need to catch up to master or to resolve any conflicts, use `git merge` instead.

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

PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3601619573

From lkostyra at openjdk.org  Tue Dec  2 11:46:07 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 2 Dec 2025 11:46:07 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: <iwmsPHVjzXWB-bAxJmHn-91NT_mTG_bTuo9-wdmoXDs=.f86ac5cc-4c7a-4d49-ba12-bcb8b700b570@github.com>
References: <O6h0vab-ONVxD-3eOinC6if5xX_Ae9Aa2xFErxWsmgU=.c0f9330b-77aa-48c8-b083-700ba6124251@github.com>
 <iwmsPHVjzXWB-bAxJmHn-91NT_mTG_bTuo9-wdmoXDs=.f86ac5cc-4c7a-4d49-ba12-bcb8b700b570@github.com>
Message-ID: <8sF0wHre1zCLU6nZ5VA6yR0ZDFe_jWVTtIk0CHlP0wE=.99794096-00b7-41a9-8477-3cbe9ed82080@github.com>

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
>> 
>> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
>> 
>> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
>> 
>> It also selects the correct visual for transparency which needs to be depth = 32 for X11.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

As discussed in #1981 that approach is in fact better. I think we can close this PR in favor of the other one.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3601622045

From duke at openjdk.org  Tue Dec  2 13:33:46 2025
From: duke at openjdk.org (notzed)
Date: Tue, 2 Dec 2025 13:33:46 GMT
Subject: RFR: JDK-8210547 synchronise with OpenGL after the last window is
 presented [v2]
In-Reply-To: <novvyQOTAOmynLHd20UHQZwWSH4h8bEWUsSMuQEMBFk=.4b1475b4-b165-4118-9a17-003cd9451cb4@github.com>
References: <oEeosr0F9dXuGNka-SUdBVqtnlzJnV6MiRng3H8iAT8=.a5de9489-6767-467e-9cce-8e0c2518ccfe@github.com>
 <novvyQOTAOmynLHd20UHQZwWSH4h8bEWUsSMuQEMBFk=.4b1475b4-b165-4118-9a17-003cd9451cb4@github.com>
Message-ID: <z6wS_vvAXwmm6N7UQRXXGdyS4vEFvcLTYzl--ChfPXs=.9d7519e6-84fb-4bfd-99a3-e430c308d849@github.com>

On Tue, 25 Nov 2025 00:33:41 GMT, notzed <duke at openjdk.org> wrote:

>> As discussed on the mailing list.
>> 
>> OpenGL requires an explicit glFinish() to synchronise with the video refresh.  The current usage is incorrect and against the specification.  This patch calls glFinish() after all windows have been drawn following a pulse.
>
> notzed has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8210547 synchronise with OpenGL after the last window is presented

Sorry I made a mistake with the push, Kevin directed me to send an "empty commit" to trigger automation and I couldn't work out how to do that otherwise at the time - until just after I'd done it and it was too late then.

I'll look at merging in bits of 1929, sans the visual stuff which seems unrelated.

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

PR Comment: https://git.openjdk.org/jfx/pull/1981#issuecomment-3602079425

From angorya at openjdk.org  Tue Dec  2 15:28:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Dec 2025 15:28:56 GMT
Subject: Integrated: 8372298: RichTextArea: missing API: applyParagraphStyle
In-Reply-To: <gPlIJwkVy8xeOnA6SG2SSXR8Laac4O-yzY7BYvtE4sA=.730e8f24-343e-45b2-89b0-1bd13036879f@github.com>
References: <gPlIJwkVy8xeOnA6SG2SSXR8Laac4O-yzY7BYvtE4sA=.730e8f24-343e-45b2-89b0-1bd13036879f@github.com>
Message-ID: <SM3KflgvA4pl8dYSBhiPvH0NdOoLxFBI9shmfVKWbHY=.a16d400e-6de5-4599-84dd-10de58d3716e@github.com>

On Fri, 21 Nov 2025 16:19:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A missing protected method in StyledTextModel prevents from toggling of an individual paragraph attribute.
> 
> This can be tested with he latest Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> - select the RichTextArea page
> - select the RichTextArea model
> - select Control -> Context Menu -> RichTextArea menu
> - type in several paragraphs
> - select all and apply one paragraph attribute, let's say Paragraph Styles -> Background -> (any non-null)
> - select a subset of previously selected paragraphs and apply a second paragraph attribute, let's say Paragraph Styles -> Bullet -> (any non-null)

This pull request has now been integrated.

Changeset: 6626e013
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/6626e01398717dc2d9eeab4e31c2c9895398fe35
Stats:     95 lines in 8 files changed: 88 ins; 0 del; 7 mod

8372298: RichTextArea: missing API: applyParagraphStyle

Reviewed-by: kcr, mstrauss

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

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

From mstrauss at openjdk.org  Tue Dec  2 16:59:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 2 Dec 2025 16:59:49 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
Message-ID: <516DwfEFiKutVJf6ugwCCb_KwcbL3Rv2a3I7nwhocz8=.f80b4b65-99bb-46fe-9673-8bf7bbf38997@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

> The reason I asked about tests and test scenarios is the possibility of regression. Case in point - with this PR, on macOS with an external monitor at scale=1:
> 
> <img alt="Image" width="1184" height="340" src="https://private-user-images.githubusercontent.com/107069028/506202288-f55f0c01-c59a-49b5-8fc6-91470524eb9a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjQ2OTM4MTIsIm5iZiI6MTc2NDY5MzUxMiwicGF0aCI6Ii8xMDcwNjkwMjgvNTA2MjAyMjg4LWY1NWYwYzAxLWM1OWEtNDliNS04ZmM2LTkxNDcwNTI0ZWI5YS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMjAyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTIwMlQxNjM4MzJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02ZTVkNTc3MmJlNTYwZTYxYTMzZjBlM2VmYTFkNGJkMTkxZGE0NTk0NWVlNTEwY2ZhZTE2MzVlNzE1NDM3OGJlJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.VWBGQ1Qm7bk_zYmKp5FM8T0UK-s-MiREAYB12hUYHyI">
> I would second @johanvos in suggesting that the regression is what we should be guarding against, and perhaps expanding the tests.

I can reproduce this issue on macOS and two displays with different DPI scale. Dragging the window to the other display has the menus appear with ellipses. Moving the mouse pointer over the menu items does not change that, but clicking on the menus causes a relayout, which fixes the issue.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3603050441

From angorya at openjdk.org  Tue Dec  2 17:04:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Dec 2025 17:04:40 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v4]
In-Reply-To: <jxbrGDlwgQGy5c8S8pReOBvemiXbf64V6E1_7CXrwlU=.183ac0a3-f923-4b6a-aabf-469af7ee27b8@github.com>
References: <jxbrGDlwgQGy5c8S8pReOBvemiXbf64V6E1_7CXrwlU=.183ac0a3-f923-4b6a-aabf-469af7ee27b8@github.com>
Message-ID: <YZ8ZEn1aqdsbS_eG0hDuus72Y7YeCYMOggqnkHs1BOI=.9a99946a-9709-42db-a9b6-963017854035@github.com>

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved)
> - the fix can be verified visually using the latest Monkey Tester
> 
> <img width="1232" height="741" alt="Screenshot 2025-11-17 at 13 43 12" src="https://github.com/user-attachments/assets/58b2ef77-094c-45bd-8a04-3caaa4672df1" />

Andy Goryachev 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 nine additional commits since the last revision:

 - Merge branch 'master' into 8371067.request.layout
 - updated test
 - Merge branch 'master' into 8371067.request.layout
 - add text segment
 - Merge branch 'master' into 8371067.request.layout
 - test
 - request layout
 - test
 - fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1975/files
  - new: https://git.openjdk.org/jfx/pull/1975/files/ecd2c0e7..56bcfff7

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

  Stats: 371 lines in 24 files changed: 206 ins; 94 del; 71 mod
  Patch: https://git.openjdk.org/jfx/pull/1975.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1975/head:pull/1975

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

From angorya at openjdk.org  Tue Dec  2 17:06:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Dec 2025 17:06:55 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v4]
In-Reply-To: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
Message-ID: <DCpx4FCSGQQlp0JeRRkXhxl6XjMjqJkhOnHOY8kbSCM=.bf9ac109-5b99-463b-b71c-0e5a10a5cddf@github.com>

> Addressing the user feedback:
> 
> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
> 
> 
> Adding two methods to the `RichParagraph` class:
> 
> - getSegmentCount()
> - getSegment(int index)
> 
> Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - test
 - expose segments

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

Changes: https://git.openjdk.org/jfx/pull/1966/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=03
  Stats: 215 lines in 7 files changed: 141 ins; 43 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1966.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1966/head:pull/1966

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

From angorya at openjdk.org  Tue Dec  2 17:10:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Dec 2025 17:10:00 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
Message-ID: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>

> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
> 
> Test cases:
> 
>     @Test
>     public void addTextAfterRegion() {
>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>         m.addParagraph(() -> new Region());
>         m.addNodeSegment(() -> new Region());
>         assertEquals(2, m.size());
>     }
> 
>     @Test
>     public void addTextAfterRegionAfterText() {
>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>         m.addNodeSegment(() -> new Region());
>         m.addParagraph(() -> new Region());
>         m.addSegment("text");
>         assertEquals(3, m.size());
>     }

Andy Goryachev 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 two additional commits since the last revision:

 - Merge branch 'master' into 8372438.non.text.paragraphs
 - fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1983/files
  - new: https://git.openjdk.org/jfx/pull/1983/files/fb24deb1..d0f1ee64

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

  Stats: 371 lines in 24 files changed: 206 ins; 94 del; 71 mod
  Patch: https://git.openjdk.org/jfx/pull/1983.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1983/head:pull/1983

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

From angorya at openjdk.org  Tue Dec  2 17:29:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Dec 2025 17:29:47 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v5]
In-Reply-To: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
Message-ID: <eoRYICqWRN36O0oufgDQMV5PbRTkTo3JjTMvLE1-d1Q=.388929ef-0b10-43bd-867f-ecd72f6c362a@github.com>

> Addressing the user feedback:
> 
> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
> 
> 
> Adding two methods to the `RichParagraph` class:
> 
> - getSegmentCount()
> - getSegment(int index)
> 
> Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  merge

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1966/files
  - new: https://git.openjdk.org/jfx/pull/1966/files/41c08b8d..b4691640

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

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

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

From mfox at openjdk.org  Tue Dec  2 19:04:27 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 2 Dec 2025 19:04:27 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds
In-Reply-To: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
Message-ID: <FVfcmaDMao5Ur6VTE2NNiEY6-Ime69s2JFhJB8Cqypg=.972e30d5-d52d-42bf-bc83-916b3d343cad@github.com>

On Mon, 24 Nov 2025 14:28:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
> 
> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
> 
> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
> 
> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
> 
> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).

I haven't uncovered any problems so far but it took me a while to get my bearings. You're working with two coordinate systems, the one used by JavaFX which doesn't include the invisible border and the one used by Windows which does. The naming convention is confusing since the "extended" rectangle is actually the smaller of the two. It would also be good to see some comments clarifying that `m_insets`, `m_maxSize`, and `m_minSize` are all specified in the JavaFX system.

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

PR Comment: https://git.openjdk.org/jfx/pull/1982#issuecomment-3603544681

From mstrauss at openjdk.org  Tue Dec  2 19:57:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 2 Dec 2025 19:57:06 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds
In-Reply-To: <FVfcmaDMao5Ur6VTE2NNiEY6-Ime69s2JFhJB8Cqypg=.972e30d5-d52d-42bf-bc83-916b3d343cad@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <FVfcmaDMao5Ur6VTE2NNiEY6-Ime69s2JFhJB8Cqypg=.972e30d5-d52d-42bf-bc83-916b3d343cad@github.com>
Message-ID: <rmweh8ha0IVYUnx8LibvVqngn4b0VG9jKmjiZTVnGaQ=.476cc6fb-92ff-4009-8806-7cf7bf0e5b3e@github.com>

On Tue, 2 Dec 2025 19:01:11 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I haven't uncovered any problems so far but it took me a while to get my bearings. You're working with two coordinate systems, the one used by JavaFX which doesn't include the invisible border and the one used by Windows which does. The naming convention is confusing since the "extended" rectangle is actually the smaller of the two. It would also be good to see some comments clarifying that `m_insets`, `m_maxSize`, and `m_minSize` are all specified in the JavaFX system.

I don?t think it?s quite "two coordinate systems" (JavaFX vs Windows). `Stage.width/height` are intended to include the normal system decorations (title bar + borders), which historically also matches what people mean by "window size": it includes the non-client area, but not purely visual effects like drop shadows. The weirdness on Windows 10+ is that GetWindowRect started including an extra invisible resize border that?s not part of the visible frame, so the window ends up being reported a few pixels larger than it looks. Using `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` is basically a way to get the visually perceived bounds back.

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

PR Comment: https://git.openjdk.org/jfx/pull/1982#issuecomment-3603720855

From mfox at openjdk.org  Wed Dec  3 00:15:36 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 3 Dec 2025 00:15:36 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds
In-Reply-To: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
Message-ID: <-0HwkGEPXrgB2WD0jLPLfU5h6QEydVLIs4OyuhP--3U=.fdec785b-1386-456e-a975-f0e5dac676ce@github.com>

On Mon, 24 Nov 2025 14:28:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
> 
> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
> 
> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
> 
> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
> 
> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).

I was thinking that JavaFX and Windows have different ideas of where the window origin (0, 0) lies; Windows thinks it's at the top left of drop shadow area and JavaFX thinks it's at the top left of the title bar (in this PR). But you're right, what's relevant is that there are two rectangles of different sizes. I still think it could be clearer that, say, `m_insets` applies to the smaller of the two (which is the extended one).

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

PR Comment: https://git.openjdk.org/jfx/pull/1982#issuecomment-3604471924

From mstrauss at openjdk.org  Wed Dec  3 00:48:52 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 3 Dec 2025 00:48:52 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v2]
In-Reply-To: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
Message-ID: <TlKuzy70qOY8mEy1bpzofyCRPvZRnReSGvAWRVfqLVI=.d2113d98-b6c0-42b0-bc56-34ccafe60a29@github.com>

> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
> 
> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
> 
> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
> 
> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
> 
> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).

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

  add comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1982/files
  - new: https://git.openjdk.org/jfx/pull/1982/files/164d9b73..defe0df7

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

  Stats: 14 lines in 1 file changed: 9 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1982.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1982/head:pull/1982

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

From mstrauss at openjdk.org  Wed Dec  3 00:48:53 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 3 Dec 2025 00:48:53 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds
In-Reply-To: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
Message-ID: <Bij-qNiq2EAAWNQQaMKxyqyHvCCN0Sr6a42-ikLRJCA=.ef398926-940b-4787-b4ad-fec254c02682@github.com>

On Mon, 24 Nov 2025 14:28:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
> 
> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
> 
> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
> 
> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
> 
> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).

I've added a comment to clarify that `m_minSize`, `m_maxSize`, and `m_insets` are specified with respect to the extended frame bounds.

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

PR Comment: https://git.openjdk.org/jfx/pull/1982#issuecomment-3604540834

From zelmidaoui at openjdk.org  Wed Dec  3 14:32:13 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 3 Dec 2025 14:32:13 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
Message-ID: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>

Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
Tested with monkeyTester and the test in the bug

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

Commit messages:
 - Fix TextArea/TextFlow alignment right in RTL

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

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

From zelmidaoui at openjdk.org  Wed Dec  3 14:32:13 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 3 Dec 2025 14:32:13 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
Message-ID: <9mdEmiM2gME2yppSL2ru6ivSI7mnAfaVl_CZtYIqfwM=.cbad938d-493e-47f8-bc15-59144170cf98@github.com>

On Wed, 3 Dec 2025 13:33:31 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
> Tested with monkeyTester and the test in the bug

Working on a JUnit Test for this bug.

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3606886102

From zelmidaoui at openjdk.org  Wed Dec  3 14:33:04 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 3 Dec 2025 14:33:04 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode
In-Reply-To: <Zn3yA25J9sPeLzUztxFjQDHWvPc2pI4X1Q6W_6z9ai8=.4ca6a163-c27e-4575-857e-12fdb470b482@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
 <Zn3yA25J9sPeLzUztxFjQDHWvPc2pI4X1Q6W_6z9ai8=.4ca6a163-c27e-4575-857e-12fdb470b482@github.com>
Message-ID: <ceItzHE9p-AXRvR3ZZNvZvLmG07p3Oon-pgzydxz2l8=.d055d1dd-6983-41c7-859e-d8df00e36fbe@github.com>

On Wed, 26 Nov 2025 21:24:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
>> Added case to handle complex text in `getPosX` of `TextRun`
>> Tested the changes with the code present in the bug.
>
> Updated reproducer: https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/TextFlow_ExtraSpace_8330559.java

@andy-goryachev-oracle I have provided a fix for [JDK-8318095](https://bugs.openjdk.org/browse/JDK-8318095) in PR [1995](https://github.com/openjdk/jfx/pull/1995). 
It doesn't impact the changes in this PR as mentioned, you can review it and let me know your suggestions for both PRs

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

PR Comment: https://git.openjdk.org/jfx/pull/1988#issuecomment-3607145473

From lukasz.kostyra at oracle.com  Wed Dec  3 16:54:55 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Wed, 3 Dec 2025 16:54:55 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io>
 <DM3PPF3367D7B9B751B25F083A68EF6D7F0FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <c21d8e4a-7269-4290-8a70-54cbccd8a782@xpipe.io>
 <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io>
 <IA3PR10MB8682C066B2046DBD40631D0CFEC9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <IA3PR10MB8682E4623B0A4251DBAF9AAEFEDCA@IA3PR10MB8682.namprd10.prod.outlook.com>
 <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io>
Message-ID: <IA3PR10MB868298C18CF5080852E3DCE3FED9A@IA3PR10MB8682.namprd10.prod.outlook.com>

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 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>
Sent: Friday, 28 November 2025 13:25
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 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 01DC647D.C3E61E40]

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 01DC647D.C3E61E40]

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/20251203/1d8a6601/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/20251203/1d8a6601/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/20251203/1d8a6601/image002-0001.png>

From mstrauss at openjdk.org  Wed Dec  3 17:23:48 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 3 Dec 2025 17:23:48 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention
Message-ID: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>

The following interpolator factories don't follow the standard method naming convention:

* `Interpolator.SPLINE(double, double, double, double)`
* `Interpolator.TANGENT(Duration, double, Duration, double)`
* `Interpolator.TANGENT(Duration, double)`
* `Interpolator.STEPS(int, StepPosition)`

New methods named `ofSpline`, `ofTangent`, and `ofSteps` are added. The existing methods are deprecated (not for removal) in favor of the correctly-named methods. This change is in line with the new `ofLinear` method added with #1977.

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

Commit messages:
 - Interpolator factories should follow method naming convention

Changes: https://git.openjdk.org/jfx/pull/1996/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373038
  Stats: 135 lines in 7 files changed: 62 ins; 9 del; 64 mod
  Patch: https://git.openjdk.org/jfx/pull/1996.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1996/head:pull/1996

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

From crschnick at xpipe.io  Wed Dec  3 17:52:40 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 3 Dec 2025 18:52:40 +0100
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <IA3PR10MB868298C18CF5080852E3DCE3FED9A@IA3PR10MB8682.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io>
 <DM3PPF3367D7B9B751B25F083A68EF6D7F0FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <c21d8e4a-7269-4290-8a70-54cbccd8a782@xpipe.io>
 <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io>
 <IA3PR10MB8682C066B2046DBD40631D0CFEC9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <IA3PR10MB8682E4623B0A4251DBAF9AAEFEDCA@IA3PR10MB8682.namprd10.prod.outlook.com>
 <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io>
 <IA3PR10MB868298C18CF5080852E3DCE3FED9A@IA3PR10MB8682.namprd10.prod.outlook.com>
Message-ID: <e9d69da3-e2e9-4e8a-80ff-84430983872a@xpipe.io>

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 
> 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>
> *Sent:* Friday, 28 November 2025 13:25
> *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 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/20251203/be2b5b68/attachment-0001.htm>
-------------- 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/20251203/be2b5b68/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/20251203/be2b5b68/image002-0001.png>

From mariushanl at web.de  Wed Dec  3 19:31:38 2025
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 3 Dec 2025 19:31:38 +0000
Subject: JavaFX Direct3D 12 - Call for performance testing help
In-Reply-To: <IA3PR10MB8682E5772DA242391EE8DC8FFECAA@IA3PR10MB8682.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B1D0248F8207E3935054BFECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <IA3PR10MB8682E5772DA242391EE8DC8FFECAA@IA3PR10MB8682.namprd10.prod.outlook.com>
Message-ID: <trinity-af93a0f7-76a4-417a-b03c-0544da356bfa-1764790298600@trinity-msg-rest-webde-webde-live-6769db957f-44674>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Laptop_dgpu_RenderPerf_results-d3d12-20251127-221003.csv
Type: application/vnd.ms-excel
Size: 894 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/Laptop_dgpu_RenderPerf_results-d3d12-20251127-221003-0001.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Laptop_dgpu_RenderPerf_results-d3d-20251127-214034.csv
Type: application/vnd.ms-excel
Size: 921 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/Laptop_dgpu_RenderPerf_results-d3d-20251127-214034-0001.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Laptop_igpu_RenderPerf_results-d3d12-20251128-000446.csv
Type: application/vnd.ms-excel
Size: 906 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/Laptop_igpu_RenderPerf_results-d3d12-20251128-000446-0001.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Laptop_igpu_RenderPerf_results-d3d-20251127-230229.csv
Type: application/vnd.ms-excel
Size: 911 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/Laptop_igpu_RenderPerf_results-d3d-20251127-230229-0001.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tower_RenderPerf_results-d3d12-20251129-131458.csv
Type: application/vnd.ms-excel
Size: 933 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/Tower_RenderPerf_results-d3d12-20251129-131458-0001.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tower_RenderPerf_results-d3d-20251129-124242.csv
Type: application/vnd.ms-excel
Size: 949 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/01b16308/Tower_RenderPerf_results-d3d-20251129-124242-0001.csv>

From zjx001202 at gmail.com  Wed Dec  3 20:00:49 2025
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 4 Dec 2025 04:00:49 +0800
Subject: WebP and AVIF image support
Message-ID: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>

Hi,

The image formats supported by JavaFX have not been updated for a very long
time. However, more and more content providers are now adopting newer
formats such as WebP and AVIF.

For example, our application needs to display icons for Minecraft mods,
modpacks, and other content sourced from Modrinth, and the vast majority of
these icons are in WebP format. To work around this, we currently have to
bundle TwelveMonkeys into our program, decode the images to BufferedImage,
and then convert them to javafx.scene.image.Image. This approach
significantly increases the size of our application, adds considerable
performance overhead, does not support animated WebP, and even has a
color-shift bug when decoding lossy-compressed WebP images.

Is there any possibility that JavaFX will add native support for modern
image formats like WebP and AVIF in the future? I noticed that the
javafx.web module already depends on libwebp during its build, yet this
dependency is not utilized for javafx.scene.image.Image decoding?which is
honestly a bit of a shame. We sincerely hope that JavaFX can provide native
support for these formats.

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/8eaf4d75/attachment.htm>

From andy.goryachev at oracle.com  Wed Dec  3 20:09:36 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 3 Dec 2025 20:09:36 +0000
Subject: WebP and AVIF image support
In-Reply-To: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
References: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
Message-ID: <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>

And HEIC.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Glavo <zjx001202 at gmail.com>
Date: Wednesday, December 3, 2025 at 12:01
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: WebP and AVIF image support

Hi,

The image formats supported by JavaFX have not been updated for a very long time. However, more and more content providers are now adopting newer formats such as WebP and AVIF.

For example, our application needs to display icons for Minecraft mods, modpacks, and other content sourced from Modrinth, and the vast majority of these icons are in WebP format. To work around this, we currently have to bundle TwelveMonkeys into our program, decode the images to BufferedImage, and then convert them to javafx.scene.image.Image. This approach significantly increases the size of our application, adds considerable performance overhead, does not support animated WebP, and even has a color-shift bug when decoding lossy-compressed WebP images.

Is there any possibility that JavaFX will add native support for modern image formats like WebP and AVIF in the future? I noticed that the javafx.web module already depends on libwebp during its build, yet this dependency is not utilized for javafx.scene.image.Image decoding?which is honestly a bit of a shame. We sincerely hope that JavaFX can provide native support for these formats.

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

From michaelstrau2 at gmail.com  Wed Dec  3 20:20:48 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 3 Dec 2025 21:20:48 +0100
Subject: WebP and AVIF image support
In-Reply-To: <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
 <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXQkfE1zUMk2yvwgQxtXrSPzn5+YA0uiC8WfDbKeU+XcuA@mail.gmail.com>

> For example, our application needs to display icons for Minecraft mods, modpacks, and other content sourced from Modrinth, and the vast majority of these icons are in WebP format. To work around this, we currently have to bundle TwelveMonkeys into our program, decode the images to BufferedImage, and then convert them to javafx.scene.image.Image. This approach significantly increases the size of our application, adds considerable performance overhead, does not support animated WebP, and even has a color-shift bug when decoding lossy-compressed WebP images.
>
> Is there any possibility that JavaFX will add native support for modern image formats like WebP and AVIF in the future? I noticed that the javafx.web module already depends on libwebp during its build, yet this dependency is not utilized for javafx.scene.image.Image decoding?which is honestly a bit of a shame. We sincerely hope that JavaFX can provide native support for these formats.


There's no need for your workaround. If you have TwelveMonkeys bundled
with your application, JavaFX can read all of the supported images
"natively" without manually converting to BufferedImage first. You
just specify the WebP file in the constructor of Image.

What's true is that this doesn't work for animated images.

From angorya at openjdk.org  Wed Dec  3 20:24:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Dec 2025 20:24:34 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention
In-Reply-To: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
Message-ID: <I0sWq99kKf8XP19uYhyoXPLvwRpLsMG6RF3Q6P9Aufo=.1375cdef-e10f-4c2e-b3c6-1e1163da0704@github.com>

On Wed, 3 Dec 2025 17:08:24 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The following interpolator factories don't follow the standard method naming convention:
> 
> * `Interpolator.SPLINE(double, double, double, double)`
> * `Interpolator.TANGENT(Duration, double, Duration, double)`
> * `Interpolator.TANGENT(Duration, double)`
> * `Interpolator.STEPS(int, StepPosition)`
> 
> New methods named `ofSpline`, `ofTangent`, and `ofSteps` are added. The existing methods are deprecated (not for removal) in favor of the correctly-named methods. This change is in line with the new `ofLinear` method added with #1977.

This change makes sense from purely esthetic reasons, though it probably won't be noticed by the app developers as they mostly deal with the interpolators via CSS (and there is no change there, as far as I can tell).

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

PR Comment: https://git.openjdk.org/jfx/pull/1996#issuecomment-3608686492

From kevin.rushforth at oracle.com  Wed Dec  3 20:31:48 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 3 Dec 2025 12:31:48 -0800
Subject: WebP and AVIF image support
In-Reply-To: <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
 <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <cb1d8d0c-0372-4e35-8b27-6377c0b71108@oracle.com>

We don't currently have any plans to add such support, but could 
consider it if there was enough demand.

Now that we have support for using Java2D's ImageIO an application could 
provide one or use a third-party ImageIO loader for those formats, but 
that would have similar limitations to those mentioned (it wouldn't 
support animated images and the application would need to bundle the 
loader).

-- Kevin


On 12/3/2025 12:09 PM, Andy Goryachev wrote:
> And HEIC.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Glavo 
> <zjx001202 at gmail.com>
> *Date: *Wednesday, December 3, 2025 at 12:01
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *WebP and AVIF image support
>
> Hi,
>
> The image formats supported by JavaFX have not been updated for a very 
> long time. However, more and more content providers are now adopting 
> newer formats such as WebP and AVIF.
>
> For example, our application needs to display icons for Minecraft 
> mods, modpacks, and other content sourced from Modrinth, and the vast 
> majority of these icons are in WebP format. To work around this, we 
> currently have to bundle TwelveMonkeys into our program, decode the 
> images to BufferedImage, and then convert them to 
> javafx.scene.image.Image. This approach significantly increases the 
> size of our application, adds considerable performance overhead, does 
> not support animated WebP, and even has a color-shift bug when 
> decoding lossy-compressed WebP images.
>
> Is there any possibility that JavaFX will add native support for 
> modern image formats like WebP and AVIF in the future? I noticed that 
> the javafx.web module already depends on libwebp during its build, yet 
> this dependency is not utilized for javafx.scene.image.Image 
> decoding?which is honestly a bit of a shame. We sincerely hope that 
> JavaFX can provide native support for these formats.
>
> Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251203/0d71ee8f/attachment.htm>

From angorya at openjdk.org  Wed Dec  3 22:06:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Dec 2025 22:06:08 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <9mdEmiM2gME2yppSL2ru6ivSI7mnAfaVl_CZtYIqfwM=.cbad938d-493e-47f8-bc15-59144170cf98@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <9mdEmiM2gME2yppSL2ru6ivSI7mnAfaVl_CZtYIqfwM=.cbad938d-493e-47f8-bc15-59144170cf98@github.com>
Message-ID: <DCfBTt604t3LUYdkjBPYYIDFl46czgyHLqIC2OH0PyY=.cc3e2094-6774-42cd-a3da-36fe5ebbbb23@github.com>

On Wed, 3 Dec 2025 13:34:21 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
>> Tested with monkeyTester and the test in the bug
>
> Working on a JUnit Test for this bug.

@Ziad-Mid this looks much better, almost complete!
I would like to ask you to test it not only with TextArea, but also with TextFlow - you can use this reproducer https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/TextFlow_ExtraSpace_8330559.java

Notice how the layout is still not right in some places when the window is resized (the screenshots are from a combined branch of this PR + #1988 but the result is still the same, I think):

<img width="579" height="612" alt="Screenshot 2025-12-03 at 13 27 21" src="https://github.com/user-attachments/assets/161b7ece-0846-47d8-ba69-4a5f6068d53a" />
<img width="686" height="612" alt="Screenshot 2025-12-03 at 13 27 29" src="https://github.com/user-attachments/assets/5b00d994-f45d-4ff4-aee8-fc8cbd93bd61" />



Also, could you try using the monkey tester and try TextArea/TextFlow (and possibly Text/TextField as well) with RTL as well as mixed text.  Please see if you can verify that the layout info is reported correctly, and the shapes are correct.

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3609033799

From angorya at openjdk.org  Wed Dec  3 23:27:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Dec 2025 23:27:12 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
Message-ID: <w9hVl11t7Tb3DDBCqRHvwlb7ILFcpUQCXEUzN-4F-BQ=.6d88966c-322f-40cd-9ff3-ebd3e0651fb1@github.com>

On Wed, 3 Dec 2025 13:33:31 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
> Tested with monkeyTester and the test in the bug

Another thing you might want to check is whether the LayoutInfo and related APIs (caretShape, etc) report correct information.

Using the updated Monkey Tester from 
https://github.com/andy-goryachev-oracle/MonkeyTest
:

<img width="1235" height="767" alt="Screenshot 2025-12-03 at 15 12 24" src="https://github.com/user-attachments/assets/31eac910-0fcb-4904-958e-1328c47f0c91" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3609251395

From alexander.matveev at oracle.com  Thu Dec  4 00:00:09 2025
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 4 Dec 2025 00:00:09 +0000
Subject: Crash on macOS 26 when playing music file
In-Reply-To: <IA3PR10MB8637A6832E8466480D9623CB99D8A@IA3PR10MB8637.namprd10.prod.outlook.com>
References: <d9136336-449f-4e68-aa38-543b2438eadf@xpipe.io>
 <15ba729c-cc6e-4d04-b520-95fd2b5ba059@oracle.com>
 <IA3PR10MB8637A6832E8466480D9623CB99D8A@IA3PR10MB8637.namprd10.prod.outlook.com>
Message-ID: <DM3PPFC82B878188A67B8E130E96F2721DF99D9A@DM3PPFC82B87818.namprd10.prod.outlook.com>

Filed a bug for it: https://bugs.openjdk.org/browse/JDK-8373058



Confidential- Oracle Internal

From: Alexander Matveev <alexander.matveev at oracle.com>
Date: Monday, December 1, 2025 at 5:55?PM
To: Kevin Rushforth <kevin.rushforth at oracle.com>, Christopher Schnick <crschnick at xpipe.io>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Crash on macOS 26 when playing music file

Hi Christopher and Kevin,

I was able to reproduce this issue with FXMediaPlayer and MP3 file when playing via JRT protocol on macOS 26.1 aarch64. Not sure if it is reproducible on x64.

Christopher, do you want to file a bug report for it? Or I can file it myself.

Thanks,
Alexander

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Tuesday, November 25, 2025 at 8:25?AM
To: Christopher Schnick <crschnick at xpipe.io>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Crash on macOS 26 when playing music file

I was able to play that media file with no problem on macOS 26.1 using
the tests/manual/media/FXMediaPlayer app in the FX repo. I didn't try
with your application.

I can see from the hs_err log you attached, that it is crashing in our
libjfxmedia_avf library in a callback from CoreFoundation.

I was running JDK 25.0.1 and I tried the latest mainline JavaFX (26 ea)
as well as JavaFX 25.0.1. Can you confirm the exact versions of JDK 25
and JavaFX 25 you were running?

-- Kevin


On 11/25/2025 5:07 AM, Christopher Schnick wrote:
> Hello, I encountered a reproducible crash when playing a music file
> with MediaPlayer. This does not occur on older versions of the app
> using an older JDK+JavaFX version on macOS 26.
>
> It crashes with JDK25 and JavaFX 25 for me. Attached is the crash log.
>
> I have not tested this in an isolated reproducer, but I don't see how
> any of my application logic can influence this. If it does not happen
> in an isolated manner, I can investigate what specific changes cause
> it to crash. The music file I tested with is from
> https://github.com/mkpaz/atlantafx/blob/master/sampler/src/main/resources/atlantafx/sampler/media/Beat%20Thee.mp3
> . The project to reproduce the crash is
> https://github.com/xpipe-io/kickstartfx, where you just have to select
> the music player and click on play sample.
>
> Best
> Christopher Schnick
>
> P.S. There is still a message I sent a few days ago in the mailing
> list moderation queue because it was larger than the maximum allowed
> attachment size
>
>

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

From angorya at openjdk.org  Thu Dec  4 00:24:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Dec 2025 00:24:10 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention
In-Reply-To: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
Message-ID: <FGaMgpjoFfBTLX-2hebrGlBCNu4jJzF4sN2OhTNXjfw=.0aeb0c77-77d2-4698-abaf-82d972d4100f@github.com>

On Wed, 3 Dec 2025 17:08:24 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The following interpolator factories don't follow the standard method naming convention:
> 
> * `Interpolator.SPLINE(double, double, double, double)`
> * `Interpolator.TANGENT(Duration, double, Duration, double)`
> * `Interpolator.TANGENT(Duration, double)`
> * `Interpolator.STEPS(int, StepPosition)`
> 
> New methods named `ofSpline`, `ofTangent`, and `ofSteps` are added. The existing methods are deprecated (not for removal) in favor of the correctly-named methods. This change is in line with the new `ofLinear` method added with #1977.

lgtm

modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 97:

> 95:     private static final double SWIPE_THRESHOLD = 0.30;
> 96:     private static final double TOUCH_THRESHOLD = 15;
> 97:     private static final Interpolator interpolator = Interpolator.ofSpline(0.4829, 0.5709, 0.6803, 0.9928);

Off-topic: shouldn't this interpolator be specified by the stylesheet (i.e. to be able to modify the transition if needed)?

More of a question for @kevinrushforth

modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 192:

> 190: 
> 191:     /**
> 192:      * Use {@link #ofSpline(double, double, double, double)}.

maybe something like "This poorly named method is deprecated in favor of ..." or words to that extent?

or keep the original description?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1996#pullrequestreview-3537381451
PR Review Comment: https://git.openjdk.org/jfx/pull/1996#discussion_r2586989217
PR Review Comment: https://git.openjdk.org/jfx/pull/1996#discussion_r2586983857

From angorya at openjdk.org  Thu Dec  4 03:27:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Dec 2025 03:27:12 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
Message-ID: <f-MOqAGpITXeux3NUnMifNJg94uHENqmuTagj-JCfIg=.fce64457-cbc5-4113-a074-c41b42612797@github.com>

On Wed, 3 Dec 2025 13:33:31 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
> Tested with monkeyTester and the test in the bug

Forgot to mention: the text layout geometry depends on the padding/borders, please make sure they are taken into account.

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3609893349

From zjx001202 at gmail.com  Thu Dec  4 05:35:06 2025
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 4 Dec 2025 13:35:06 +0800
Subject: WebP and AVIF image support
In-Reply-To: <CAJEpuXQkfE1zUMk2yvwgQxtXrSPzn5+YA0uiC8WfDbKeU+XcuA@mail.gmail.com>
References: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
 <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAJEpuXQkfE1zUMk2yvwgQxtXrSPzn5+YA0uiC8WfDbKeU+XcuA@mail.gmail.com>
Message-ID: <CAJL5A3nYEvy9u=KFUG=X6zhcbKsvB1_JiumySrqbxixFMZi2SA@mail.gmail.com>

Hi Michael,

There's no need for your workaround. If you have TwelveMonkeys bundled
> with your application, JavaFX can read all of the supported images
> "natively" without manually converting to BufferedImage first. You
> just specify the WebP file in the constructor of Image.


I know we could do this starting with JavaFX 24, but most of our users are
using Java 21, and we need to maintain compatibility with JavaFX 14 in the
long term, so we haven't made any special handling for JavaFX 24+ for the
time being.

However, if JavaFX natively supports WebP, the benefits would make us
willing to maintain an additional if-else statement.

Glavo

On Thu, Dec 4, 2025 at 4:21?AM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> > For example, our application needs to display icons for Minecraft mods,
> modpacks, and other content sourced from Modrinth, and the vast majority of
> these icons are in WebP format. To work around this, we currently have to
> bundle TwelveMonkeys into our program, decode the images to BufferedImage,
> and then convert them to javafx.scene.image.Image. This approach
> significantly increases the size of our application, adds considerable
> performance overhead, does not support animated WebP, and even has a
> color-shift bug when decoding lossy-compressed WebP images.
> >
> > Is there any possibility that JavaFX will add native support for modern
> image formats like WebP and AVIF in the future? I noticed that the
> javafx.web module already depends on libwebp during its build, yet this
> dependency is not utilized for javafx.scene.image.Image decoding?which is
> honestly a bit of a shame. We sincerely hope that JavaFX can provide native
> support for these formats.
>
>
> There's no need for your workaround. If you have TwelveMonkeys bundled
> with your application, JavaFX can read all of the supported images
> "natively" without manually converting to BufferedImage first. You
> just specify the WebP file in the constructor of Image.
>
> What's true is that this doesn't work for animated images.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/8c30aeac/attachment-0001.htm>

From zjx001202 at gmail.com  Thu Dec  4 05:54:23 2025
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 4 Dec 2025 13:54:23 +0800
Subject: WebP and AVIF image support
In-Reply-To: <cb1d8d0c-0372-4e35-8b27-6377c0b71108@oracle.com>
References: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
 <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <cb1d8d0c-0372-4e35-8b27-6377c0b71108@oracle.com>
Message-ID: <CAJL5A3=rBVkyq3VPratMUtWnfL-BjVtUgXd-1egYAzkqD-Lrkg@mail.gmail.com>

Hi Kevin,

Compared to other difficulties, the most troublesome part of TwelveMonkeys
for us was the color shift bug[1] when decoding images.
Our program allows users to choose their own background images, but this
bug is causing all WebP background pictures to appear greenish :(

Additionally, JavaFX still doesn?t natively support any high-quality
animated image format.
GIF quality is too poor. To support high-quality animated images, we had no
choice but to implement APNG decoding ourselves in the program.
However, APNG files are insanely large ? one of my 5-second, 1920?1080, 60
fps animated wallpapers ends up reaching 1 GiB in size, which makes APNG
almost equally impractical.
It would be great if JavaFX could natively support animated WebP.

Glavo

[1]: https://github.com/haraldk/TwelveMonkeys/issues/734

On Thu, Dec 4, 2025 at 4:31?AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> We don't currently have any plans to add such support, but could consider
> it if there was enough demand.
>
> Now that we have support for using Java2D's ImageIO an application could
> provide one or use a third-party ImageIO loader for those formats, but that
> would have similar limitations to those mentioned (it wouldn't support
> animated images and the application would need to bundle the loader).
>
> -- Kevin
>
>
> On 12/3/2025 12:09 PM, Andy Goryachev wrote:
>
> And HEIC.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
> <openjfx-dev-retn at openjdk.org> on behalf of Glavo <zjx001202 at gmail.com>
> <zjx001202 at gmail.com>
> *Date: *Wednesday, December 3, 2025 at 12:01
> *To: *openjfx-dev <openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org>
> *Subject: *WebP and AVIF image support
>
> Hi,
>
> The image formats supported by JavaFX have not been updated for a very
> long time. However, more and more content providers are now adopting newer
> formats such as WebP and AVIF.
>
> For example, our application needs to display icons for Minecraft mods,
> modpacks, and other content sourced from Modrinth, and the vast majority of
> these icons are in WebP format. To work around this, we currently have to
> bundle TwelveMonkeys into our program, decode the images to BufferedImage,
> and then convert them to javafx.scene.image.Image. This approach
> significantly increases the size of our application, adds considerable
> performance overhead, does not support animated WebP, and even has a
> color-shift bug when decoding lossy-compressed WebP images.
>
> Is there any possibility that JavaFX will add native support for modern
> image formats like WebP and AVIF in the future? I noticed that the
> javafx.web module already depends on libwebp during its build, yet this
> dependency is not utilized for javafx.scene.image.Image decoding?which is
> honestly a bit of a shame. We sincerely hope that JavaFX can provide native
> support for these formats.
>
> Glavo
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/aa82057b/attachment.htm>

From lukasz.kostyra at oracle.com  Thu Dec  4 10:52:04 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Thu, 4 Dec 2025 10:52:04 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <e9d69da3-e2e9-4e8a-80ff-84430983872a@xpipe.io>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io>
 <DM3PPF3367D7B9B751B25F083A68EF6D7F0FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <c21d8e4a-7269-4290-8a70-54cbccd8a782@xpipe.io>
 <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io>
 <IA3PR10MB8682C066B2046DBD40631D0CFEC9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <IA3PR10MB8682E4623B0A4251DBAF9AAEFEDCA@IA3PR10MB8682.namprd10.prod.outlook.com>
 <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io>
 <IA3PR10MB868298C18CF5080852E3DCE3FED9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <e9d69da3-e2e9-4e8a-80ff-84430983872a@xpipe.io>
Message-ID: <DM3PPF3367D7B9B6FC6AF955C783A9EA92AFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

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:

[cid:image001.png at 01DC6514.67022F60]

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 01DC6514.67022F60]

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/20251204/b4523220/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/20251204/b4523220/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/20251204/b4523220/image002-0001.png>

From lukasz.kostyra at oracle.com  Thu Dec  4 10:54:09 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Thu, 4 Dec 2025 10:54:09 +0000
Subject: JavaFX Direct3D 12 - Call for performance testing help
In-Reply-To: <trinity-af93a0f7-76a4-417a-b03c-0544da356bfa-1764790298600@trinity-msg-rest-webde-webde-live-6769db957f-44674>
References: <DM3PPF3367D7B9B1D0248F8207E3935054BFECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <IA3PR10MB8682E5772DA242391EE8DC8FFECAA@IA3PR10MB8682.namprd10.prod.outlook.com>
 <trinity-af93a0f7-76a4-417a-b03c-0544da356bfa-1764790298600@trinity-msg-rest-webde-webde-live-6769db957f-44674>
Message-ID: <DM3PPF3367D7B9B07AE12E847D61142CF9FFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Thanks for testing! They seem to be mostly in line with what we see as well.

I will take a closer look at those and work on improving those soon after I?m done with functional bugs we caught since EA2 :)

-Lukasz

From: Marius Hanl <mariushanl at web.de>
Sent: Wednesday, 3 December 2025 20:32
To: Lukasz Kostyra <lukasz.kostyra at oracle.com>; openjfx-dev at openjdk.org
Subject: [External] : RE: RE: JavaFX Direct3D 12 - Call for performance testing help

Hi Lukasz,

finally, here are my benchmarks.
I can confirm what you found out earlier.

Some 3D shapes seems to perform better.
Especially Text Rendering seems way worse right now, as expected.

#1 - Tower PC
- AMD Ryzen 9 5900X
- AMD Radeon RX 6900 XT

D3D12
Test;objectCount;FPS
3DBox;20000;28,73
3DCylinder;20000;28,77
3DMesh;15000;12,50
3DSphere;20000;35,57
Arc;6500;15,27
Button;5000;12,40
Circle;70000;8,87
CircleBlendAdd;22500;14,13
CircleBlendDarken;22500;14,13
CircleBlendMultiply;22500;14,10
CircleRH;12500;13,00
ColorText;25000;1,00
CubicCurve;40000;10,50
Ellipse;70000;8,70
Image;70000;9,30
ImageRH;70000;9,23
Label;5000;17,80
LargeColorText;30000;1,50
LargeText;30000;1,50
LinGradCircle;40000;8,93
Line;70000;8,70
MultiShape2D;22500;11,83
MultiShape2D3D;22500;27,33
MultiShape2D3DInterleaved;15000;24,00
MultiShape2DInterleaved;12500;14,97
MultiShape3D;12500;50,37
MultiShape3DInterleaved;12500;36,50
OpenArc;5000;17,03
Path;40000;10,67
Polygon;47500;9,50
QuadCurve;47500;10,20
RadGradCircle;4000;29,93
RandomSizeText;22500;1,10
Rectangle;70000;8,63
RotatedRectangleRH;47500;6,60
StrokedCircle;70000;8,10
StrokedPolygon;47500;5,53
StrokedRectangle;70000;8,10
WhiteText;22500;1,00
D3D
Test;objectCount;FPS
3DBox;20000;31,97
3DCylinder;20000;34,13
3DMesh;15000;28,77
3DSphere;20000;20,27
Arc;6500;16,97
Button;5000;13,07
Circle;70000;20,47
CircleBlendAdd;22500;11,10
CircleBlendDarken;22500;11,00
CircleBlendMultiply;22500;10,83
CircleRH;12500;15,73
ColorText;25000;14,50
CubicCurve;40000;27,33
Ellipse;70000;19,07
Image;70000;33,37
ImageRH;70000;19,67
Label;5000;15,60
LargeColorText;30000;16,30
LargeText;30000;16,27
LinGradCircle;40000;24,87
Line;70000;18,33
MultiShape2D;22500;16,57
MultiShape2D3D;22500;32,43
MultiShape2D3DInterleaved;15000;16,63
MultiShape2DInterleaved;12500;8,93
MultiShape3D;12500;40,67
MultiShape3DInterleaved;12500;26,07
OpenArc;5000;18,97
Path;40000;25,50
Polygon;47500;22,40
QuadCurve;47500;24,17
RadGradCircle;4000;14,90
RandomSizeText;22500;16,10
Rectangle;70000;16,60
RotatedRectangleRH;47500;17,47
StrokedCircle;70000;20,90
StrokedPolygon;47500;20,97
StrokedRectangle;70000;15,80
WhiteText;22500;16,80
#2 - Laptop, only iGPU
- AMD Ryzen 9 9955HX3D
- iGPU: AMD Radeon(TM) 610M

D3D12
Test;objectCount;FPS
3DBox;20000;18,43
3DCylinder;20000;12,80
3DMesh;15000;6,90
3DSphere;20000;6,50
Arc;6500;13,87
Button;5000;5,20
Circle;70000;8,93
CircleBlendAdd;22500;15,63
CircleBlendDarken;22500;15,53
CircleBlendMultiply;22500;15,43
CircleRH;12500;13,03
ColorText;25000;0,80
CubicCurve;40000;11,67
Ellipse;70000;8,90
Image;70000;8,93
ImageRH;70000;8,97
Label;5000;20,87
LargeColorText;30000;0,70
LargeText;30000;0,70
LinGradCircle;40000;10,47
Line;70000;8,30
MultiShape2D;22500;10,77
MultiShape2D3D;22500;15,00
MultiShape2D3DInterleaved;15000;20,63
MultiShape2DInterleaved;12500;15,67
MultiShape3D;12500;17,97
MultiShape3DInterleaved;12500;17,00
OpenArc;5000;16,10
Path;40000;10,97
Polygon;47500;9,60
QuadCurve;47500;10,03
RadGradCircle;4000;43,50
Rectangle;70000;8,50
RotatedRectangleRH;47500;9,43
StrokedCircle;70000;8,53
StrokedPolygon;47500;10,60
StrokedRectangle;70000;8,67
WhiteText;22500;0,90

D3D
Test;objectCount;FPS
3DBox;20000;7,53
3DCylinder;20000;5,20
3DMesh;15000;5,83
3DSphere;20000;3,53
Arc;6500;14,73
Button;5000;2,30
Circle;70000;11,77
CircleBlendAdd;22500;12,00
CircleBlendDarken;22500;12,30
CircleBlendMultiply;22500;12,13
CircleRH;12500;11,33
ColorText;25000;10,90
CubicCurve;40000;23,10
Ellipse;70000;6,37
Image;70000;11,73
ImageRH;70000;11,87
Label;5000;19,93
LargeColorText;30000;5,43
LargeText;30000;5,53
LinGradCircle;40000;8,63
Line;70000;19,93
MultiShape2D;22500;10,70
MultiShape2D3D;22500;8,77
MultiShape2D3DInterleaved;15000;11,37
MultiShape2DInterleaved;12500;10,53
MultiShape3D;12500;8,93
MultiShape3DInterleaved;12500;7,23
OpenArc;5000;17,57
Path;40000;12,70
Polygon;47500;20,47
QuadCurve;47500;21,63
RadGradCircle;4000;18,27
Rectangle;70000;13,07
RotatedRectangleRH;47500;17,43
StrokedCircle;70000;10,20
StrokedPolygon;47500;17,40
StrokedRectangle;70000;10,80
WhiteText;22500;12,83

#3 - Laptop, with dGPU
- AMD Ryzen 9 9955HX3D
- iGPU: AMD Radeon(TM) 610M
- dGPU: NVIDIA GeForce RTX 5080 Laptop GPU

D3D12
Test;objectCount;FPS
3DBox;20000;39,73
3DCylinder;20000;37,67
3DMesh;15000;32,13
3DSphere;20000;47,93
Arc;6500;8,10
Button;5000;1,30
Circle;70000;1,00
CircleBlendAdd;22500;2,20
CircleBlendDarken;22500;2,20
CircleBlendMultiply;22500;2,20
CircleRH;12500;6,27
ColorText;25000;0,00
CubicCurve;40000;3,17
Ellipse;70000;1,90
Image;70000;1,90
ImageRH;70000;1,90
Label;5000;2,60
LargeColorText;30000;0,00
LargeText;30000;0,00
LinGradCircle;40000;1,60
Line;70000;1,00
MultiShape2D;22500;4,30
MultiShape2D3D;22500;10,20
MultiShape2D3DInterleaved;15000;13,30
MultiShape2DInterleaved;12500;7,70
MultiShape3D;12500;76,87
MultiShape3DInterleaved;12500;58,33
OpenArc;5000;9,93
Path;40000;3,10
Polygon;47500;2,63
QuadCurve;47500;2,60
RadGradCircle;4000;27,30
Rectangle;70000;1,00
RotatedRectangleRH;47500;1,40
StrokedCircle;70000;1,13
StrokedPolygon;47500;2,07
StrokedRectangle;70000;1,87
WhiteText;22500;0,00

D3D
Test;objectCount;FPS
3DBox;20000;59,40
3DCylinder;20000;56,87
3DMesh;15000;16,57
3DSphere;20000;57,30
Arc;6500;10,03
Button;5000;5,63
Circle;70000;43,63
CircleBlendAdd;22500;56,60
CircleBlendDarken;22500;55,57
CircleBlendMultiply;22500;54,57
CircleRH;12500;8,83
ColorText;25000;19,23
CubicCurve;40000;35,87
Ellipse;70000;19,53
Image;70000;41,57
ImageRH;70000;34,93
Label;5000;72,20
LargeColorText;30000;17,97
LargeText;30000;15,93
LinGradCircle;40000;32,40
Line;70000;20,17
MultiShape2D;22500;10,70
MultiShape2D3D;22500;78,77
MultiShape2D3DInterleaved;15000;52,80
MultiShape2DInterleaved;12500;20,67
MultiShape3D;12500;87,70
MultiShape3DInterleaved;12500;74,47
OpenArc;5000;12,43
Path;40000;31,67
Polygon;47500;27,60
QuadCurve;47500;31,67
RadGradCircle;4000;28,70
Rectangle;70000;20,97
RotatedRectangleRH;47500;23,23
StrokedCircle;70000;34,57
StrokedPolygon;47500;24,53
StrokedRectangle;70000;19,53
WhiteText;22500;24,97

Also attached all results.

-- Marius

Gesendet: Freitag, 14. November 2025 um 15:10
Von: "Lukasz Kostyra" <lukasz.kostyra at oracle.com<mailto:lukasz.kostyra at oracle.com>>
An: "openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>" <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Betreff: RE: JavaFX Direct3D 12 - Call for performance testing help
Hello all,

I got feedback on the previous call for performance testing email that, instead of using the Bash test script on Windows (and hoping you have Cygwin/MINGW installed) it would be easier to integrate testing and CSV output functionality into RenderPerfTest. I made those changes and they are now available on jfx-sandbox direct3d12 branch (you WON?T find those on main repo yet): https://github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf__;!!ACWV5N9M2RV99hQ!OPDGeZcoI8FCHDUo-VSzEu04GgAdiAsA-L-P3Yr0BQi7U99rj3vcn1EXCwJXdQEoJFydRrZ9aVcJ78LmN2mV5C03$>

Any feedback regarding RenderPerfTest will be updated on that branch automatically, so it?s indeed a better solution if there?s more feedback to it :)

New steps for running tests:

  1.  Download RenderPerfTest from above link (has to be jfx-sandbox repo, direct3d12 branch) - best to download the entire ?renderperf? folder as ZIP as it contains extra resources needed for the test app
  2.  Get JavaFX Direct3D 12 build - either download the EA2 SDK from [ https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!OPDGeZcoI8FCHDUo-VSzEu04GgAdiAsA-L-P3Yr0BQi7U99rj3vcn1EXCwJXdQEoJFydRrZ9aVcJ78LmNxHJSc0g$> ] or build it from scratch from direct3d12 [ https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!OPDGeZcoI8FCHDUo-VSzEu04GgAdiAsA-L-P3Yr0BQi7U99rj3vcn1EXCwJXdQEoJFydRrZ9aVcJ78LmN8EQENBY$> ] branch (make sure to build with -PCONF=Release; at the time of writing this email there is no functional difference between the sandbox repo and the EA2 build).
  3.  RenderPerf can be run with (underlined parts you need to fill in yourself):
    java --upgrade-module-path="<path_to_jfx_sdk>/lib" --add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media --enable-native-access=javafx.graphics -Dprism.order=<backend> renderperf/RenderPerfTest.java --output-csv -r <runs>
Where:
    <path_to_jfx_sdk> -  path to directory where JavaFX SDK is located (has to be where JavaFX bin and lib folders reside)
    <backend> -  short-hand for which Prism backend to use
    <runs>  - how many times each test case should run; RenderPerf will average FPS results from these runs



  1.  Running RenderPerf like above will produce RenderPerf_results-<backend>-<date>-<time>.csv in your current directory.

Examples:

  1.  For D3D baseline test, run:
    java --upgrade-module-path="<path_to_jfx_sdk>/lib" --add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media, --enable-native-access=javafx.graphics -Dprism.order=d3d renderperf/RenderPerfTest.java --output-csv -r 3
  2.  For D3D12 baseline test, run:
    java --upgrade-module-path="<path_to_jfx_sdk>/lib" --add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media, --enable-native-access=javafx.graphics -Dprism.order=d3d12 renderperf/RenderPerfTest.java --output-csv -r 3

Notes:
* Closing the test on warm-up stage will stop the test run early
* Similarly to the test script, RenderPerfTest defines default object numbers at the beginning as Map<String, Integer> defaultObjectCounts which are used for running all the tests. Similar remarks as to the test script apply - It would be preferred to keep these numbers as-is but if needed (test timeouts loading, or framerate on baseline D3D run is very low (below 15FPS) ) they can be lowered, as long as they remain consistent between D3D and D3D12 runs.

Thanks once again for your help!
-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> On Behalf Of Lukasz Kostyra
Sent: Thursday, 13 November 2025 15:50
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>
Subject: JavaFX Direct3D 12 - Call for performance testing help

Hello openjfx-dev,

Because Windows is very open hardware-wise, it is difficult to prepare the backend for all possible hardware combinations available, especially from performance perspective. To make sure JavaFX performance does not degrade compared to old D3D backend we would like to call for volunteers to help performance-test the backend. These tests will let us get a general idea on how the backend behaves on different hardware and which areas of the backend to focus on while moving forward with optimization effort for Direct3D 12.

At this point we tested the backend quite extensively on Intel-based integrated GPUs and did some testing on a machine running a recent discrete Nvidia GPU. We are primarily looking for testing Direct3D 12 backend on a system running an AMD discrete GPU, but any hardware combinations are welcome - the more the merrier :). Also note that these tests require a Windows machine, as D3D12 backend is Windows-only.

We run performance testing using RenderPerfTest JavaFX app located in the JavaFX repository under "tests/performance/animation/RenderPerfTest". I wrote a bash script to use with this app for performance-testing the backend. The script will run all available demos on RenderPerfTest with a set amount of objects per test, average the FPS results from each run and output the results into a CSV file.


How to run perf tests:

  1.  Download the test script - https://gist.github.com/lukostyra/bc354a5fd845b82805ffb3380caebe9a<https://urldefense.com/v3/__https:/gist.github.com/lukostyra/bc354a5fd845b82805ffb3380caebe9a__;!!ACWV5N9M2RV99hQ!OPDGeZcoI8FCHDUo-VSzEu04GgAdiAsA-L-P3Yr0BQi7U99rj3vcn1EXCwJXdQEoJFydRrZ9aVcJ78LmN-QEXWQp$>
  2.  Get JavaFX Direct3D 12 build - either download the EA2 SDK from [ https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!OPDGeZcoI8FCHDUo-VSzEu04GgAdiAsA-L-P3Yr0BQi7U99rj3vcn1EXCwJXdQEoJFydRrZ9aVcJ78LmNxHJSc0g$> ] or build it from scratch from direct3d12 [ https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!OPDGeZcoI8FCHDUo-VSzEu04GgAdiAsA-L-P3Yr0BQi7U99rj3vcn1EXCwJXdQEoJFydRrZ9aVcJ78LmN8EQENBY$> ] branch (make sure to build with -PCONF=Release; at the time of writing this email there is no functional difference between the sandbox repo and the EA2 build).
  3.  Put the script in the same directory as renderperf/RenderPerfTest.java - I usually copy the contents of tests/performance/animation/RenderPerfTest/src into a separate directory where the script is located. The script will look in the current directory specifically for "renderperf" directory containing a "RenderPerfTest.java" source file.
  4.  Ensure nothing else is running on your system.
  5.  Perform a baseline test run with D3D backend:
   ./run_renderperf_all.sh -j <path_to_jfx_sdk> -b d3d -r 3
When the script is done, this should result in "RenderPerf_results_d3d-<date>-<time>.csv" file. This will let us establish how your machine performs on RenderPerf?s test cases on the old D3D backend.
  6.  Perform a perf test run for D3D12 backend:
   ./run_renderperf_all.sh -j <path_to_jfx_sdk> -b d3d12 -r 3
This should result in "RenderPerf_results_d3d12-<date>-<time>.csv" file. The results will be used as a comparison to D3D backend.

Once you are done, reply to this email thread with details what hardware you ran the tests on and with contents of both CSV files specifying which came from which test run - I?m pretty sure attachments will be stripped when sending an email to the mailing list, so to make sure the results get to us you should paste them inline. Also, include the console output of running any JavaFX app on D3D12 backend with "-Dprism.verbose=true".

Note that these tests will run for quite a bit of time. Each test case's single run will take 15 seconds - 5 seconds of warm-up and 10 seconds of actual test run where FPS is measured. Testing every single case, 3 runs each, for a single backend takes approximately 40 minutes - ensure your computer won't lock or turn off the screens during that process.


Test script reference:
    ./run_renderperf_all.sh -j/--jfx <path_to_jfx_sdk> [-b/--backend <backend>] [-r/--runs <runs>]

Where:
    -j, --jfx  -  required; path to directory where JavaFX SDK is located (has to be where JavaFX bin and lib folders are located)
    -b, --backend  -  optional, defaults to "d3d12"; short-hand for which Prism backend to use. Whatever is set here will be forwarded to "-Dprism.order" property.
    -r, --runs  -  optional, defaults to 3; how many times each test case should run. Script will average FPS results from these runs.

Notes:
   * Closing currently running test during the warm-up stage (first 5 seconds since starting the execution of the test case) should stop the test script early.
  * Script starts by declaring an array of test cases and object counts to run. We recommend leaving those as they are, however if there are tests which do not load because of a "Timeout" message (the script will then exit early) or perform significantly worse on D3D backend (below 20 FPS) you can lower the object count and retry.


Let me know if you have any problems with running the tests. And, in advance, thanks for your help!

Regards,
Lukasz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/014e0a82/attachment-0001.htm>

From duke at openjdk.org  Thu Dec  4 14:43:18 2025
From: duke at openjdk.org (Alessadro Parisi)
Date: Thu, 4 Dec 2025 14:43:18 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: <SdUHESG8rXRdleOI9cH8zcEqIIFC9jiSNSgJ_uz2HgA=.249a2f18-776b-4ade-8a70-f2546a9fed7a@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <hajVA9L5jTPU0338Kv29KLifaTBb9PaRaEMTFVAojkE=.3ce941b5-f436-4817-8d2e-59165c2b9fec@github.com>
 <SdUHESG8rXRdleOI9cH8zcEqIIFC9jiSNSgJ_uz2HgA=.249a2f18-776b-4ade-8a70-f2546a9fed7a@github.com>
Message-ID: <AIfGHcTRfmZARDmLJO-i2Gk9GP7s4F4fI8xWTeiLAPA=.df7d0ed6-d0f1-4040-8c13-80720437ff37@github.com>

On Fri, 17 Oct 2025 02:50:19 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make leftSystemInset/rightSystemInset/minSystemHeight attached properties
>
> There's another thing that I think will improve the `HeaderBar`API:
> 
> The `leftSystemInset`, `rightSystemInset`, and `minSystemHeight`  properties shouldn't be normal properties, but attached properties for `Stage`. If you think about it, these aren't really properties of `HeaderBar`, but properties of `Stage` that are used in the context of `HeaderBar`.
> 
> We already have an attached property of this kind: `HeaderBar.getPrefButtonHeight(Stage)`. Having the other three properties defined similarly makes the API more consistent.
> 
> It should be noted that this will be the first instance of an _observable_ attached property in JavaFX. So while regular attached properties have a getter/setter pair like this...
> 
> class HBox {
>     static Insets getMargin(Node);
>     static void setMargin(Node, Insets);
> }
> 
> 
> ...an observable attached property will have an observable property getter:
> 
> class HeaderBar {
>     static ReadOnlyObjectProperty<Dimension2D> leftSystemInsetProperty(Stage);
>     static Dimension2D getLeftSystemInset(Stage);
> }
> 
> 
> The form of the property getter shouldn't be controversial, as it follows the existing getter/setter form for attached properties.
> 
> What needs to be clarified, however, is what `getBean()` and `getName()` should return for an attached observable property.
> Since an attached property is a part of the object it is attached to, the `getBean()` method should return that object. In our example, this means `HeaderBar.leftSystemInsetProperty(myStage).getBean() == myStage`.
> 
> For the `getName()` method, the usual convention is to return the lowerCamelCase name of the property. However, since an attached property is not declared on the object's class to which it is attached, the name shouldn't claim that it is. I propose a naming convention of the form `DeclaringType.myProperty`, that is, the property name is qualified with the declaring type. In our example, the name of the property would be "HeaderBar.leftSystemInset" (instead of just "leftSystemInset").

@mstr2 are there any plans to look at this:
<img width="908" height="508" alt="IMG_20251204_153610" src="https://github.com/user-attachments/assets/6306c678-38f3-4e8c-bcf1-933536403933" />

On Linux Min 22.2 with Cinnamon I get a rectangular window no matter what. I also tried setting the root's background color and radius, as well as the scene's fill to `TRANSPARENT` but nothing works.

One thing I'm curious about is why it was implemented this way. I mean, if the native decorations are just rendered on top of JavaFX nodes, then why I'm not able to set the scene's fill to `TRANSPARENT` and let the developer handle the rest.

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

PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3612579619

From nlisker at gmail.com  Thu Dec  4 15:27:41 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 4 Dec 2025 17:27:41 +0200
Subject: WebP and AVIF image support
In-Reply-To: <CAJL5A3=rBVkyq3VPratMUtWnfL-BjVtUgXd-1egYAzkqD-Lrkg@mail.gmail.com>
References: <CAJL5A3mCg077xJB=JZ6-CnvQHP9SpHf+sJpXiaWDcEy0P_8M-g@mail.gmail.com>
 <CY8PR10MB7265649BF8C103739F34A525E5D9A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <cb1d8d0c-0372-4e35-8b27-6377c0b71108@oracle.com>
 <CAJL5A3=rBVkyq3VPratMUtWnfL-BjVtUgXd-1egYAzkqD-Lrkg@mail.gmail.com>
Message-ID: <CA+0ynh8Sgbfcza5DYGMPGp=6ky0LRc9t00UTkuPwvReFf2Fbgw@mail.gmail.com>

There was a survey about media-related enhancement some years ago. I didn't
follow what came out of it.

https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034949.html

On Thu, Dec 4, 2025 at 7:55?AM Glavo <zjx001202 at gmail.com> wrote:

> Hi Kevin,
>
> Compared to other difficulties, the most troublesome part of TwelveMonkeys
> for us was the color shift bug[1] when decoding images.
> Our program allows users to choose their own background images, but this
> bug is causing all WebP background pictures to appear greenish :(
>
> Additionally, JavaFX still doesn?t natively support any high-quality
> animated image format.
> GIF quality is too poor. To support high-quality animated images, we had
> no choice but to implement APNG decoding ourselves in the program.
> However, APNG files are insanely large ? one of my 5-second, 1920?1080, 60
> fps animated wallpapers ends up reaching 1 GiB in size, which makes APNG
> almost equally impractical.
> It would be great if JavaFX could natively support animated WebP.
>
> Glavo
>
> [1]: https://github.com/haraldk/TwelveMonkeys/issues/734
>
> On Thu, Dec 4, 2025 at 4:31?AM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> We don't currently have any plans to add such support, but could consider
>> it if there was enough demand.
>>
>> Now that we have support for using Java2D's ImageIO an application could
>> provide one or use a third-party ImageIO loader for those formats, but that
>> would have similar limitations to those mentioned (it wouldn't support
>> animated images and the application would need to bundle the loader).
>>
>> -- Kevin
>>
>>
>> On 12/3/2025 12:09 PM, Andy Goryachev wrote:
>>
>> And HEIC.
>>
>> -andy
>>
>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>> <openjfx-dev-retn at openjdk.org> on behalf of Glavo <zjx001202 at gmail.com>
>> <zjx001202 at gmail.com>
>> *Date: *Wednesday, December 3, 2025 at 12:01
>> *To: *openjfx-dev <openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org>
>> *Subject: *WebP and AVIF image support
>>
>> Hi,
>>
>> The image formats supported by JavaFX have not been updated for a very
>> long time. However, more and more content providers are now adopting newer
>> formats such as WebP and AVIF.
>>
>> For example, our application needs to display icons for Minecraft mods,
>> modpacks, and other content sourced from Modrinth, and the vast majority of
>> these icons are in WebP format. To work around this, we currently have to
>> bundle TwelveMonkeys into our program, decode the images to BufferedImage,
>> and then convert them to javafx.scene.image.Image. This approach
>> significantly increases the size of our application, adds considerable
>> performance overhead, does not support animated WebP, and even has a
>> color-shift bug when decoding lossy-compressed WebP images.
>>
>> Is there any possibility that JavaFX will add native support for modern
>> image formats like WebP and AVIF in the future? I noticed that the
>> javafx.web module already depends on libwebp during its build, yet this
>> dependency is not utilized for javafx.scene.image.Image decoding?which is
>> honestly a bit of a shame. We sincerely hope that JavaFX can provide native
>> support for these formats.
>>
>> Glavo
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/0dbe386a/attachment.htm>

From angorya at openjdk.org  Thu Dec  4 16:28:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Dec 2025 16:28:08 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
 <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
Message-ID: <vOSJn1wFhQiUd_gBVS9cYdQSSJRY_PBLEfejWbBujlk=.323fee08-573f-4487-9032-22c5e283c7a1@github.com>

On Tue, 2 Dec 2025 17:10:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
>> 
>> Test cases:
>> 
>>     @Test
>>     public void addTextAfterRegion() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addParagraph(() -> new Region());
>>         m.addNodeSegment(() -> new Region());
>>         assertEquals(2, m.size());
>>     }
>> 
>>     @Test
>>     public void addTextAfterRegionAfterText() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addNodeSegment(() -> new Region());
>>         m.addParagraph(() -> new Region());
>>         m.addSegment("text");
>>         assertEquals(3, m.size());
>>     }
>
> Andy Goryachev 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372438.non.text.paragraphs
>  - fix

@Ziad-Mid could you please review this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1983#issuecomment-3613081352

From tsayao at openjdk.org  Thu Dec  4 17:55:34 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 4 Dec 2025 17:55:34 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: <AIfGHcTRfmZARDmLJO-i2Gk9GP7s4F4fI8xWTeiLAPA=.df7d0ed6-d0f1-4040-8c13-80720437ff37@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <hajVA9L5jTPU0338Kv29KLifaTBb9PaRaEMTFVAojkE=.3ce941b5-f436-4817-8d2e-59165c2b9fec@github.com>
 <SdUHESG8rXRdleOI9cH8zcEqIIFC9jiSNSgJ_uz2HgA=.249a2f18-776b-4ade-8a70-f2546a9fed7a@github.com>
 <AIfGHcTRfmZARDmLJO-i2Gk9GP7s4F4fI8xWTeiLAPA=.df7d0ed6-d0f1-4040-8c13-80720437ff37@github.com>
Message-ID: <CzDFgczRqvsmDjuabrwc6DKA1S30J3TNqaJouHOWBUg=.9848a452-4a06-4c87-b26f-8f09516d2d37@github.com>

On Thu, 4 Dec 2025 14:40:43 GMT, Alessadro Parisi <duke at openjdk.org> wrote:

>> There's another thing that I think will improve the `HeaderBar`API:
>> 
>> The `leftSystemInset`, `rightSystemInset`, and `minSystemHeight`  properties shouldn't be normal properties, but attached properties for `Stage`. If you think about it, these aren't really properties of `HeaderBar`, but properties of `Stage` that are used in the context of `HeaderBar`.
>> 
>> We already have an attached property of this kind: `HeaderBar.getPrefButtonHeight(Stage)`. Having the other three properties defined similarly makes the API more consistent.
>> 
>> It should be noted that this will be the first instance of an _observable_ attached property in JavaFX. So while regular attached properties have a getter/setter pair like this...
>> 
>> class HBox {
>>     static Insets getMargin(Node);
>>     static void setMargin(Node, Insets);
>> }
>> 
>> 
>> ...an observable attached property will have an observable property getter:
>> 
>> class HeaderBar {
>>     static ReadOnlyObjectProperty<Dimension2D> leftSystemInsetProperty(Stage);
>>     static Dimension2D getLeftSystemInset(Stage);
>> }
>> 
>> 
>> The form of the property getter shouldn't be controversial, as it follows the existing getter/setter form for attached properties.
>> 
>> What needs to be clarified, however, is what `getBean()` and `getName()` should return for an attached observable property.
>> Since an attached property is a part of the object it is attached to, the `getBean()` method should return that object. In our example, this means `HeaderBar.leftSystemInsetProperty(myStage).getBean() == myStage`.
>> 
>> For the `getName()` method, the usual convention is to return the lowerCamelCase name of the property. However, since an attached property is not declared on the object's class to which it is attached, the name shouldn't claim that it is. I propose a naming convention of the form `DeclaringType.myProperty`, that is, the property name is qualified with the declaring type. In our example, the name of the property would be "HeaderBar.leftSystemInset" (instead of just "leftSystemInset").
>
> @mstr2 are there any plans to look at this:
> <img width="908" height="508" alt="IMG_20251204_153610" src="https://github.com/user-attachments/assets/6306c678-38f3-4e8c-bcf1-933536403933" />
> 
> On Linux Min 22.2 with Cinnamon I get a rectangular window no matter what. I also tried setting the root's background color and radius, as well as the scene's fill to `TRANSPARENT` but nothing works.
> 
> One thing I'm curious about is why it was implemented this way. I mean, if the native decorations are just rendered on top of JavaFX nodes, then why I'm not able to set the scene's fill to `TRANSPARENT` and let the developer handle the rest.
> 
> Edit: btw this is quite the issue because I can't achieve a consistent look across the various systems. The only solution is to use a `TRANSPARENT` Stage and make my own window buttons, losing a ton of features though (resize, drag, snap assistants, etc.)

@palexdev 
In the case of linux, the decorations are a JavaFX overlay, the window manager (at least mutter) will not draw over the window.

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

PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3613559680

From credmond at certak.com  Thu Dec  4 18:40:41 2025
From: credmond at certak.com (Cormac Redmond)
Date: Thu, 4 Dec 2025 18:40:41 +0000
Subject: SortedList hanging on to references & preventing GC
Message-ID: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>

Hi,

I've traced a memory issue back to a SortedList (surprisingly), where it's
hanging on to objects that could/should have been GC'd.

SortedList's internal arrays will only grow (but not shrink) in line with
the source ObservableList (I'm sure there are reasons for this). So even
when your source ObservableList shrinks, SortedList is hanging on to
references to objects the source list once contained, even though they're
completely removed from the source list.

This leads to a substantial waste of memory, especially when just one
momentarily large dataset leads to a permanent spike in unnecessary memory
usage for the remainder for the application's lifetime. I'm sure I'm not
the first to raise this or ask about it & I'm going to guess there's a very
good reason for this behaviour. But could someone explain this? I would
have thought SortedList should/could remain as lean as the source list.
FilteredList is somewhat similar, except it stores an array of ints
(indexes), so less of a memory hit, but still pointless nonetheless.

Example GIF + code below: setup a typical sortable table (so,
ObservableList + FilteredList + SortableList), where the print button shows
that when you add a lot of data, and remove it, SortedList retains
references to all of the old objects. Some reflection is used to print that
information.

[image: sorted_list_mem.gif]


Code to reproduce:

public class SortedListMemWasteDemo extends Application {

    record PotentialLargeData(String info) {}

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        ObservableList<PotentialLargeData> masterData =
FXCollections.observableArrayList(
                new PotentialLargeData("Initial info 1"),
                new PotentialLargeData("Initial info 2"));

        TableColumn<PotentialLargeData, String> col = new
TableColumn<>("Info");
        col.setCellValueFactory(cellData -> new
SimpleStringProperty(cellData.getValue().info()));

        TableView<PotentialLargeData> table = new TableView<>();
        table.getColumns().add(col);

        FilteredList<PotentialLargeData> filteredData = new
FilteredList<>(masterData, item -> true);
        SortedList<PotentialLargeData> sortedData = new
SortedList<>(filteredData);
        sortedData.comparatorProperty().bind(table.comparatorProperty());
        table.setItems(sortedData);

        Button loadManyBtn = new Button("Add 10,000 items");
        loadManyBtn.setOnAction(e -> {
            System.out.println("Adding 10000 items to master data");
            masterData.clear();
            for (int i = 0; i < 10000; i++) masterData.add(new
PotentialLargeData("Info item " + i));
        });

        Button reduceBtn = new Button("Reduce to 2");
        reduceBtn.setOnAction(e -> {
            System.out.println("Reducing master data size to 2");
            masterData.setAll(new PotentialLargeData("New info 1"), new
PotentialLargeData("New info 2"));
        });

        Button printBtn = new Button("Print interal sizes");
        printBtn.setOnAction(e -> {
            try {
                System.out.println("Items the user sees: " +
sortedData.size());
                int[] filtered = (int[]) getFieldValue(filteredData,
"filtered");
                System.out.println("FilteredList.filtered length: " +
filtered.length);
                // This is a hidden and significant waste of memory
                Object[] sorted = (Object[]) getFieldValue(sortedData,
"sorted");
                System.out.println("SortedList.sorted length: " +
sorted.length);
            } catch (Exception ex) {
                throw new RuntimeException(ex);
            }
        });

        primaryStage.setScene(new Scene(new VBox(table, loadManyBtn,
reduceBtn, printBtn), 600, 400));
        primaryStage.show();
    }

    private static Object getFieldValue(Object object, String fieldName)
throws Exception {
        Field field = object.getClass().getDeclaredField(fieldName);
        field.setAccessible(true);
        return field.get(object);
    }
}


Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/cfaa2788/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/cfaa2788/sorted_list_mem-0001.gif>

From angorya at openjdk.org  Thu Dec  4 18:44:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Dec 2025 18:44:39 GMT
Subject: RFR: 8373098: RichTextArea: NPE in InputMethodRequests
Message-ID: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>

Fixes an NPE discovered while working on https://github.com/openjdk/jfx/pull/1975

To reproduce, run RichTextAreaDemoApp with a "2,000,000,000 Lines" model and try scrolling with the mouse wheel rapidly up and down.

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

Commit messages:
 - fix

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

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

From angorya at openjdk.org  Thu Dec  4 18:44:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Dec 2025 18:44:40 GMT
Subject: RFR: 8373098: RichTextArea: NPE in InputMethodRequests
In-Reply-To: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
References: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
Message-ID: <WfNEe5NSzvhM4_t8-q6V6RnNd5ck47FV3zkbRJlfNP0=.204914ef-45e1-40d4-88c9-251d6c6493d4@github.com>

On Thu, 4 Dec 2025 17:12:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixes an NPE discovered while working on https://github.com/openjdk/jfx/pull/1975
> 
> To reproduce, run RichTextAreaDemoApp with a "2,000,000,000 Lines" model and try scrolling with the mouse wheel rapidly up and down.

@lukostyra may I ask you to review this please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1997#issuecomment-3613709943

From john.hendrikx at gmail.com  Thu Dec  4 19:18:22 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 4 Dec 2025 20:18:22 +0100
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
Message-ID: <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>

This looks like a classic problem where unused elements in an array are
not nulled.? Looking at the code that updates the `size` field, there
are a few code paths that are not setting unused elements to null.? I
also saw no code that ever shrinks the arrays.? So it looks this
implementation is only half finished.

So, yes,?I'd say this is a bug.

> I'm going to guess there's a very good reason for this behaviour.
Time pressure and insufficient testing.

--John

On 04/12/2025 19:40, Cormac Redmond wrote:
> Hi,
>
> I've traced a memory issue back to a SortedList (surprisingly), where
> it's hanging on to objects that could/should have been GC'd.
>
> SortedList's internal arrays will only grow (but not shrink) in line
> with the source ObservableList (I'm sure there are reasons for this).
> So even when your source ObservableList shrinks, SortedList is hanging
> on to references to objects the source list once contained, even
> though they're completely removed from the?source list.
>
> This leads to a substantial waste of memory, especially when just one
> momentarily?large dataset leads to a permanent spike in unnecessary
> memory usage for the remainder?for the application's lifetime. I'm
> sure I'm not the first to raise this or ask about it & I'm going to
> guess there's a very good reason for this behaviour. But could someone
> explain this? I would have thought SortedList should/could remain as
> lean as the source list. FilteredList is somewhat similar, except it
> stores an array of ints (indexes), so less of a memory hit, but still
> pointless nonetheless.
>
> Example GIF + code below: setup a typical sortable table (so,
> ObservableList + FilteredList?+ SortableList), where the print button
> shows that when you add a lot of data, and remove it, SortedList
> retains references to all of the old objects. Some reflection is used
> to print that information.
>
> sorted_list_mem.gif
>
>
> Code to reproduce:
>
> public class SortedListMemWasteDemo extends Application {
>
> ? ? record PotentialLargeData(String info) {}
>
> ? ? public static void main(String[] args) {
> ? ? ? ? launch(args);
> ? ? }
>
> ? ? @Override
> ? ? public void start(Stage primaryStage) {
> ? ? ? ? ObservableList<PotentialLargeData> masterData =
> FXCollections.observableArrayList(
> ? ? ? ? ? ? ? ? new PotentialLargeData("Initial info 1"),
> ? ? ? ? ? ? ? ? new PotentialLargeData("Initial info 2"));
>
> ? ? ? ? TableColumn<PotentialLargeData, String> col = new
> TableColumn<>("Info");
> ? ? ? ? col.setCellValueFactory(cellData -> new
> SimpleStringProperty(cellData.getValue().info()));
> ? ? ? ?
> ? ? ? ? TableView<PotentialLargeData> table = new TableView<>();
> ? ? ? ? table.getColumns().add(col);
>
> ? ? ? ? FilteredList<PotentialLargeData> filteredData = new
> FilteredList<>(masterData, item -> true);
> ? ? ? ? SortedList<PotentialLargeData> sortedData = new
> SortedList<>(filteredData);
> ? ? ? ? sortedData.comparatorProperty().bind(table.comparatorProperty());
> ? ? ? ? table.setItems(sortedData);
>
> ? ? ? ? Button loadManyBtn = new Button("Add 10,000 items");
> ? ? ? ? loadManyBtn.setOnAction(e -> {
> ? ? ? ? ? ? System.out.println("Adding 10000 items to master data");
> ? ? ? ? ? ? masterData.clear();
> ? ? ? ? ? ? for (int i = 0; i < 10000; i++) masterData.add(new
> PotentialLargeData("Info item " + i));
> ? ? ? ? });
>
> ? ? ? ? Button reduceBtn = new Button("Reduce to 2");
> ? ? ? ? reduceBtn.setOnAction(e -> {
> ? ? ? ? ? ? System.out.println("Reducing master data size to 2");
> ? ? ? ? ? ? masterData.setAll(new PotentialLargeData("New info 1"),
> new PotentialLargeData("New info 2"));
> ? ? ? ? });
>
> ? ? ? ? Button printBtn = new Button("Print interal sizes");
> ? ? ? ? printBtn.setOnAction(e -> {
> ? ? ? ? ? ? try {
> ? ? ? ? ? ? ? ? System.out.println("Items the user sees: " +
> sortedData.size());
> ? ? ? ? ? ? ? ? int[] filtered = (int[]) getFieldValue(filteredData,
> "filtered");
> ? ? ? ? ? ? ? ? System.out.println("FilteredList.filtered length: " +
> filtered.length);
> ? ? ? ? ? ? ? ? // This is a hidden and significant waste of memory
> ? ? ? ? ? ? ? ? Object[] sorted = (Object[]) getFieldValue(sortedData,
> "sorted");
> ? ? ? ? ? ? ? ? System.out.println("SortedList.sorted length: " +
> sorted.length);
> ? ? ? ? ? ? } catch (Exception ex) {
> ? ? ? ? ? ? ? ? throw new RuntimeException(ex);
> ? ? ? ? ? ? }
> ? ? ? ? });
>
> ? ? ? ? primaryStage.setScene(new Scene(new VBox(table, loadManyBtn,
> reduceBtn, printBtn), 600, 400));
> ? ? ? ? primaryStage.show();
> ? ? }
>
> ? ? private static Object getFieldValue(Object object, String
> fieldName) throws Exception {
> ? ? ? ? Field field = object.getClass().getDeclaredField(fieldName);
> ? ? ? ? field.setAccessible(true);
> ? ? ? ? return field.get(object);
> ? ? }
> }
>
>
> Kind Regards,
> Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/d333facd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/d333facd/sorted_list_mem-0001.gif>

From andy.goryachev at oracle.com  Thu Dec  4 19:40:16 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 4 Dec 2025 19:40:16 +0000
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
Message-ID: <CY8PR10MB7265CD73103B4CEA9446EAC0E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>

> Time pressure and insufficient testing.

Alas!  I can create a ticket, unless someone has already created one.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Thursday, December 4, 2025 at 11:18
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: SortedList hanging on to references & preventing GC


This looks like a classic problem where unused elements in an array are not nulled.  Looking at the code that updates the `size` field, there are a few code paths that are not setting unused elements to null.  I also saw no code that ever shrinks the arrays.  So it looks this implementation is only half finished.

So, yes, I'd say this is a bug.

I'm going to guess there's a very good reason for this behaviour.
Time pressure and insufficient testing.

--John

On 04/12/2025 19:40, Cormac Redmond wrote:
Hi,

I've traced a memory issue back to a SortedList (surprisingly), where it's hanging on to objects that could/should have been GC'd.

SortedList's internal arrays will only grow (but not shrink) in line with the source ObservableList (I'm sure there are reasons for this). So even when your source ObservableList shrinks, SortedList is hanging on to references to objects the source list once contained, even though they're completely removed from the source list.

This leads to a substantial waste of memory, especially when just one momentarily large dataset leads to a permanent spike in unnecessary memory usage for the remainder for the application's lifetime. I'm sure I'm not the first to raise this or ask about it & I'm going to guess there's a very good reason for this behaviour. But could someone explain this? I would have thought SortedList should/could remain as lean as the source list. FilteredList is somewhat similar, except it stores an array of ints (indexes), so less of a memory hit, but still pointless nonetheless.

Example GIF + code below: setup a typical sortable table (so, ObservableList + FilteredList + SortableList), where the print button shows that when you add a lot of data, and remove it, SortedList retains references to all of the old objects. Some reflection is used to print that information.

[sorted_list_mem.gif]


Code to reproduce:

public class SortedListMemWasteDemo extends Application {

    record PotentialLargeData(String info) {}

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        ObservableList<PotentialLargeData> masterData = FXCollections.observableArrayList(
                new PotentialLargeData("Initial info 1"),
                new PotentialLargeData("Initial info 2"));

        TableColumn<PotentialLargeData, String> col = new TableColumn<>("Info");
        col.setCellValueFactory(cellData -> new SimpleStringProperty(cellData.getValue().info()));

        TableView<PotentialLargeData> table = new TableView<>();
        table.getColumns().add(col);

        FilteredList<PotentialLargeData> filteredData = new FilteredList<>(masterData, item -> true);
        SortedList<PotentialLargeData> sortedData = new SortedList<>(filteredData);
        sortedData.comparatorProperty().bind(table.comparatorProperty());
        table.setItems(sortedData);

        Button loadManyBtn = new Button("Add 10,000 items");
        loadManyBtn.setOnAction(e -> {
            System.out.println("Adding 10000 items to master data");
            masterData.clear();
            for (int i = 0; i < 10000; i++) masterData.add(new PotentialLargeData("Info item " + i));
        });

        Button reduceBtn = new Button("Reduce to 2");
        reduceBtn.setOnAction(e -> {
            System.out.println("Reducing master data size to 2");
            masterData.setAll(new PotentialLargeData("New info 1"), new PotentialLargeData("New info 2"));
        });

        Button printBtn = new Button("Print interal sizes");
        printBtn.setOnAction(e -> {
            try {
                System.out.println("Items the user sees: " + sortedData.size());
                int[] filtered = (int[]) getFieldValue(filteredData, "filtered");
                System.out.println("FilteredList.filtered length: " + filtered.length);
                // This is a hidden and significant waste of memory
                Object[] sorted = (Object[]) getFieldValue(sortedData, "sorted");
                System.out.println("SortedList.sorted length: " + sorted.length);
            } catch (Exception ex) {
                throw new RuntimeException(ex);
            }
        });

        primaryStage.setScene(new Scene(new VBox(table, loadManyBtn, reduceBtn, printBtn), 600, 400));
        primaryStage.show();
    }

    private static Object getFieldValue(Object object, String fieldName) throws Exception {
        Field field = object.getClass().getDeclaredField(fieldName);
        field.setAccessible(true);
        return field.get(object);
    }
}


Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/a02fc3ee/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: sorted_list_mem.gif
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/a02fc3ee/sorted_list_mem-0001.gif>

From andy.goryachev at oracle.com  Thu Dec  4 19:44:32 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 4 Dec 2025 19:44:32 +0000
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <CY8PR10MB7265CD73103B4CEA9446EAC0E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
 <CY8PR10MB7265CD73103B4CEA9446EAC0E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CY8PR10MB72656E806C8CC9D1108BAA56E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>

Spoke too soon: we already have
https://bugs.openjdk.org/browse/JDK-8184166
from 2017.

Question: are there any more places where we don't null the unused entries?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Andy Goryachev <andy.goryachev at oracle.com>
Date: Thursday, December 4, 2025 at 11:40
To: John Hendrikx <john.hendrikx at gmail.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: SortedList hanging on to references & preventing GC

> Time pressure and insufficient testing.

Alas!  I can create a ticket, unless someone has already created one.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Thursday, December 4, 2025 at 11:18
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: SortedList hanging on to references & preventing GC


This looks like a classic problem where unused elements in an array are not nulled.  Looking at the code that updates the `size` field, there are a few code paths that are not setting unused elements to null.  I also saw no code that ever shrinks the arrays.  So it looks this implementation is only half finished.

So, yes, I'd say this is a bug.

I'm going to guess there's a very good reason for this behaviour.
Time pressure and insufficient testing.

--John

On 04/12/2025 19:40, Cormac Redmond wrote:
Hi,

I've traced a memory issue back to a SortedList (surprisingly), where it's hanging on to objects that could/should have been GC'd.

SortedList's internal arrays will only grow (but not shrink) in line with the source ObservableList (I'm sure there are reasons for this). So even when your source ObservableList shrinks, SortedList is hanging on to references to objects the source list once contained, even though they're completely removed from the source list.

This leads to a substantial waste of memory, especially when just one momentarily large dataset leads to a permanent spike in unnecessary memory usage for the remainder for the application's lifetime. I'm sure I'm not the first to raise this or ask about it & I'm going to guess there's a very good reason for this behaviour. But could someone explain this? I would have thought SortedList should/could remain as lean as the source list. FilteredList is somewhat similar, except it stores an array of ints (indexes), so less of a memory hit, but still pointless nonetheless.

Example GIF + code below: setup a typical sortable table (so, ObservableList + FilteredList + SortableList), where the print button shows that when you add a lot of data, and remove it, SortedList retains references to all of the old objects. Some reflection is used to print that information.

[sorted_list_mem.gif]


Code to reproduce:

public class SortedListMemWasteDemo extends Application {

    record PotentialLargeData(String info) {}

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        ObservableList<PotentialLargeData> masterData = FXCollections.observableArrayList(
                new PotentialLargeData("Initial info 1"),
                new PotentialLargeData("Initial info 2"));

        TableColumn<PotentialLargeData, String> col = new TableColumn<>("Info");
        col.setCellValueFactory(cellData -> new SimpleStringProperty(cellData.getValue().info()));

        TableView<PotentialLargeData> table = new TableView<>();
        table.getColumns().add(col);

        FilteredList<PotentialLargeData> filteredData = new FilteredList<>(masterData, item -> true);
        SortedList<PotentialLargeData> sortedData = new SortedList<>(filteredData);
        sortedData.comparatorProperty().bind(table.comparatorProperty());
        table.setItems(sortedData);

        Button loadManyBtn = new Button("Add 10,000 items");
        loadManyBtn.setOnAction(e -> {
            System.out.println("Adding 10000 items to master data");
            masterData.clear();
            for (int i = 0; i < 10000; i++) masterData.add(new PotentialLargeData("Info item " + i));
        });

        Button reduceBtn = new Button("Reduce to 2");
        reduceBtn.setOnAction(e -> {
            System.out.println("Reducing master data size to 2");
            masterData.setAll(new PotentialLargeData("New info 1"), new PotentialLargeData("New info 2"));
        });

        Button printBtn = new Button("Print interal sizes");
        printBtn.setOnAction(e -> {
            try {
                System.out.println("Items the user sees: " + sortedData.size());
                int[] filtered = (int[]) getFieldValue(filteredData, "filtered");
                System.out.println("FilteredList.filtered length: " + filtered.length);
                // This is a hidden and significant waste of memory
                Object[] sorted = (Object[]) getFieldValue(sortedData, "sorted");
                System.out.println("SortedList.sorted length: " + sorted.length);
            } catch (Exception ex) {
                throw new RuntimeException(ex);
            }
        });

        primaryStage.setScene(new Scene(new VBox(table, loadManyBtn, reduceBtn, printBtn), 600, 400));
        primaryStage.show();
    }

    private static Object getFieldValue(Object object, String fieldName) throws Exception {
        Field field = object.getClass().getDeclaredField(fieldName);
        field.setAccessible(true);
        return field.get(object);
    }
}


Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/0c77b141/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: sorted_list_mem.gif
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/0c77b141/sorted_list_mem-0001.gif>

From kevin.rushforth at oracle.com  Thu Dec  4 19:52:55 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 4 Dec 2025 11:52:55 -0800
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <CY8PR10MB72656E806C8CC9D1108BAA56E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
 <CY8PR10MB7265CD73103B4CEA9446EAC0E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CY8PR10MB72656E806C8CC9D1108BAA56E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <48406cb8-0fb5-476b-aec3-ceb145f920a1@oracle.com>

Since there is already a bug tracking this, can you add the additional 
information and test case to the bug report?

-- Kevin


On 12/4/2025 11:44 AM, Andy Goryachev wrote:
> Spoke too soon: we already have
> https://bugs.openjdk.org/browse/JDK-8184166
> from 2017.
>
> Question: are there any more places where we don't null the unused 
> entries?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Andy 
> Goryachev <andy.goryachev at oracle.com>
> *Date: *Thursday, December 4, 2025 at 11:40
> *To: *John Hendrikx <john.hendrikx at gmail.com>, openjfx-dev at openjdk.org 
> <openjfx-dev at openjdk.org>
> *Subject: *Re: SortedList hanging on to references & preventing GC
>
> > Time pressure and insufficient testing.
>
> Alas! ?I can create a ticket, unless someone has already created one.
>
> -andy
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John 
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Thursday, December 4, 2025 at 11:18
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: SortedList hanging on to references & preventing GC
>
> This looks like a classic problem where unused elements in an array 
> are not nulled.? Looking at the code that updates the `size` field, 
> there are a few code paths that are not setting unused elements to 
> null.? I also saw no code that ever shrinks the arrays.? So it looks 
> this implementation is only half finished.
>
> So, yes,?I'd say this is a bug.
>
>     I'm going to guess there's a very good reason for this behaviour.
>
> Time pressure and insufficient testing.
>
> --John
>
> On 04/12/2025 19:40, Cormac Redmond wrote:
>
>     Hi,
>
>     I've traced a memory issue back to a SortedList (surprisingly),
>     where it's hanging on to objects that could/should have been GC'd.
>
>     SortedList's internal arrays will only grow (but not shrink) in
>     line with the source ObservableList (I'm sure there are reasons
>     for this). So even when your source ObservableList shrinks,
>     SortedList is hanging on to references to objects the source list
>     once contained, even though they're completely removed from
>     the?source list.
>
>     This leads to a substantial waste of memory, especially when just
>     one momentarily?large dataset leads to a permanent spike in
>     unnecessary memory usage for the remainder?for the application's
>     lifetime. I'm sure I'm not the first to raise this or ask about it
>     & I'm going to guess there's a very good reason for this
>     behaviour. But could someone explain this? I would have thought
>     SortedList should/could remain as lean as the source list.
>     FilteredList is somewhat similar, except it stores an array of
>     ints (indexes), so less of a memory hit, but still pointless
>     nonetheless.
>
>     Example GIF + code below: setup a typical sortable table (so,
>     ObservableList + FilteredList?+ SortableList), where the print
>     button shows that when you add a lot of data, and remove it,
>     SortedList retains references to all of the old objects. Some
>     reflection is used to print that information.
>
>     sorted_list_mem.gif
>
>
>     Code to reproduce:
>
>     public class SortedListMemWasteDemo extends Application {
>
>     ? ? record PotentialLargeData(String info) {}
>
>     ? ? public static void main(String[] args) {
>     ? ? ? ? launch(args);
>     ? ? }
>
>     ? ? @Override
>     ? ? public void start(Stage primaryStage) {
>     ? ? ? ? ObservableList<PotentialLargeData> masterData =
>     FXCollections.observableArrayList(
>     ? ? ? ? ? ? ? ? new PotentialLargeData("Initial info 1"),
>     ? ? ? ? ? ? ? ? new PotentialLargeData("Initial info 2"));
>
>     ? ? ? ? TableColumn<PotentialLargeData, String> col = new
>     TableColumn<>("Info");
>     ? ? ? ? col.setCellValueFactory(cellData -> new
>     SimpleStringProperty(cellData.getValue().info()));
>
>     ? ? ? ? TableView<PotentialLargeData> table = new TableView<>();
>     ? ? ? ? table.getColumns().add(col);
>
>     ? ? ? ? FilteredList<PotentialLargeData> filteredData = new
>     FilteredList<>(masterData, item -> true);
>     ? ? ? ? SortedList<PotentialLargeData> sortedData = new
>     SortedList<>(filteredData);
>     sortedData.comparatorProperty().bind(table.comparatorProperty());
>     ? ? ? ? table.setItems(sortedData);
>
>     ? ? ? ? Button loadManyBtn = new Button("Add 10,000 items");
>     ? ? ? ? loadManyBtn.setOnAction(e -> {
>     ? ? ? ? ? ? System.out.println("Adding 10000 items to master data");
>     ? ? ? ? ? ? masterData.clear();
>     ? ? ? ? ? ? for (int i = 0; i < 10000; i++) masterData.add(new
>     PotentialLargeData("Info item " + i));
>     ? ? ? ? });
>
>     ? ? ? ? Button reduceBtn = new Button("Reduce to 2");
>     ? ? ? ? reduceBtn.setOnAction(e -> {
>     ? ? ? ? ? ? System.out.println("Reducing master data size to 2");
>     ? ? ? ? ? ? masterData.setAll(new PotentialLargeData("New info
>     1"), new PotentialLargeData("New info 2"));
>     ? ? ? ? });
>
>     ? ? ? ? Button printBtn = new Button("Print interal sizes");
>     ? ? ? ? printBtn.setOnAction(e -> {
>     ? ? ? ? ? ? try {
>     ? ? ? ? ? ? ? ? System.out.println("Items the user sees: " +
>     sortedData.size());
>     ? ? ? ? ? ? ? ? int[] filtered = (int[])
>     getFieldValue(filteredData, "filtered");
>     ? ? ? ? ? ? ? ? System.out.println("FilteredList.filtered length:
>     " + filtered.length);
>     ? ? ? ? ? ? ? ? // This is a hidden and significant waste of memory
>     ? ? ? ? ? ? ? ? Object[] sorted = (Object[])
>     getFieldValue(sortedData, "sorted");
>     ? ? ? ? ? ? ? ? System.out.println("SortedList.sorted length: " +
>     sorted.length);
>     ? ? ? ? ? ? } catch (Exception ex) {
>     ? ? ? ? ? ? ? ? throw new RuntimeException(ex);
>     ? ? ? ? ? ? }
>     ? ? ? ? });
>
>     ? ? ? ? primaryStage.setScene(new Scene(new VBox(table,
>     loadManyBtn, reduceBtn, printBtn), 600, 400));
>     ? ? ? ? primaryStage.show();
>     ? ? }
>
>     ? ? private static Object getFieldValue(Object object, String
>     fieldName) throws Exception {
>     ? ? ? ? Field field = object.getClass().getDeclaredField(fieldName);
>     ? ? ? ? field.setAccessible(true);
>     ? ? ? ? return field.get(object);
>     ? ? }
>     }
>
>
>     Kind Regards,
>     Cormac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/dd179ff5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/dd179ff5/sorted_list_mem-0001.gif>

From andy.goryachev at oracle.com  Thu Dec  4 19:59:43 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 4 Dec 2025 19:59:43 +0000
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <48406cb8-0fb5-476b-aec3-ceb145f920a1@oracle.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
 <CY8PR10MB7265CD73103B4CEA9446EAC0E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CY8PR10MB72656E806C8CC9D1108BAA56E5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <48406cb8-0fb5-476b-aec3-ceb145f920a1@oracle.com>
Message-ID: <CY8PR10MB72650BBA92698E83BAF851FCE5A6A@CY8PR10MB7265.namprd10.prod.outlook.com>

Done.

This could be a good candidate for the next test sprint: a test for all other collections and maps to make sure shrinking operations do not hold on to references.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Thursday, December 4, 2025 at 11:53
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: SortedList hanging on to references & preventing GC

Since there is already a bug tracking this, can you add the additional information and test case to the bug report?

-- Kevin


On 12/4/2025 11:44 AM, Andy Goryachev wrote:
Spoke too soon: we already have
https://bugs.openjdk.org/browse/JDK-8184166
from 2017.

Question: are there any more places where we don't null the unused entries?

-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: Thursday, December 4, 2025 at 11:40
To: John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>, openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: SortedList hanging on to references & preventing GC

> Time pressure and insufficient testing.

Alas!  I can create a ticket, unless someone has already created one.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Thursday, December 4, 2025 at 11:18
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: SortedList hanging on to references & preventing GC


This looks like a classic problem where unused elements in an array are not nulled.  Looking at the code that updates the `size` field, there are a few code paths that are not setting unused elements to null.  I also saw no code that ever shrinks the arrays.  So it looks this implementation is only half finished.

So, yes, I'd say this is a bug.

I'm going to guess there's a very good reason for this behaviour.
Time pressure and insufficient testing.

--John

On 04/12/2025 19:40, Cormac Redmond wrote:
Hi,

I've traced a memory issue back to a SortedList (surprisingly), where it's hanging on to objects that could/should have been GC'd.

SortedList's internal arrays will only grow (but not shrink) in line with the source ObservableList (I'm sure there are reasons for this). So even when your source ObservableList shrinks, SortedList is hanging on to references to objects the source list once contained, even though they're completely removed from the source list.

This leads to a substantial waste of memory, especially when just one momentarily large dataset leads to a permanent spike in unnecessary memory usage for the remainder for the application's lifetime. I'm sure I'm not the first to raise this or ask about it & I'm going to guess there's a very good reason for this behaviour. But could someone explain this? I would have thought SortedList should/could remain as lean as the source list. FilteredList is somewhat similar, except it stores an array of ints (indexes), so less of a memory hit, but still pointless nonetheless.

Example GIF + code below: setup a typical sortable table (so, ObservableList + FilteredList + SortableList), where the print button shows that when you add a lot of data, and remove it, SortedList retains references to all of the old objects. Some reflection is used to print that information.

[sorted_list_mem.gif]


Code to reproduce:

public class SortedListMemWasteDemo extends Application {

    record PotentialLargeData(String info) {}

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        ObservableList<PotentialLargeData> masterData = FXCollections.observableArrayList(
                new PotentialLargeData("Initial info 1"),
                new PotentialLargeData("Initial info 2"));

        TableColumn<PotentialLargeData, String> col = new TableColumn<>("Info");
        col.setCellValueFactory(cellData -> new SimpleStringProperty(cellData.getValue().info()));

        TableView<PotentialLargeData> table = new TableView<>();
        table.getColumns().add(col);

        FilteredList<PotentialLargeData> filteredData = new FilteredList<>(masterData, item -> true);
        SortedList<PotentialLargeData> sortedData = new SortedList<>(filteredData);
        sortedData.comparatorProperty().bind(table.comparatorProperty());
        table.setItems(sortedData);

        Button loadManyBtn = new Button("Add 10,000 items");
        loadManyBtn.setOnAction(e -> {
            System.out.println("Adding 10000 items to master data");
            masterData.clear();
            for (int i = 0; i < 10000; i++) masterData.add(new PotentialLargeData("Info item " + i));
        });

        Button reduceBtn = new Button("Reduce to 2");
        reduceBtn.setOnAction(e -> {
            System.out.println("Reducing master data size to 2");
            masterData.setAll(new PotentialLargeData("New info 1"), new PotentialLargeData("New info 2"));
        });

        Button printBtn = new Button("Print interal sizes");
        printBtn.setOnAction(e -> {
            try {
                System.out.println("Items the user sees: " + sortedData.size());
                int[] filtered = (int[]) getFieldValue(filteredData, "filtered");
                System.out.println("FilteredList.filtered length: " + filtered.length);
                // This is a hidden and significant waste of memory
                Object[] sorted = (Object[]) getFieldValue(sortedData, "sorted");
                System.out.println("SortedList.sorted length: " + sorted.length);
            } catch (Exception ex) {
                throw new RuntimeException(ex);
            }
        });

        primaryStage.setScene(new Scene(new VBox(table, loadManyBtn, reduceBtn, printBtn), 600, 400));
        primaryStage.show();
    }

    private static Object getFieldValue(Object object, String fieldName) throws Exception {
        Field field = object.getClass().getDeclaredField(fieldName);
        field.setAccessible(true);
        return field.get(object);
    }
}


Kind Regards,
Cormac

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/a3ebe2ee/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: sorted_list_mem.gif
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/a3ebe2ee/sorted_list_mem-0001.gif>

From credmond at certak.com  Thu Dec  4 20:21:42 2025
From: credmond at certak.com (Cormac Redmond)
Date: Thu, 4 Dec 2025 20:21:42 +0000
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
Message-ID: <CAG_-AaD6XJh0Esih2OTjeP+MS7+UXMFBMUeF_vWViPcwj=A40w@mail.gmail.com>

Hi John,

Thanks for the prompt response. Yes, I looked into the code afterwards, and
I can see that it is just fairly oblivious to the waste. I was looking to
override with nulls myself, but there were too many privates.

The only solution (without re-writing my own impl) is to re-create the
SortedList every time the dataset is smaller, or to create some sort of DTO
that does not link to the original real objects in any way (or maybe use
WeakReferences). In my case, I could have 10,000 rows where each item's
underlying memory is around 500KB on the heap. That's instantly 5GB I
cannot re-claim, or example.

That code with the "bug" *mostly* hasn't changed in 10+ years. Can it be
fixed? It's such a fundamental class, adding workarounds (everywhere,
forever) would seem a shame.




Kind Regards,
Cormac

On Thu, 4 Dec 2025 at 20:01, John Hendrikx <john.hendrikx at gmail.com> wrote:

> This looks like a classic problem where unused elements in an array are
> not nulled.  Looking at the code that updates the `size` field, there are a
> few code paths that are not setting unused elements to null.  I also saw no
> code that ever shrinks the arrays.  So it looks this implementation is only
> half finished.
>
> So, yes, I'd say this is a bug.
>
> I'm going to guess there's a very good reason for this behaviour.
>
> Time pressure and insufficient testing.
>
> --John
> On 04/12/2025 19:40, Cormac Redmond wrote:
>
> Hi,
>
> I've traced a memory issue back to a SortedList (surprisingly), where it's
> hanging on to objects that could/should have been GC'd.
>
> SortedList's internal arrays will only grow (but not shrink) in line with
> the source ObservableList (I'm sure there are reasons for this). So even
> when your source ObservableList shrinks, SortedList is hanging on to
> references to objects the source list once contained, even though they're
> completely removed from the source list.
>
> This leads to a substantial waste of memory, especially when just one
> momentarily large dataset leads to a permanent spike in unnecessary memory
> usage for the remainder for the application's lifetime. I'm sure I'm not
> the first to raise this or ask about it & I'm going to guess there's a very
> good reason for this behaviour. But could someone explain this? I would
> have thought SortedList should/could remain as lean as the source list.
> FilteredList is somewhat similar, except it stores an array of ints
> (indexes), so less of a memory hit, but still pointless nonetheless.
>
> Example GIF + code below: setup a typical sortable table (so,
> ObservableList + FilteredList + SortableList), where the print button shows
> that when you add a lot of data, and remove it, SortedList retains
> references to all of the old objects. Some reflection is used to print that
> information.
>
> [image: sorted_list_mem.gif]
>
>
> Code to reproduce:
>
> public class SortedListMemWasteDemo extends Application {
>
>     record PotentialLargeData(String info) {}
>
>     public static void main(String[] args) {
>         launch(args);
>     }
>
>     @Override
>     public void start(Stage primaryStage) {
>         ObservableList<PotentialLargeData> masterData =
> FXCollections.observableArrayList(
>                 new PotentialLargeData("Initial info 1"),
>                 new PotentialLargeData("Initial info 2"));
>
>         TableColumn<PotentialLargeData, String> col = new
> TableColumn<>("Info");
>         col.setCellValueFactory(cellData -> new
> SimpleStringProperty(cellData.getValue().info()));
>
>         TableView<PotentialLargeData> table = new TableView<>();
>         table.getColumns().add(col);
>
>         FilteredList<PotentialLargeData> filteredData = new
> FilteredList<>(masterData, item -> true);
>         SortedList<PotentialLargeData> sortedData = new
> SortedList<>(filteredData);
>         sortedData.comparatorProperty().bind(table.comparatorProperty());
>         table.setItems(sortedData);
>
>         Button loadManyBtn = new Button("Add 10,000 items");
>         loadManyBtn.setOnAction(e -> {
>             System.out.println("Adding 10000 items to master data");
>             masterData.clear();
>             for (int i = 0; i < 10000; i++) masterData.add(new
> PotentialLargeData("Info item " + i));
>         });
>
>         Button reduceBtn = new Button("Reduce to 2");
>         reduceBtn.setOnAction(e -> {
>             System.out.println("Reducing master data size to 2");
>             masterData.setAll(new PotentialLargeData("New info 1"), new
> PotentialLargeData("New info 2"));
>         });
>
>         Button printBtn = new Button("Print interal sizes");
>         printBtn.setOnAction(e -> {
>             try {
>                 System.out.println("Items the user sees: " +
> sortedData.size());
>                 int[] filtered = (int[]) getFieldValue(filteredData,
> "filtered");
>                 System.out.println("FilteredList.filtered length: " +
> filtered.length);
>                 // This is a hidden and significant waste of memory
>                 Object[] sorted = (Object[]) getFieldValue(sortedData,
> "sorted");
>                 System.out.println("SortedList.sorted length: " +
> sorted.length);
>             } catch (Exception ex) {
>                 throw new RuntimeException(ex);
>             }
>         });
>
>         primaryStage.setScene(new Scene(new VBox(table, loadManyBtn,
> reduceBtn, printBtn), 600, 400));
>         primaryStage.show();
>     }
>
>     private static Object getFieldValue(Object object, String fieldName)
> throws Exception {
>         Field field = object.getClass().getDeclaredField(fieldName);
>         field.setAccessible(true);
>         return field.get(object);
>     }
> }
>
>
> Kind Regards,
> Cormac
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/c5335cf3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251204/c5335cf3/sorted_list_mem-0001.gif>

From tsayao at openjdk.org  Thu Dec  4 20:49:41 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 4 Dec 2025 20:49:41 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: <iwmsPHVjzXWB-bAxJmHn-91NT_mTG_bTuo9-wdmoXDs=.f86ac5cc-4c7a-4d49-ba12-bcb8b700b570@github.com>
References: <O6h0vab-ONVxD-3eOinC6if5xX_Ae9Aa2xFErxWsmgU=.c0f9330b-77aa-48c8-b083-700ba6124251@github.com>
 <iwmsPHVjzXWB-bAxJmHn-91NT_mTG_bTuo9-wdmoXDs=.f86ac5cc-4c7a-4d49-ba12-bcb8b700b570@github.com>
Message-ID: <eD0HLgW6S8ut_18CspBoJRbqPLAl-PNlnPUPWJc6MPY=.56771388-d804-4c0e-9f2b-3e6e5f22d1ef@github.com>

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
>> 
>> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
>> 
>> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
>> 
>> It also selects the correct visual for transparency which needs to be depth = 32 for X11.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

Closing in favor of #1981. I will send the improvement on the visual selection on another PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3614261562

From tsayao at openjdk.org  Thu Dec  4 20:49:42 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 4 Dec 2025 20:49:42 GMT
Subject: Withdrawn: 8210547: [Linux] Uncontrolled framerate
In-Reply-To: <O6h0vab-ONVxD-3eOinC6if5xX_Ae9Aa2xFErxWsmgU=.c0f9330b-77aa-48c8-b083-700ba6124251@github.com>
References: <O6h0vab-ONVxD-3eOinC6if5xX_Ae9Aa2xFErxWsmgU=.c0f9330b-77aa-48c8-b083-700ba6124251@github.com>
Message-ID: <rajTQiGUCut3KbSNnHrQwMkApNV0s_iNPLD8cHBdWwM=.755ba5c4-394e-48a8-b4ba-c6ec19ec0e0a@github.com>

On Sat, 4 Oct 2025 13:38:47 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
> 
> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
> 
> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
> 
> It also selects the correct visual for transparency which needs to be depth = 32 for X11.

This pull request has been closed without being integrated.

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

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

From angorya at openjdk.org  Thu Dec  4 20:59:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Dec 2025 20:59:18 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v6]
In-Reply-To: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
Message-ID: <zspEs0wEu--S0xKW0ZL7m6mzO_E6sSO3gpEb7Ea8g5Q=.ac54fa7f-e22b-4dfc-a95b-f23fb8b82228@github.com>

> Addressing the user feedback:
> 
> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
> 
> 
> Adding two methods to the `RichParagraph` class:
> 
> - getSegmentCount()
> - getSegment(int index)
> 
> Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  npe

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1966/files
  - new: https://git.openjdk.org/jfx/pull/1966/files/b4691640..64f7836d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=04-05

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1966.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1966/head:pull/1966

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

From tsayao at openjdk.org  Thu Dec  4 21:00:47 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 4 Dec 2025 21:00:47 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v71]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <KN56cD9N7P_GkJUYKWWA8TsdQSVtIumJ40rInilxEME=.77d477df-1fe8-42aa-a892-f5a51366b82e@github.com>

> 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 85 commits:

 - 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
 - Revert "8367898: Skip StageFocusTest on Linux"
   
   This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
 - Merge branch 'master' into 8354943
 - Remove unused imports
 - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=70
  Stats: 4113 lines in 28 files changed: 2708 ins; 776 del; 629 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From kcr at openjdk.org  Thu Dec  4 21:30:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Dec 2025 21:30:39 GMT
Subject: RFR: 8372203: Piecewise linear easing function [v9]
In-Reply-To: <QwQJ8Ctc3RSVbAeRRaDyMm-MBYjYSlJMC22I_F-cL_M=.4ba69235-b7e0-40f9-abc5-085df8cbcd6d@github.com>
References: <w1BA5TKZERJD_3f7f9pLxq_JzT4YuTybzLb9cpNHqn0=.f7103c02-e8c6-4826-8b3c-64c206b0c811@github.com>
 <QwQJ8Ctc3RSVbAeRRaDyMm-MBYjYSlJMC22I_F-cL_M=.4ba69235-b7e0-40f9-abc5-085df8cbcd6d@github.com>
Message-ID: <vPfHVwFfoWV97Id-edsfLgrIdw3KnTFoQJKGEh-W6zU=.e30aab09-1741-4e68-9561-6ff9c987b704@github.com>

On Thu, 27 Nov 2025 12:46:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
>> 
>> It allows developers to approximate arbitrary easing functions with linear segments:
>> 
>> 
>> linear(
>>     /* Start to 1st bounce */
>>     0, 0.063, 0.25, 0.563, 1 36.4%,
>>     /* 1st to 2nd bounce */
>>     0.812, 0.75, 0.813, 1 72.7%,
>>     /* 2nd to 3rd bounce */
>>     0.953, 0.938, 0.953, 1 90.9%,
>>     /* 3rd bounce to end */
>>     0.984, 1 100% 100%
>>   )
>> 
>> 
>> <img src="https://github.com/user-attachments/assets/73aac0d4-0185-47c5-8791-bdb247eb69c8" width="400"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

The code looks good and behaves as expected. Nice work!

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1977#pullrequestreview-3542169372

From mstrauss at openjdk.org  Thu Dec  4 21:49:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 4 Dec 2025 21:49:22 GMT
Subject: Integrated: 8372203: Piecewise linear easing function
In-Reply-To: <w1BA5TKZERJD_3f7f9pLxq_JzT4YuTybzLb9cpNHqn0=.f7103c02-e8c6-4826-8b3c-64c206b0c811@github.com>
References: <w1BA5TKZERJD_3f7f9pLxq_JzT4YuTybzLb9cpNHqn0=.f7103c02-e8c6-4826-8b3c-64c206b0c811@github.com>
Message-ID: <_Fpyck5hsD3UDMNxlh9-JdJomVdAhWyCMmNhiq4wtUw=.dcd90582-9e58-477f-bc95-425325b1325f@github.com>

On Wed, 19 Nov 2025 21:36:36 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of the [linear](https://www.w3.org/TR/css-easing-2/#the-linear-easing-function) easing function, which is now widely supported by all browsers, but still missing in JavaFX.
> 
> It allows developers to approximate arbitrary easing functions with linear segments:
> 
> 
> linear(
>     /* Start to 1st bounce */
>     0, 0.063, 0.25, 0.563, 1 36.4%,
>     /* 1st to 2nd bounce */
>     0.812, 0.75, 0.813, 1 72.7%,
>     /* 2nd to 3rd bounce */
>     0.953, 0.938, 0.953, 1 90.9%,
>     /* 3rd bounce to end */
>     0.984, 1 100% 100%
>   )
> 
> 
> <img src="https://github.com/user-attachments/assets/73aac0d4-0185-47c5-8791-bdb247eb69c8" width="400"/>

This pull request has now been integrated.

Changeset: 05d6f544
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/05d6f544344b3520516cedf99bd4a13f96332002
Stats:     862 lines in 13 files changed: 844 ins; 2 del; 16 mod

8372203: Piecewise linear easing function

Reviewed-by: angorya, kcr

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

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

From mstrauss at openjdk.org  Thu Dec  4 21:57:32 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 4 Dec 2025 21:57:32 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention [v2]
In-Reply-To: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
Message-ID: <pdPi-yE-81iVhdamvsnrjsD97ap-evUhrU5m4Td5ghQ=.2a26319d-cb1b-4bbf-9685-2974136e1abb@github.com>

> The following interpolator factories don't follow the standard method naming convention:
> 
> * `Interpolator.SPLINE(double, double, double, double)`
> * `Interpolator.TANGENT(Duration, double, Duration, double)`
> * `Interpolator.TANGENT(Duration, double)`
> * `Interpolator.STEPS(int, StepPosition)`
> 
> New methods named `ofSpline`, `ofTangent`, and `ofSteps` are added. The existing methods are deprecated (not for removal) in favor of the correctly-named methods. This change is in line with the new `ofLinear` method added with #1977.

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 three additional commits since the last revision:

 - doc changes
 - Merge branch 'master' into fixes/interpolator-names
 - Interpolator factories should follow method naming convention

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1996/files
  - new: https://git.openjdk.org/jfx/pull/1996/files/1fb91b9a..2128f2a9

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

  Stats: 999 lines in 23 files changed: 972 ins; 2 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1996.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1996/head:pull/1996

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

From kcr at openjdk.org  Thu Dec  4 21:57:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Dec 2025 21:57:36 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention [v2]
In-Reply-To: <FGaMgpjoFfBTLX-2hebrGlBCNu4jJzF4sN2OhTNXjfw=.0aeb0c77-77d2-4698-abaf-82d972d4100f@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
 <FGaMgpjoFfBTLX-2hebrGlBCNu4jJzF4sN2OhTNXjfw=.0aeb0c77-77d2-4698-abaf-82d972d4100f@github.com>
Message-ID: <2irzTsOqvNax5qvA6Cp7ztjsC11nImPipjNUB6a0ALI=.ea4ab8aa-c587-4917-9aa7-dc5ec83c79b6@github.com>

On Thu, 4 Dec 2025 00:10:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - doc changes
>>  - Merge branch 'master' into fixes/interpolator-names
>>  - Interpolator factories should follow method naming convention
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 97:
> 
>> 95:     private static final double SWIPE_THRESHOLD = 0.30;
>> 96:     private static final double TOUCH_THRESHOLD = 15;
>> 97:     private static final Interpolator interpolator = Interpolator.ofSpline(0.4829, 0.5709, 0.6803, 0.9928);
> 
> Off-topic: shouldn't this interpolator be specified by the stylesheet (i.e. to be able to modify the transition if needed)?
> 
> More of a question for @kevinrushforth

You mean should it be styleable in pagination? Probably, but I haven't heard anyone request it. It could be an RFE for "some day".

> maybe something like "This poorly named method is deprecated in favor of ..." or words to that extent?

We wouldn't do this in the description, but possibly in the `@deprecated` tag text (not sure).

> or keep the original description?

That's what we typically do, although I can see the value in what @mstr2 proposed. I'll take a look at the built docs and see how it looks.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1996#discussion_r2590640178
PR Review Comment: https://git.openjdk.org/jfx/pull/1996#discussion_r2590668378

From mstrauss at openjdk.org  Thu Dec  4 21:57:37 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 4 Dec 2025 21:57:37 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention [v2]
In-Reply-To: <2irzTsOqvNax5qvA6Cp7ztjsC11nImPipjNUB6a0ALI=.ea4ab8aa-c587-4917-9aa7-dc5ec83c79b6@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
 <FGaMgpjoFfBTLX-2hebrGlBCNu4jJzF4sN2OhTNXjfw=.0aeb0c77-77d2-4698-abaf-82d972d4100f@github.com>
 <2irzTsOqvNax5qvA6Cp7ztjsC11nImPipjNUB6a0ALI=.ea4ab8aa-c587-4917-9aa7-dc5ec83c79b6@github.com>
Message-ID: <-OuOUFDyi4ycOV1fCaJvcDplc0vqsHnnh_eiVqHZrcc=.86eb029f-cece-4948-8549-4f34e5363807@github.com>

On Thu, 4 Dec 2025 21:40:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 192:
>> 
>>> 190: 
>>> 191:     /**
>>> 192:      * Use {@link #ofSpline(double, double, double, double)}.
>> 
>> maybe something like "This poorly named method is deprecated in favor of ..." or words to that extent?
>> 
>> or keep the original description?
>
>> maybe something like "This poorly named method is deprecated in favor of ..." or words to that extent?
> 
> We wouldn't do this in the description, but possibly in the `@deprecated` tag text (not sure).
> 
>> or keep the original description?
> 
> That's what we typically do, although I can see the value in what @mstr2 proposed. I'll take a look at the built docs and see how it looks.

I've commited the suggested change without noticing your reply here. The description is now similar to:

     * This is a legacy method named inconsistently with method naming conventions,
     * use {@link #ofSpline(double, double, double, double)} instead.

I can revert the change, or keep the existing description.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1996#discussion_r2590705707

From kcr at openjdk.org  Thu Dec  4 21:57:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Dec 2025 21:57:32 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention [v2]
In-Reply-To: <pdPi-yE-81iVhdamvsnrjsD97ap-evUhrU5m4Td5ghQ=.2a26319d-cb1b-4bbf-9685-2974136e1abb@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
 <pdPi-yE-81iVhdamvsnrjsD97ap-evUhrU5m4Td5ghQ=.2a26319d-cb1b-4bbf-9685-2974136e1abb@github.com>
Message-ID: <NA2OaQrEBvSoxzAoJ4K6bLRdNydYbb5i7FD4OMZGqpU=.477cc7c0-a4a0-49ef-a531-81218e4a921c@github.com>

On Thu, 4 Dec 2025 21:54:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The following interpolator factories don't follow the standard method naming convention:
>> 
>> * `Interpolator.SPLINE(double, double, double, double)`
>> * `Interpolator.TANGENT(Duration, double, Duration, double)`
>> * `Interpolator.TANGENT(Duration, double)`
>> * `Interpolator.STEPS(int, StepPosition)`
>> 
>> New methods named `ofSpline`, `ofTangent`, and `ofSteps` are added. The existing methods are deprecated (not for removal) in favor of the correctly-named methods. This change is in line with the new `ofLinear` method added with #1977.
>
> 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 three additional commits since the last revision:
> 
>  - doc changes
>  - Merge branch 'master' into fixes/interpolator-names
>  - Interpolator factories should follow method naming convention

This looks like a reasonable thing to do. I'll take a closer look at the docs before approving.

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

PR Review: https://git.openjdk.org/jfx/pull/1996#pullrequestreview-3542174057

From kcr at openjdk.org  Thu Dec  4 22:16:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Dec 2025 22:16:27 GMT
Subject: RFR: 8373038: Interpolator factories should follow method naming
 convention [v2]
In-Reply-To: <-OuOUFDyi4ycOV1fCaJvcDplc0vqsHnnh_eiVqHZrcc=.86eb029f-cece-4948-8549-4f34e5363807@github.com>
References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com>
 <FGaMgpjoFfBTLX-2hebrGlBCNu4jJzF4sN2OhTNXjfw=.0aeb0c77-77d2-4698-abaf-82d972d4100f@github.com>
 <2irzTsOqvNax5qvA6Cp7ztjsC11nImPipjNUB6a0ALI=.ea4ab8aa-c587-4917-9aa7-dc5ec83c79b6@github.com>
 <-OuOUFDyi4ycOV1fCaJvcDplc0vqsHnnh_eiVqHZrcc=.86eb029f-cece-4948-8549-4f34e5363807@github.com>
Message-ID: <bqjNEp7fWDPt2VHyaAKC7hwkKg0Mv2YX3waUS6xYUnI=.9a2e0276-e286-4e3e-8754-38643813df18@github.com>

On Thu, 4 Dec 2025 21:54:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>> maybe something like "This poorly named method is deprecated in favor of ..." or words to that extent?
>> 
>> We wouldn't do this in the description, but possibly in the `@deprecated` tag text (not sure).
>> 
>>> or keep the original description?
>> 
>> That's what we typically do, although I can see the value in what @mstr2 proposed. I'll take a look at the built docs and see how it looks.
>
> I've commited the suggested change without noticing your reply here. The description is now similar to:
> 
>      * This is a legacy method named inconsistently with method naming conventions,
>      * use {@link #ofSpline(double, double, double, double)} instead.
> 
> I can revert the change, or keep the existing description.

I'll take a closer look soon.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1996#discussion_r2590760291

From john.hendrikx at gmail.com  Fri Dec  5 04:20:37 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 5 Dec 2025 05:20:37 +0100
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <CAG_-AaD6XJh0Esih2OTjeP+MS7+UXMFBMUeF_vWViPcwj=A40w@mail.gmail.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
 <CAG_-AaD6XJh0Esih2OTjeP+MS7+UXMFBMUeF_vWViPcwj=A40w@mail.gmail.com>
Message-ID: <404afbf5-9db6-4b91-ad17-465d049cace3@gmail.com>


On 04/12/2025 21:21, Cormac Redmond wrote:
> Hi John,
>
> Thanks for the prompt response. Yes, I looked into the code
> afterwards, and I can see that it is just fairly oblivious to the
> waste. I was looking to override with nulls myself, but there were too
> many privates.
>
> The only?solution (without re-writing my own impl) is to re-create?the
> SortedList every time the dataset is smaller, or to create some sort
> of DTO that does not link to the original real objects in any way (or
> maybe use WeakReferences). In my case, I could have 10,000 rows where
> each item's underlying memory is around 500KB on the heap. That's
> instantly 5GB I cannot re-claim, or example.
>
> That code with the "bug"?/mostly/?hasn't changed in 10+ years. Can it
> be fixed? It's such a fundamental class, adding workarounds
> (everywhere, forever) would seem a shame.

It definitely can be fixed.? Nothing should be relying on the current
behavior, as it is not specified to hold on to stale references.

You could try submit a PR with a fix, or wait until this becomes a
priority.? I myself may also do a fix when I have time, as it is pretty
low hanging fruit and self contained.

You can "test" a fixed implementation by just making a copy of the
class. If you're not in a modular environment, you can even replace the
class (in the same package it is in) with a fixed version until FX fixes
it.? This is how I usually test and fix (deep) internal problems without
having to build FX locally at all.

--John


>
>
>
>
> Kind Regards,
> Cormac
>
> On Thu, 4 Dec 2025 at 20:01, John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>     This looks like a classic problem where unused elements in an
>     array are not nulled.? Looking at the code that updates the `size`
>     field, there are a few code paths that are not setting unused
>     elements to null.? I also saw no code that ever shrinks the
>     arrays.? So it looks this implementation is only half finished.
>
>     So, yes,?I'd say this is a bug.
>
>>     I'm going to guess there's a very good reason for this behaviour.
>     Time pressure and insufficient testing.
>
>     --John
>
>     On 04/12/2025 19:40, Cormac Redmond wrote:
>>     Hi,
>>
>>     I've traced a memory issue back to a SortedList (surprisingly),
>>     where it's hanging on to objects that could/should have been GC'd.
>>
>>     SortedList's internal arrays will only grow (but not shrink) in
>>     line with the source ObservableList (I'm sure there are reasons
>>     for this). So even when your source ObservableList shrinks,
>>     SortedList is hanging on to references to objects the source list
>>     once contained, even though they're completely removed from
>>     the?source list.
>>
>>     This leads to a substantial waste of memory, especially when just
>>     one momentarily?large dataset leads to a permanent spike in
>>     unnecessary memory usage for the remainder?for the application's
>>     lifetime. I'm sure I'm not the first to raise this or ask about
>>     it & I'm going to guess there's a very good reason for this
>>     behaviour. But could someone explain this? I would have thought
>>     SortedList should/could remain as lean as the source list.
>>     FilteredList is somewhat similar, except it stores an array of
>>     ints (indexes), so less of a memory hit, but still pointless
>>     nonetheless.
>>
>>     Example GIF + code below: setup a typical sortable table (so,
>>     ObservableList + FilteredList?+ SortableList), where the print
>>     button shows that when you add a lot of data, and remove it,
>>     SortedList retains references to all of the old objects. Some
>>     reflection is used to print that information.
>>
>>     sorted_list_mem.gif
>>
>>
>>     Code to reproduce:
>>
>>     public class SortedListMemWasteDemo extends Application {
>>
>>     ? ? record PotentialLargeData(String info) {}
>>
>>     ? ? public static void main(String[] args) {
>>     ? ? ? ? launch(args);
>>     ? ? }
>>
>>     ? ? @Override
>>     ? ? public void start(Stage primaryStage) {
>>     ? ? ? ? ObservableList<PotentialLargeData> masterData =
>>     FXCollections.observableArrayList(
>>     ? ? ? ? ? ? ? ? new PotentialLargeData("Initial info 1"),
>>     ? ? ? ? ? ? ? ? new PotentialLargeData("Initial info 2"));
>>
>>     ? ? ? ? TableColumn<PotentialLargeData, String> col = new
>>     TableColumn<>("Info");
>>     ? ? ? ? col.setCellValueFactory(cellData -> new
>>     SimpleStringProperty(cellData.getValue().info()));
>>     ? ? ? ?
>>     ? ? ? ? TableView<PotentialLargeData> table = new TableView<>();
>>     ? ? ? ? table.getColumns().add(col);
>>
>>     ? ? ? ? FilteredList<PotentialLargeData> filteredData = new
>>     FilteredList<>(masterData, item -> true);
>>     ? ? ? ? SortedList<PotentialLargeData> sortedData = new
>>     SortedList<>(filteredData);
>>     ? ? ? ?
>>     sortedData.comparatorProperty().bind(table.comparatorProperty());
>>     ? ? ? ? table.setItems(sortedData);
>>
>>     ? ? ? ? Button loadManyBtn = new Button("Add 10,000 items");
>>     ? ? ? ? loadManyBtn.setOnAction(e -> {
>>     ? ? ? ? ? ? System.out.println("Adding 10000 items to master data");
>>     ? ? ? ? ? ? masterData.clear();
>>     ? ? ? ? ? ? for (int i = 0; i < 10000; i++) masterData.add(new
>>     PotentialLargeData("Info item " + i));
>>     ? ? ? ? });
>>
>>     ? ? ? ? Button reduceBtn = new Button("Reduce to 2");
>>     ? ? ? ? reduceBtn.setOnAction(e -> {
>>     ? ? ? ? ? ? System.out.println("Reducing master data size to 2");
>>     ? ? ? ? ? ? masterData.setAll(new PotentialLargeData("New info
>>     1"), new PotentialLargeData("New info 2"));
>>     ? ? ? ? });
>>
>>     ? ? ? ? Button printBtn = new Button("Print interal sizes");
>>     ? ? ? ? printBtn.setOnAction(e -> {
>>     ? ? ? ? ? ? try {
>>     ? ? ? ? ? ? ? ? System.out.println("Items the user sees: " +
>>     sortedData.size());
>>     ? ? ? ? ? ? ? ? int[] filtered = (int[])
>>     getFieldValue(filteredData, "filtered");
>>     ? ? ? ? ? ? ? ? System.out.println("FilteredList.filtered length:
>>     " + filtered.length);
>>     ? ? ? ? ? ? ? ? // This is a hidden and significant waste of memory
>>     ? ? ? ? ? ? ? ? Object[] sorted = (Object[])
>>     getFieldValue(sortedData, "sorted");
>>     ? ? ? ? ? ? ? ? System.out.println("SortedList.sorted length: " +
>>     sorted.length);
>>     ? ? ? ? ? ? } catch (Exception ex) {
>>     ? ? ? ? ? ? ? ? throw new RuntimeException(ex);
>>     ? ? ? ? ? ? }
>>     ? ? ? ? });
>>
>>     ? ? ? ? primaryStage.setScene(new Scene(new VBox(table,
>>     loadManyBtn, reduceBtn, printBtn), 600, 400));
>>     ? ? ? ? primaryStage.show();
>>     ? ? }
>>
>>     ? ? private static Object getFieldValue(Object object, String
>>     fieldName) throws Exception {
>>     ? ? ? ? Field field = object.getClass().getDeclaredField(fieldName);
>>     ? ? ? ? field.setAccessible(true);
>>     ? ? ? ? return field.get(object);
>>     ? ? }
>>     }
>>
>>
>>     Kind Regards,
>>     Cormac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251205/666cbc4e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251205/666cbc4e/sorted_list_mem-0001.gif>

From arapte at openjdk.org  Fri Dec  5 06:56:12 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 5 Dec 2025 06:56:12 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
 <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
Message-ID: <5l8qR_tlH-1hmnjAnkNZQumoMBBMtWM_I6fBFf7yE7o=.0d80e955-3ed7-4805-8571-426e2c16b59d@github.com>

On Mon, 1 Dec 2025 22:08:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
>> 
>> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
>> 
>> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
>> 
>> 
>> public class ZeroSizeSubScene extends Application {
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var rect = new Rectangle(50, 50, Color.RED);
>>         var subScene = new SubScene(new Group(rect), 100, 100);
>>         subScene.setFill(Color.GRAY);
>> 
>>         // Also try a perspective camera:
>>         //
>>         // var camera = new PerspectiveCamera();
>>         // camera.setRotate(45);
>>         // camera.setTranslateX(-20);
>>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>>         // subScene.setCamera(camera);
>> 
>>         class MyButton extends Button {
>>             public MyButton(String text, double width, double height) {
>>                 super(text);
>>                 setOnAction(_ -> {
>>                     var timeline = new Timeline(
>>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
>> 
>>                     timeline.setOnFinished(_ -> {
>>                         Point2D p0 = rect.localToScreen(0, 0);
>>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>>                     });
>> 
>>                     timeline.play();
>>                 });
>>             }
>>         }
>> 
>>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
>> 
>>         var root = new VBox(5,
>>             subScene,
>>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>>             new MyButton("Size: 100x100", 100, 100),
>>             new MyButton("Size: 10x10", 10, 10),
>>             new MyButton("Size: 100x0", 100, 0),
>>             ne...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Doc of [localToScreen()](https://openjfx.io/javadoc/24/javafx.graphics/javafx/scene/Node.html#localToScreen(double,double)): Transforms a point from the local coordinate space of this Node into the coordinate space of its Screen
When the sub scene is of size (0, 0), then the sub scene and so it's children will not be shown on screen.
Printing a valid screen coordinates with localToScreen() for nodes that are not shown on screen, seems not correct.
Rather, NaN would imply that something is not correct / the node is not shown on screen.

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

PR Comment: https://git.openjdk.org/jfx/pull/1992#issuecomment-3615542508

From lkostyra at openjdk.org  Fri Dec  5 07:48:23 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 5 Dec 2025 07:48:23 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v71]
In-Reply-To: <KN56cD9N7P_GkJUYKWWA8TsdQSVtIumJ40rInilxEME=.77d477df-1fe8-42aa-a892-f5a51366b82e@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <KN56cD9N7P_GkJUYKWWA8TsdQSVtIumJ40rInilxEME=.77d477df-1fe8-42aa-a892-f5a51366b82e@github.com>
Message-ID: <ceZ3AtYxFbpRWwRkFm271jagnAcVl_h2Ew0cXYbIGyY=.fc41f3fa-4df4-42f2-b55d-9b194e89f7e6@github.com>

On Thu, 4 Dec 2025 21:00:47 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 85 commits:
> 
>  - 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
>  - Revert "8367898: Skip StageFocusTest on Linux"
>    
>    This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
>  - Merge branch 'master' into 8354943
>  - Remove unused imports
>  - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205

Marked as reviewed by lkostyra (Reviewer).

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

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

From lkostyra at openjdk.org  Fri Dec  5 08:07:13 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 5 Dec 2025 08:07:13 GMT
Subject: RFR: 8373098: RichTextArea: NPE in InputMethodRequests
In-Reply-To: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
References: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
Message-ID: <GL3gSF-D70biqL_fmqBi2WIgiX3jY4yr0zIMy6gRiF4=.76e0ee4d-97bd-4d0a-959d-03913ce948c3@github.com>

On Thu, 4 Dec 2025 17:12:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixes an NPE discovered while working on https://github.com/openjdk/jfx/pull/1975
> 
> To reproduce, run RichTextAreaDemoApp with a "2,000,000,000 Lines" model and try scrolling with the mouse wheel rapidly up and down.

LGTM. I couldn't reproduce the original issue, but since it's a trivial NPE and this change addresses what the stacktrace in the issue said I think it's okay. And it certainly shows no NPEs after the patch =)

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1997#pullrequestreview-3543532379

From mhanl at openjdk.org  Fri Dec  5 10:45:13 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 5 Dec 2025 10:45:13 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>
References: <wf49A9Cv05TOHVrHB13numUo2qfwyrg-UnvUbc1JS6M=.26a864df-3429-43fb-85e9-a9e0b52eb7bc@github.com>
 <Vg6y2XoT0s-zXM6hI3Lcas6VXGhCouWGHHb9DACRSLQ=.a36939a5-8fe7-4309-933e-959336a92e57@github.com>
 <C-fprMy8fhJH4o7kSvcD9w4-E1547ARZcofiKykNzzo=.5d8f67ed-4624-4f37-a17a-d55baddb1232@github.com>
 <CC-SPDELW9jsPu3evQb0V5gZT5czmB5eB_MyQ_zE3d4=.6936067a-2342-4153-ba78-5c6b2f7a4df3@github.com>
 <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
 <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>
Message-ID: <g3fKq_bF0Q89jVGSMz0pcbS4OQqgKbgLYxqf2akiKIM=.4949e12c-0137-472a-b071-915c657ced61@github.com>

On Mon, 1 Dec 2025 14:39:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Either is fine, but having the `all` task depend on it seems a better choice (the fact that the `sdk` task currently depends on it seems somewhat arbitrary).

I had a look and gave it a shot. 

If we depend on the `all` task, we will now also build all `apps`, which I think is not a good thing. Since this is unexpected if we just want to (build and) publish the Maven Libraries. In my opinion, the `sdk` task makes more sense (or a task that will do everything except the apps).

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3616305204

From kcr at openjdk.org  Fri Dec  5 13:47:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Dec 2025 13:47:16 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: <g3fKq_bF0Q89jVGSMz0pcbS4OQqgKbgLYxqf2akiKIM=.4949e12c-0137-472a-b071-915c657ced61@github.com>
References: <wf49A9Cv05TOHVrHB13numUo2qfwyrg-UnvUbc1JS6M=.26a864df-3429-43fb-85e9-a9e0b52eb7bc@github.com>
 <Vg6y2XoT0s-zXM6hI3Lcas6VXGhCouWGHHb9DACRSLQ=.a36939a5-8fe7-4309-933e-959336a92e57@github.com>
 <C-fprMy8fhJH4o7kSvcD9w4-E1547ARZcofiKykNzzo=.5d8f67ed-4624-4f37-a17a-d55baddb1232@github.com>
 <CC-SPDELW9jsPu3evQb0V5gZT5czmB5eB_MyQ_zE3d4=.6936067a-2342-4153-ba78-5c6b2f7a4df3@github.com>
 <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
 <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>
 <g3fKq_bF0Q89jVGSMz0pcbS4OQqgKbgLYxqf2akiKIM=.4949e12c-0137-472a-b071-915c657ced61@github.com>
Message-ID: <_IE0eaP3WCTKNcNlP9gC3yJN5OGi0lMmDKOmFD1u_OU=.316308c4-21f6-4c09-9447-b78d416d5ca3@github.com>

On Fri, 5 Dec 2025 10:42:13 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > Either is fine, but having the `all` task depend on it seems a better choice (the fact that the `sdk` task currently depends on it seems somewhat arbitrary).
> 
> I had a look and gave it a shot.
> 
> If we depend on the `all` task, we will now also build all `apps`, which I think is not a good thing. Since this is unexpected if we just want to (build and) publish the Maven Libraries. In my opinion, the `sdk` task makes more sense (or a task that will do everything except the apps).

I think you might have it backwards: `all` should depend on the task to build the publications, not the other way around. The goal is that `gradle all` should produce `build/publications`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3616987499

From lkostyra at openjdk.org  Fri Dec  5 13:47:40 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 5 Dec 2025 13:47:40 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash
Message-ID: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>

This commit fixes the JVM crash caused by bad Clipboard data on Linux.

On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.

Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.

Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.

As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

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

Commit messages:
 - Check if underlying jobject types are what we expect

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

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

From kcr at openjdk.org  Fri Dec  5 13:51:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Dec 2025 13:51:41 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash
In-Reply-To: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
Message-ID: <FBTXfTz1SziFAOlRFO7ZJu73wsMsJqLc7GqZxBk_XaY=.5116c9c1-47f7-4a98-8f05-589204e61245@github.com>

On Fri, 5 Dec 2025 13:43:45 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
> 
> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
> 
> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
> 
> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
> 
> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

Can you turn the test case from the bug report into an automated test?

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

PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3617000776

From lkostyra at openjdk.org  Fri Dec  5 13:57:45 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 5 Dec 2025 13:57:45 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash
In-Reply-To: <FBTXfTz1SziFAOlRFO7ZJu73wsMsJqLc7GqZxBk_XaY=.5116c9c1-47f7-4a98-8f05-589204e61245@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
 <FBTXfTz1SziFAOlRFO7ZJu73wsMsJqLc7GqZxBk_XaY=.5116c9c1-47f7-4a98-8f05-589204e61245@github.com>
Message-ID: <Y8v7sIOglpSMeRNT2luz9NM_M7mHU400y7k4-Z_picI=.d274dbca-9757-4bef-a319-3368a021df67@github.com>

On Fri, 5 Dec 2025 13:48:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Can you turn the test case from the bug report into an automated test?

I was not sure about this, mostly because of difference in behavior between platforms. For now I could add a test that simply sets `ClipboardContent` and then tries to put it on the Clipboard, but because each platform behaves differently I can't double-check if Clipboard was correctly (not) updated - Windows will return a valid object, while Linux will return null.

I can also write a proper test, make it work only on Linux assuming this is the behavior we want to follow and exclude it on other platforms, that way [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090) will have it mostly ready to go.

Which option do you prefer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3617026020

From mstrauss at openjdk.org  Fri Dec  5 14:19:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 5 Dec 2025 14:19:59 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <5l8qR_tlH-1hmnjAnkNZQumoMBBMtWM_I6fBFf7yE7o=.0d80e955-3ed7-4805-8571-426e2c16b59d@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
 <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
 <5l8qR_tlH-1hmnjAnkNZQumoMBBMtWM_I6fBFf7yE7o=.0d80e955-3ed7-4805-8571-426e2c16b59d@github.com>
Message-ID: <yFsglntORrsY6isS35RG-e2xCyFyi6yv-tcHV8uOLSo=.d136e52b-eb45-41e9-916c-dee4ec31304a@github.com>

On Fri, 5 Dec 2025 06:53:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Doc of [localToScreen()](https://openjfx.io/javadoc/24/javafx.graphics/javafx/scene/Node.html#localToScreen(double,double)): Transforms a point from the local coordinate space of this Node into the coordinate space of its Screen When the sub scene is of size (0, 0), then the sub scene and so it's children will not be shown on screen. Printing a valid screen coordinates with localToScreen() for nodes that are not shown on screen, seems not correct. Rather, NaN would imply that something is not correct / the node is not shown on screen.

`localToScreen` is not specified to account for something being "shown" on screen. Instead, it answers the question: given a point in the local coordinate system of a node, which point on the screen does it correspond to?

And _this_ question has a valid answer: In the limit, the screen coordinates of a point specified in a 0-size scene or a vanishingly small scene are the same. In fact, the only reason this API can't answer this question is not because of some deep lack of meaning for the 0-size case, but simply because the size of the scene appears as a denominator in the projection transform.

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

PR Comment: https://git.openjdk.org/jfx/pull/1992#issuecomment-3617104296

From mhanl at openjdk.org  Fri Dec  5 15:05:04 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 5 Dec 2025 15:05:04 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: <_IE0eaP3WCTKNcNlP9gC3yJN5OGi0lMmDKOmFD1u_OU=.316308c4-21f6-4c09-9447-b78d416d5ca3@github.com>
References: <wf49A9Cv05TOHVrHB13numUo2qfwyrg-UnvUbc1JS6M=.26a864df-3429-43fb-85e9-a9e0b52eb7bc@github.com>
 <Vg6y2XoT0s-zXM6hI3Lcas6VXGhCouWGHHb9DACRSLQ=.a36939a5-8fe7-4309-933e-959336a92e57@github.com>
 <C-fprMy8fhJH4o7kSvcD9w4-E1547ARZcofiKykNzzo=.5d8f67ed-4624-4f37-a17a-d55baddb1232@github.com>
 <CC-SPDELW9jsPu3evQb0V5gZT5czmB5eB_MyQ_zE3d4=.6936067a-2342-4153-ba78-5c6b2f7a4df3@github.com>
 <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
 <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>
 <g3fKq_bF0Q89jVGSMz0pcbS4OQqgKbgLYxqf2akiKIM=.4949e12c-0137-472a-b071-915c657ced61@github.com>
 <_IE0eaP3WCTKNcNlP9gC3yJN5OGi0lMmDKOmFD1u_OU=.316308c4-21f6-4c09-9447-b78d416d5ca3@github.com>
Message-ID: <ie6qFlfd2Cb1P1Jo05owCHOOSFgUICSm8-27QRg42c4=.c5246e37-662d-4559-9ee2-ea685617ef45@github.com>

On Fri, 5 Dec 2025 13:44:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I think you might have it backwards: `all` should depend on the task to build the publications, not the other way around. The goal is that `gradle all` should produce `build/publications`.

Ah okay, I got you now! I will have a look how this can be achieved.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3617278676

From angorya at openjdk.org  Fri Dec  5 17:07:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 5 Dec 2025 17:07:27 GMT
Subject: RFR: 8373098: RichTextArea: NPE in InputMethodRequests
In-Reply-To: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
References: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
Message-ID: <c7aYktLQdfldwnf-gXwwGb3AqnV_tTBAGPsK4IIV80o=.52e33c7c-4b62-4fc0-ba9c-34d83a7c350a@github.com>

On Thu, 4 Dec 2025 17:12:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixes an NPE discovered while working on https://github.com/openjdk/jfx/pull/1975
> 
> To reproduce, run RichTextAreaDemoApp with a "2,000,000,000 Lines" model and try scrolling with the mouse wheel rapidly up and down.

thank you!

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

PR Comment: https://git.openjdk.org/jfx/pull/1997#issuecomment-3617733448

From angorya at openjdk.org  Fri Dec  5 17:07:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 5 Dec 2025 17:07:27 GMT
Subject: Integrated: 8373098: RichTextArea: NPE in InputMethodRequests
In-Reply-To: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
References: <H9bWDwg2L0QiMPUihD_65jjEOUV2_1-S4f6OBp_jCCQ=.5c38d90d-1a6d-4917-9b4a-d9bda3a76554@github.com>
Message-ID: <4ZMYfYSGaYhTBC4gU-m9iEVb3_eZ-u60cZZd11Hms1s=.39aff93a-437f-4634-a322-273749e8fcb8@github.com>

On Thu, 4 Dec 2025 17:12:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixes an NPE discovered while working on https://github.com/openjdk/jfx/pull/1975
> 
> To reproduce, run RichTextAreaDemoApp with a "2,000,000,000 Lines" model and try scrolling with the mouse wheel rapidly up and down.

This pull request has now been integrated.

Changeset: e28c5d2e
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e28c5d2ee92e7eaead50828b2990c7f04597d322
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8373098: RichTextArea: NPE in InputMethodRequests

Reviewed-by: lkostyra

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

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

From angorya at openjdk.org  Fri Dec  5 17:09:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 5 Dec 2025 17:09:34 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v7]
In-Reply-To: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
Message-ID: <YF-9J6a1Lj_bJaIhjyaBlcFs66woFdpInSU4XoE2sQw=.66787b08-2154-47f7-84cc-80a99e4bda8b@github.com>

> Addressing the user feedback:
> 
> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
> 
> 
> Adding two methods to the `RichParagraph` class:
> 
> - getSegmentCount()
> - getSegment(int index)
> 
> Decided against exposing a List since it would require additional allocation.  Some of the callers seems to implement special logic when the number of segments is 0 anyway.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into 8371070.enhance
 - npe
 - merge
 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - test
 - expose segments

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

Changes: https://git.openjdk.org/jfx/pull/1966/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=06
  Stats: 215 lines in 7 files changed: 141 ins; 43 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1966.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1966/head:pull/1966

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

From angorya at openjdk.org  Fri Dec  5 17:21:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 5 Dec 2025 17:21:13 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash
In-Reply-To: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
Message-ID: <QybkqggSaEdEQ-_9VicAmJ2M5Gecu3OjCfhpPkJrnX8=.5c1f492b-3648-4be5-91bd-c5b34b975e32@github.com>

On Fri, 5 Dec 2025 13:43:45 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
> 
> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
> 
> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
> 
> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
> 
> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

Questions:
1. do we have the same issue with other text types (e.g. "text/css" or "text/javascript")?
2. should we have an automated test developed which places mismatched data to the clipboard (it might need to be headful to operate with the real clipboard)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3617792451

From crschnick at xpipe.io  Sat Dec  6 09:40:16 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sat, 6 Dec 2025 10:40:16 +0100
Subject: macOS 26 title bar artifacts
In-Reply-To: <70d4e007-6501-4c18-a838-0a7d881fd7b1@xpipe.io>
References: <70d4e007-6501-4c18-a838-0a7d881fd7b1@xpipe.io>
Message-ID: <85f141ff-821a-4957-8818-66d42bfad164@xpipe.io>

Bump, since this mail was stuck in the moderation queue for two weeks 
and probably?nobody saw it.

On 19/11/2025 11:53 PM, Christopher Schnick wrote:
> Hello,
>
> I discovered an weird graphical glitch around the title bar buttons on 
> macOS 26.0.1 and the latest JavaFX (but it's also there in older 
> JavaFX versions).
>
> I have no idea what causes this, there aren't any customizations 
> configured for the Stage that I can think of. I haven't seen this 
> happen in any other app so far.
>
> It happens at least in my project's releases from 
> https://github.com/xpipe-io/kickstartfx/releases/latest
>
> Best
> Christopher Schnick
>

From credmond at certak.com  Sun Dec  7 02:28:42 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sun, 7 Dec 2025 02:28:42 +0000
Subject: SortedList hanging on to references & preventing GC
In-Reply-To: <404afbf5-9db6-4b91-ad17-465d049cace3@gmail.com>
References: <CAG_-AaDynME6krZL_Lq7eYuKc5dtWPF+Fo4ttVMYXi3gPBwUHg@mail.gmail.com>
 <cb50bdb7-9cfc-46fd-91df-820644bb3dc8@gmail.com>
 <CAG_-AaD6XJh0Esih2OTjeP+MS7+UXMFBMUeF_vWViPcwj=A40w@mail.gmail.com>
 <404afbf5-9db6-4b91-ad17-465d049cace3@gmail.com>
Message-ID: <CAG_-AaA3W8xJh9qsfuk=xc6yA1tzkbN8wsHaMNEe8dubBXe-8Q@mail.gmail.com>

Hi,

Thanks. I've opened a draft PR: https://github.com/openjdk/jfx/pull/2000 (first
time, be kind!)...

As requested per https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md,
the tests I added do fail without the fixes in place, around both the
"sorted" array and tempElement, and pass with them in place.

Aside from that, a lot of manual testing has not found any issues also.




Kind REgards,
Cormac

On Fri, 5 Dec 2025 at 04:20, John Hendrikx <john.hendrikx at gmail.com> wrote:

>
> On 04/12/2025 21:21, Cormac Redmond wrote:
>
> Hi John,
>
> Thanks for the prompt response. Yes, I looked into the code afterwards,
> and I can see that it is just fairly oblivious to the waste. I was looking
> to override with nulls myself, but there were too many privates.
>
> The only solution (without re-writing my own impl) is to re-create the
> SortedList every time the dataset is smaller, or to create some sort of DTO
> that does not link to the original real objects in any way (or maybe use
> WeakReferences). In my case, I could have 10,000 rows where each item's
> underlying memory is around 500KB on the heap. That's instantly 5GB I
> cannot re-claim, or example.
>
> That code with the "bug" *mostly* hasn't changed in 10+ years. Can it be
> fixed? It's such a fundamental class, adding workarounds (everywhere,
> forever) would seem a shame.
>
> It definitely can be fixed.  Nothing should be relying on the current
> behavior, as it is not specified to hold on to stale references.
>
> You could try submit a PR with a fix, or wait until this becomes a
> priority.  I myself may also do a fix when I have time, as it is pretty low
> hanging fruit and self contained.
>
> You can "test" a fixed implementation by just making a copy of the class.
> If you're not in a modular environment, you can even replace the class (in
> the same package it is in) with a fixed version until FX fixes it.  This is
> how I usually test and fix (deep) internal problems without having to build
> FX locally at all.
>
> --John
>
>
>
>
>
>
> Kind Regards,
> Cormac
>
> On Thu, 4 Dec 2025 at 20:01, John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> This looks like a classic problem where unused elements in an array are
>> not nulled.  Looking at the code that updates the `size` field, there are a
>> few code paths that are not setting unused elements to null.  I also saw no
>> code that ever shrinks the arrays.  So it looks this implementation is only
>> half finished.
>>
>> So, yes, I'd say this is a bug.
>>
>> I'm going to guess there's a very good reason for this behaviour.
>>
>> Time pressure and insufficient testing.
>>
>> --John
>> On 04/12/2025 19:40, Cormac Redmond wrote:
>>
>> Hi,
>>
>> I've traced a memory issue back to a SortedList (surprisingly), where
>> it's hanging on to objects that could/should have been GC'd.
>>
>> SortedList's internal arrays will only grow (but not shrink) in line with
>> the source ObservableList (I'm sure there are reasons for this). So even
>> when your source ObservableList shrinks, SortedList is hanging on to
>> references to objects the source list once contained, even though they're
>> completely removed from the source list.
>>
>> This leads to a substantial waste of memory, especially when just one
>> momentarily large dataset leads to a permanent spike in unnecessary memory
>> usage for the remainder for the application's lifetime. I'm sure I'm not
>> the first to raise this or ask about it & I'm going to guess there's a very
>> good reason for this behaviour. But could someone explain this? I would
>> have thought SortedList should/could remain as lean as the source list.
>> FilteredList is somewhat similar, except it stores an array of ints
>> (indexes), so less of a memory hit, but still pointless nonetheless.
>>
>> Example GIF + code below: setup a typical sortable table (so,
>> ObservableList + FilteredList + SortableList), where the print button shows
>> that when you add a lot of data, and remove it, SortedList retains
>> references to all of the old objects. Some reflection is used to print that
>> information.
>>
>> [image: sorted_list_mem.gif]
>>
>>
>> Code to reproduce:
>>
>> public class SortedListMemWasteDemo extends Application {
>>
>>     record PotentialLargeData(String info) {}
>>
>>     public static void main(String[] args) {
>>         launch(args);
>>     }
>>
>>     @Override
>>     public void start(Stage primaryStage) {
>>         ObservableList<PotentialLargeData> masterData =
>> FXCollections.observableArrayList(
>>                 new PotentialLargeData("Initial info 1"),
>>                 new PotentialLargeData("Initial info 2"));
>>
>>         TableColumn<PotentialLargeData, String> col = new
>> TableColumn<>("Info");
>>         col.setCellValueFactory(cellData -> new
>> SimpleStringProperty(cellData.getValue().info()));
>>
>>         TableView<PotentialLargeData> table = new TableView<>();
>>         table.getColumns().add(col);
>>
>>         FilteredList<PotentialLargeData> filteredData = new
>> FilteredList<>(masterData, item -> true);
>>         SortedList<PotentialLargeData> sortedData = new
>> SortedList<>(filteredData);
>>         sortedData.comparatorProperty().bind(table.comparatorProperty());
>>         table.setItems(sortedData);
>>
>>         Button loadManyBtn = new Button("Add 10,000 items");
>>         loadManyBtn.setOnAction(e -> {
>>             System.out.println("Adding 10000 items to master data");
>>             masterData.clear();
>>             for (int i = 0; i < 10000; i++) masterData.add(new
>> PotentialLargeData("Info item " + i));
>>         });
>>
>>         Button reduceBtn = new Button("Reduce to 2");
>>         reduceBtn.setOnAction(e -> {
>>             System.out.println("Reducing master data size to 2");
>>             masterData.setAll(new PotentialLargeData("New info 1"), new
>> PotentialLargeData("New info 2"));
>>         });
>>
>>         Button printBtn = new Button("Print interal sizes");
>>         printBtn.setOnAction(e -> {
>>             try {
>>                 System.out.println("Items the user sees: " +
>> sortedData.size());
>>                 int[] filtered = (int[]) getFieldValue(filteredData,
>> "filtered");
>>                 System.out.println("FilteredList.filtered length: " +
>> filtered.length);
>>                 // This is a hidden and significant waste of memory
>>                 Object[] sorted = (Object[]) getFieldValue(sortedData,
>> "sorted");
>>                 System.out.println("SortedList.sorted length: " +
>> sorted.length);
>>             } catch (Exception ex) {
>>                 throw new RuntimeException(ex);
>>             }
>>         });
>>
>>         primaryStage.setScene(new Scene(new VBox(table, loadManyBtn,
>> reduceBtn, printBtn), 600, 400));
>>         primaryStage.show();
>>     }
>>
>>     private static Object getFieldValue(Object object, String fieldName)
>> throws Exception {
>>         Field field = object.getClass().getDeclaredField(fieldName);
>>         field.setAccessible(true);
>>         return field.get(object);
>>     }
>> }
>>
>>
>> Kind Regards,
>> Cormac
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251207/381eb032/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sorted_list_mem.gif
Type: image/gif
Size: 128014 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251207/381eb032/sorted_list_mem-0001.gif>

From martinfox656 at gmail.com  Mon Dec  8 01:54:42 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Sun, 7 Dec 2025 17:54:42 -0800
Subject: macOS 26 title bar artifacts
In-Reply-To: <85f141ff-821a-4957-8818-66d42bfad164@xpipe.io>
References: <70d4e007-6501-4c18-a838-0a7d881fd7b1@xpipe.io>
 <85f141ff-821a-4957-8818-66d42bfad164@xpipe.io>
Message-ID: <EC87E3AD-0336-4A0A-9C4D-5A1F6CE1F3C1@gmail.com>

I can reproduce this in a reduced form on my macOS 26.1 system. When I hover over the stoplight buttons their backgrounds are drawn incorrectly.

We take the color specified in the Scene constructor (the default is white) and pass it along as the NSWindow?s background color. The OS then tints the titlebar using that color. If we don?t set the window?s background color this bug goes away based on my very limited testing.

I wanted to take a closer look at what?s going on but when I launch the Digital Color Meter app the bug stops happening. Which is interesting.

No idea what the workaround might be short of not setting the NSWindow background color.

> On Dec 6, 2025, at 1:40?AM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Bump, since this mail was stuck in the moderation queue for two weeks and probably nobody saw it.
> 
> On 19/11/2025 11:53 PM, Christopher Schnick wrote:
>> Hello,
>> 
>> I discovered an weird graphical glitch around the title bar buttons on macOS 26.0.1 and the latest JavaFX (but it's also there in older JavaFX versions).
>> 
>> I have no idea what causes this, there aren't any customizations configured for the Stage that I can think of. I haven't seen this happen in any other app so far.
>> 
>> It happens at least in my project's releases from https://github.com/xpipe-io/kickstartfx/releases/latest
>> 
>> Best
>> Christopher Schnick
>> 


From arapte at openjdk.org  Mon Dec  8 05:06:13 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 8 Dec 2025 05:06:13 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
 <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
Message-ID: <AQ0S8tIxFm9Y8y327849qk671l35iu6IeReF4Dw15G0=.508759ab-aac7-4d1c-a5bd-1d0239d65fba@github.com>

On Mon, 1 Dec 2025 22:08:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
>> 
>> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
>> 
>> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
>> 
>> 
>> public class ZeroSizeSubScene extends Application {
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var rect = new Rectangle(50, 50, Color.RED);
>>         var subScene = new SubScene(new Group(rect), 100, 100);
>>         subScene.setFill(Color.GRAY);
>> 
>>         // Also try a perspective camera:
>>         //
>>         // var camera = new PerspectiveCamera();
>>         // camera.setRotate(45);
>>         // camera.setTranslateX(-20);
>>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>>         // subScene.setCamera(camera);
>> 
>>         class MyButton extends Button {
>>             public MyButton(String text, double width, double height) {
>>                 super(text);
>>                 setOnAction(_ -> {
>>                     var timeline = new Timeline(
>>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
>> 
>>                     timeline.setOnFinished(_ -> {
>>                         Point2D p0 = rect.localToScreen(0, 0);
>>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>>                     });
>> 
>>                     timeline.play();
>>                 });
>>             }
>>         }
>> 
>>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
>> 
>>         var root = new VBox(5,
>>             subScene,
>>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>>             new MyButton("Size: 100x100", 100, 100),
>>             new MyButton("Size: 10x10", 10, 10),
>>             new MyButton("Size: 100x0", 100, 0),
>>             ne...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1992#pullrequestreview-3550135942

From arapte at openjdk.org  Mon Dec  8 05:06:14 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 8 Dec 2025 05:06:14 GMT
Subject: RFR: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene [v2]
In-Reply-To: <yFsglntORrsY6isS35RG-e2xCyFyi6yv-tcHV8uOLSo=.d136e52b-eb45-41e9-916c-dee4ec31304a@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
 <1Al1iS95zotQhJuoekTf97Ip0oircRcAyvFu5nNnvxo=.51415942-a59f-4076-b744-fa1eb2e5d635@github.com>
 <5l8qR_tlH-1hmnjAnkNZQumoMBBMtWM_I6fBFf7yE7o=.0d80e955-3ed7-4805-8571-426e2c16b59d@github.com>
 <yFsglntORrsY6isS35RG-e2xCyFyi6yv-tcHV8uOLSo=.d136e52b-eb45-41e9-916c-dee4ec31304a@github.com>
Message-ID: <2DoUizHbWhZs38ojYpzfTLZG0oSmLwCkyoJdV8UlVpE=.9611395f-bd5a-4085-b2c9-3c11db94ae61@github.com>

On Fri, 5 Dec 2025 14:16:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `localToScreen` is not specified to account for something being "shown" on screen. Instead, it answers the question: given a point in the local coordinate system of a node, which point on the screen does it correspond to?

That seems right to me. I tested a few more random coordinates, the behavior same before and after this change. (as expected)

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

PR Comment: https://git.openjdk.org/jfx/pull/1992#issuecomment-3624812611

From arapte at openjdk.org  Mon Dec  8 05:16:14 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 8 Dec 2025 05:16:14 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
In-Reply-To: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
Message-ID: <Tfti5doidlBg19_AgPza1bIyGCL_zORx_LtEhdigxEQ=.09bac228-2d8d-4090-8d79-9b56b1ca7206@github.com>

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)
> 
> Under this change, there are two factors that affect our zip files.
> 1. Files have fixed timestamps (timestamps depends on the archive type).
> 2. File order in the archive is now deterministic.
> Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.
> 
> the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.
> 
> Verified that for all files extracted from generated zip files:
> 1. Timestamp is now not fixed, and reflects the CREATION date.
> 2. The file permissions are unchanged.

@tiainen Please take a look

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

PR Comment: https://git.openjdk.org/jfx/pull/1993#issuecomment-3624917680

From mstrauss at openjdk.org  Mon Dec  8 06:30:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 8 Dec 2025 06:30:14 GMT
Subject: Integrated: 8372761: Prevent degenerate transforms for zero-size
 Scene/SubScene
In-Reply-To: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
References: <f39Y4Qt-UajsfonuRsiBFj9cciVWWznoH-LyUVwgWFY=.3144ba98-96ae-4ff1-a13b-1bd6ce586bc9@github.com>
Message-ID: <8lpt4e9C09faSiFidjpVOh2VL4VUPkqOMafvunQXGEU=.b925051c-ba58-4a7c-a126-75948684d4a1@github.com>

On Sun, 30 Nov 2025 03:25:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When a `Scene` or `SubScene` has its width or height set to 0, coordinate transformations stop working because the transformation matrix contains NaNs. This is a consequence of divisions by zero in both parallel and perspective projections.
> 
> Even though a 0x0 scene is mathematically degenerate, it is still desirable for coordinate transformation APIs to remain numerically well-behaved and return finite results whenever possible, rather than being poisoned by NaN/Infinity.
> 
> Here is an application that demonstrates the failing coordinate transformations. Click on the buttons to resize the SubScene and observe the console output. After applying the patch in this PR, you should observe that `localToScreen()` no longer returns NaN.
> 
> 
> public class ZeroSizeSubScene extends Application {
> 
>     @Override
>     public void start(Stage stage) {
>         var rect = new Rectangle(50, 50, Color.RED);
>         var subScene = new SubScene(new Group(rect), 100, 100);
>         subScene.setFill(Color.GRAY);
> 
>         // Also try a perspective camera:
>         //
>         // var camera = new PerspectiveCamera();
>         // camera.setRotate(45);
>         // camera.setTranslateX(-20);
>         // camera.setRotationAxis(new Point3D(0, 1, 0));
>         // subScene.setCamera(camera);
> 
>         class MyButton extends Button {
>             public MyButton(String text, double width, double height) {
>                 super(text);
>                 setOnAction(_ -> {
>                     var timeline = new Timeline(
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.widthProperty(), width)),
>                         new KeyFrame(Duration.seconds(1), new KeyValue(subScene.heightProperty(), height)));
> 
>                     timeline.setOnFinished(_ -> {
>                         Point2D p0 = rect.localToScreen(0, 0);
>                         System.out.println("rect.localToScreen(0, 0) = " + p0);
>                     });
> 
>                     timeline.play();
>                 });
>             }
>         }
> 
>         VBox.setMargin(subScene, new Insets(0, 0, 20, 0));
> 
>         var root = new VBox(5,
>             subScene,
>             new CheckBox("Rotate SubScene") {{ setOnAction(_ -> subScene.setRotate(isSelected() ? 45 : 0)); }},
>             new MyButton("Size: 100x100", 100, 100),
>             new MyButton("Size: 10x10", 10, 10),
>             new MyButton("Size: 100x0", 100, 0),
>             new MyButton("Size: 0x100", 0, 100),
>             new MyButton("Size: 0x0", 0, 0)
>         );
> 
>         S...

This pull request has now been integrated.

Changeset: 9e1c70c7
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9e1c70c7d5204cb4b4ec863e12f7d93a9ad16a99
Stats:     168 lines in 3 files changed: 108 ins; 16 del; 44 mod

8372761: Prevent degenerate transforms for zero-size Scene/SubScene

Reviewed-by: angorya, arapte

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

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

From arapte at openjdk.org  Mon Dec  8 08:40:21 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 8 Dec 2025 08:40:21 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash
In-Reply-To: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
Message-ID: <ImR-OiYRp1shkAIW45DbYGyhyqBHhw5zkPIL25n-TtI=.8e59574d-6777-4fab-97db-de7f3611ca1e@github.com>

On Fri, 5 Dec 2025 13:43:45 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
> 
> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
> 
> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
> 
> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
> 
> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

Observation: On Mac, The test program results in below exception


DelayedCallback not implemented yet: JDK-8091740
java.lang.Exception: Stack trace
	at java.base/java.lang.Thread.dumpStack(Thread.java:2018)
	at javafx.graphics at 26-internal/com.sun.glass.ui.mac.MacSystemClipboard.pushToSystem(MacSystemClipboard.java:157)
	at javafx.graphics at 26-internal/com.sun.glass.ui.SystemClipboard.flush(SystemClipboard.java:51)
	at javafx.graphics at 26-internal/com.sun.glass.ui.ClipboardAssistance.flush(ClipboardAssistance.java:59)
	at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:630)
	at javafx.graphics at 26-internal/javafx.scene.input.Clipboard.setContent(Clipboard.java:244)
	at Abort1$1.run(Abort1.java:24)
	at javafx.graphics at 26-internal/com.sun.javafx.application.PlatformImpl.lambda$runLater$0(PlatformImpl.java:424)
	at javafx.graphics at 26-internal/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)


As you pointed, that can be matched/changed when the behavior is unified.

modules/javafx.graphics/src/main/native-glass/gtk/GlassSystemClipboard.cpp line 202:

> 200:         if (jurl != NULL && mainEnv->IsInstanceOf(jurl, jStringCls)) {
> 201:             url = getUTF(mainEnv, jurl);
> 202:         }

May be the type casting to `jstring` on line 198 be removed, as there is no guarantee that returned object is jstring, and may be change type of `jurl` to `jobject`
similarly line no 235.

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

PR Review: https://git.openjdk.org/jfx/pull/1999#pullrequestreview-3550760783
PR Review Comment: https://git.openjdk.org/jfx/pull/1999#discussion_r2597570409

From mhanl at openjdk.org  Mon Dec  8 11:50:15 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 8 Dec 2025 11:50:15 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: <ie6qFlfd2Cb1P1Jo05owCHOOSFgUICSm8-27QRg42c4=.c5246e37-662d-4559-9ee2-ea685617ef45@github.com>
References: <wf49A9Cv05TOHVrHB13numUo2qfwyrg-UnvUbc1JS6M=.26a864df-3429-43fb-85e9-a9e0b52eb7bc@github.com>
 <Vg6y2XoT0s-zXM6hI3Lcas6VXGhCouWGHHb9DACRSLQ=.a36939a5-8fe7-4309-933e-959336a92e57@github.com>
 <C-fprMy8fhJH4o7kSvcD9w4-E1547ARZcofiKykNzzo=.5d8f67ed-4624-4f37-a17a-d55baddb1232@github.com>
 <CC-SPDELW9jsPu3evQb0V5gZT5czmB5eB_MyQ_zE3d4=.6936067a-2342-4153-ba78-5c6b2f7a4df3@github.com>
 <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
 <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>
 <g3fKq_bF0Q89jVGSMz0pcbS4OQqgKbgLYxqf2akiKIM=.4949e12c-0137-472a-b071-915c657ced61@github.com>
 <_IE0eaP3WCTKNcNlP9gC3yJN5OGi0lMmDKOmFD1u_OU=.316308c4-21f6-4c09-9447-b78d416d5ca3@github.com>
 <ie6qFlfd2Cb1P1Jo05owCHOOSFgUICSm8-27QRg42c4=.c5246e37-662d-4559-9ee2-ea685617ef45@github.com>
Message-ID: <j8jqAT5DTkxuDzqDXFMaS7Htt4qIiHwtjp2WrmORRLM=.3c1496ad-08ca-4f8e-a3f4-a675de5ba00f@github.com>

On Fri, 5 Dec 2025 15:02:32 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> I think you might have it backwards: `all` should depend on the task to build the publications, not the other way around. The goal is that `gradle all` should produce `build/publications`.

Did you have a specific idea in mind when writing the message? 
I ran a few tests, but nothing worked without explicitly writing `publishToMavenLocal` within the command.
And I don't want to worsen the separation between the main and publish gradle files.
If there's no idea at the moment, then I'll continue looking for a good solution!

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3626517617

From lkostyra at openjdk.org  Mon Dec  8 13:53:15 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 8 Dec 2025 13:53:15 GMT
Subject: RFR: 8326428: [Linux] UI scaling factor cannot be fractional when
 using KDE
In-Reply-To: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
References: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
Message-ID: <QuXPMRgEoFjTCuwyIUYqx53xnp_FrxiThei-DpnLRVU=.5b9fae9a-6078-4d25-bec9-5bdbafcf4e0b@github.com>

On Mon, 1 Dec 2025 17:57:30 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The standard way to determine the user interface scaling factor on Linux is to consult the reported monitor DPI and divide by 96 (which is also the way it's done on Windows). This allows the scaling factor to vary per-monitor and also achieve fractional values.
> 
> Before this became the standard the Gnome toolkit communicated the scaling factor using the "GDK_SCALE" environment variable or the "org.gnome.desktop.interface" "scaling-factor" gsetting. These were always integer values (no fractional scaling) and applied to all monitors. They became the de-facto way of communicating the scaling factor and were picked  by various toolkits including JavaFX. They are now obsolete within Gnome.
> 
> JavaFX will compute correct per-monitor scaling factors if GDK_SCALE and "scaling-factor" aren't set. Gnome no longer sets these but unfortunately the KDE desktop does in an attempt to get certain apps to scale (one bug report specifically called out IntelliJ). In KDE for Ubuntu 24 the "scaling-factor" is always set to the floor of the actual scaling factor which is preventing JavaFX from computing fractional scales. Either setting will prevent JavaFX from computing per-monitor scales.
> 
> This PR changes the priority of the ui scale tests. As always, the JavaFX "glass.gtk.uiScale" setting takes precedence. If that's not set the system uses the scaling computed based on the monitor DPI. It only consults the legacy settings if the reported DPI is 96.
> 
> Ignoring GDK_SCALE is problematic since there are certainly users who use this as a convenient way to influence JavaFX (if only to work around this bug). If we want to provide an environment variable for them we should create our own and not rely on the legacy variables of other toolkits.

LGTM, tested on Ubuntu 24.04 with both KDE and Gnome, in both render scale is correct with 125% scaling.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1994#pullrequestreview-3552190447

From lkostyra at openjdk.org  Mon Dec  8 14:21:07 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 8 Dec 2025 14:21:07 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash
In-Reply-To: <QybkqggSaEdEQ-_9VicAmJ2M5Gecu3OjCfhpPkJrnX8=.5c1f492b-3648-4be5-91bd-c5b34b975e32@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
 <QybkqggSaEdEQ-_9VicAmJ2M5Gecu3OjCfhpPkJrnX8=.5c1f492b-3648-4be5-91bd-c5b34b975e32@github.com>
Message-ID: <7W3StRFvs8t9uaWUeAaio3ru0Vbz_GDjfyAEkwOAeDk=.f7cc08ef-dd3b-4058-ab9d-8fe616dc8854@github.com>

On Fri, 5 Dec 2025 17:19:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
>> 
>> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
>> 
>> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
>> 
>> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
>> 
>> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).
>
> Questions:
> 1. do we have the same issue with other text types (e.g. "text/css" or "text/javascript")?
> 2. should we have an automated test developed which places mismatched data to the clipboard (it might need to be headful to operate with the real clipboard)?
> 
> Another consideration is what should happen when a single item of unacceptable data is put into the clipboard.  Should it replace the existing clipboard content (possibly from another application), or should it be a no-op?

@andy-goryachev-oracle 

> do we have the same issue with other text types (e.g. "text/css" or "text/javascript")?

Those types are not mentioned in `DataFormat.java`. `ClipboardContent` can only take `DataFormat` entries as keys. I would assume those are unsupported.

> should we have an automated test developed which places mismatched data to the clipboard (it might need to be headful to operate with the real clipboard)?

Absolutely! Although, as I mentioned in the previous comment to @kevinrushforth we don't really have a way to make this test platform independent yet due to different platforms behaving differently in this scenario.

I can make it Linux-only for now based on this change, and we can "free it" to other platforms with [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090) but then the question is - what should be the expected behavior? With this change on Linux we assume silently that nothing happens, but maybe we should expect an Exception? I think it doesn't make much sense to write a whole test if we plan to make some changes to the API and have to inevitably adjust or even rewrite it - it would make more sense to establish those tests with [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

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

PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3627155212

From lkostyra at openjdk.org  Mon Dec  8 15:11:08 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 8 Dec 2025 15:11:08 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash [v2]
In-Reply-To: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
Message-ID: <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>

> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
> 
> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
> 
> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
> 
> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
> 
> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Review: Move jstring cast

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1999/files
  - new: https://git.openjdk.org/jfx/pull/1999/files/0ad0aaf5..ff278dd2

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

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

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

From zelmidaoui at openjdk.org  Mon Dec  8 16:02:32 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 8 Dec 2025 16:02:32 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
 <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
Message-ID: <bCUcAxCG7H2MNBao9fNNMGFtFx4-7EXiSyc3E-huNh8=.611038a1-62aa-47da-a31e-8e0fa48bfea5@github.com>

On Tue, 2 Dec 2025 17:10:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
>> 
>> Test cases:
>> 
>>     @Test
>>     public void addTextAfterRegion() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addParagraph(() -> new Region());
>>         m.addNodeSegment(() -> new Region());
>>         assertEquals(2, m.size());
>>     }
>> 
>>     @Test
>>     public void addTextAfterRegionAfterText() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addNodeSegment(() -> new Region());
>>         m.addParagraph(() -> new Region());
>>         m.addSegment("text");
>>         assertEquals(3, m.size());
>>     }
>
> Andy Goryachev 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372438.non.text.paragraphs
>  - fix

LGTM , the test works with the fix

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

PR Comment: https://git.openjdk.org/jfx/pull/1983#issuecomment-3627700881

From zelmidaoui at openjdk.org  Mon Dec  8 16:06:37 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 8 Dec 2025 16:06:37 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
 <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
Message-ID: <HN87xKzeWRDsVtuUTpj4L-6d8js9CGTuZhcpy6UG71U=.9f68c553-fa8b-472d-a624-523ab198e4dc@github.com>

On Tue, 2 Dec 2025 17:10:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
>> 
>> Test cases:
>> 
>>     @Test
>>     public void addTextAfterRegion() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addParagraph(() -> new Region());
>>         m.addNodeSegment(() -> new Region());
>>         assertEquals(2, m.size());
>>     }
>> 
>>     @Test
>>     public void addTextAfterRegionAfterText() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addNodeSegment(() -> new Region());
>>         m.addParagraph(() -> new Region());
>>         m.addSegment("text");
>>         assertEquals(3, m.size());
>>     }
>
> Andy Goryachev 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372438.non.text.paragraphs
>  - fix

Marked as reviewed by zelmidaoui (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1983#pullrequestreview-3552830115

From angorya at openjdk.org  Mon Dec  8 16:59:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Dec 2025 16:59:00 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
 <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
Message-ID: <ZzzKgfxrt85m9QKaDcCzVYy6ZvduupkTekmARX6LvC0=.b4b69343-0b61-4001-8a7d-4bfb3894ad2a@github.com>

On Tue, 2 Dec 2025 17:10:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
>> 
>> Test cases:
>> 
>>     @Test
>>     public void addTextAfterRegion() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addParagraph(() -> new Region());
>>         m.addNodeSegment(() -> new Region());
>>         assertEquals(2, m.size());
>>     }
>> 
>>     @Test
>>     public void addTextAfterRegionAfterText() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addNodeSegment(() -> new Region());
>>         m.addParagraph(() -> new Region());
>>         m.addSegment("text");
>>         assertEquals(3, m.size());
>>     }
>
> Andy Goryachev 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372438.non.text.paragraphs
>  - fix

@lukostyra can I trouble you for a review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1983#issuecomment-3628029873

From angorya at openjdk.org  Mon Dec  8 19:04:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Dec 2025 19:04:15 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash [v2]
In-Reply-To: <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
 <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
Message-ID: <jofuiWMz5-uPMSYE_FDk7U5fmsBTi8FUZXSXwXuvnD0=.a1f3c4fd-7259-49f1-9461-e2150beede62@github.com>

On Mon, 8 Dec 2025 15:11:08 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
>> 
>> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
>> 
>> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
>> 
>> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
>> 
>> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Move jstring cast

FYI: I've added a Clipboard page to the standalone monkey tester
https://github.com/andy-goryachev-oracle/MonkeyTest

with a bunch of canned options for data format and data values for testing.
Feel free to add (or ask me to add) missing combinations.

<img width="1274" height="477" alt="Screenshot 2025-12-08 at 10 58 42" src="https://github.com/user-attachments/assets/9afe5b26-5ad4-4cda-b6f4-0b3709e8330f" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3628583197

From mstrauss at openjdk.org  Mon Dec  8 23:16:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 8 Dec 2025 23:16:18 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: <AIfGHcTRfmZARDmLJO-i2Gk9GP7s4F4fI8xWTeiLAPA=.df7d0ed6-d0f1-4040-8c13-80720437ff37@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <hajVA9L5jTPU0338Kv29KLifaTBb9PaRaEMTFVAojkE=.3ce941b5-f436-4817-8d2e-59165c2b9fec@github.com>
 <SdUHESG8rXRdleOI9cH8zcEqIIFC9jiSNSgJ_uz2HgA=.249a2f18-776b-4ade-8a70-f2546a9fed7a@github.com>
 <AIfGHcTRfmZARDmLJO-i2Gk9GP7s4F4fI8xWTeiLAPA=.df7d0ed6-d0f1-4040-8c13-80720437ff37@github.com>
Message-ID: <YumD88vCL13i2-F0tzDvgR9VL2oW5GT2HdeqFAiylRo=.72eca4a9-1d75-4ac4-8c1f-d1deb05d0db3@github.com>

On Thu, 4 Dec 2025 14:40:43 GMT, Alessadro Parisi <duke at openjdk.org> wrote:

> On Linux Min 22.2 with Cinnamon I get a rectangular window no matter what. I also tried setting the root's background color and radius, as well as the scene's fill to `TRANSPARENT` but nothing works.
> 
> One thing I'm curious about is why it was implemented this way. I mean, if the native decorations are just rendered on top of JavaFX nodes, then why I'm not able to set the scene's fill to `TRANSPARENT` and let the developer handle the rest.

The USP of an extended stage is: give me native window decorations (borders, drop shadows, animations, etc.) but don't give me the native title bar. As it turns out, this is surprisingly hard to do with GTK: we either get all of the decorations, or almost none of them. We can't tell GTK to just give us a native-looking window without the title bar, we can only get a completely undecorated window. We didn't forget the rounded corners, it's just a non-trivial thing to achieve.

Could we have implemented this feature in a way where you'll basically get a transparent window, and then have the application be responsible for drawing decorations and drop shadows? Maybe. But that would be a different feature, we want the native-looking windows without applications trying (and failing) to recreate their look-and-feel. In addition to that, such an approach would also lead to applications looking like they're stuck in time when a future OS version changes the styling of native window decorations.

@tsayao recently posted an [email](https://mail.openjdk.org/pipermail/openjfx-dev/2025-September/056374.html) to the mailing list with some thoughts on how the Linux situation could be improved.

> Edit: btw this is quite the issue because I can't achieve a consistent look across the various systems. The only solution is to use a `TRANSPARENT` Stage and make my own window buttons, losing a ton of features though (resize, drag, snap assistants, etc.)

Using a transparent stage has even more downsides, as you'll not only lose all of the things you mentioned, but also window animations (on Windows) and drop shadows.

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

PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3629422412

From angorya at openjdk.org  Mon Dec  8 23:17:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Dec 2025 23:17:25 GMT
Subject: RFR: 8373193: RichTextArea: exceptions specifying position beyond the
 document end
Message-ID: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>

Tying loose ends: clamping start/end positions in the `StyledTextModel` mutation operations to avoid problems down the road.

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

Commit messages:
 - fix
 - Merge remote-tracking branch 'origin/master' into 8373193.beyond
 - tests

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

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

From lkostyra at openjdk.org  Tue Dec  9 10:44:12 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 9 Dec 2025 10:44:12 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
 <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
Message-ID: <IAfDRtFit0xKK3Qxc4GGo38Bv_2H6uwY3wmizy0BHRk=.7ae21313-9154-44f0-abf3-eabd5fbde552@github.com>

On Tue, 2 Dec 2025 17:10:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
>> 
>> Test cases:
>> 
>>     @Test
>>     public void addTextAfterRegion() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addParagraph(() -> new Region());
>>         m.addNodeSegment(() -> new Region());
>>         assertEquals(2, m.size());
>>     }
>> 
>>     @Test
>>     public void addTextAfterRegionAfterText() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addNodeSegment(() -> new Region());
>>         m.addParagraph(() -> new Region());
>>         m.addSegment("text");
>>         assertEquals(3, m.size());
>>     }
>
> Andy Goryachev 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372438.non.text.paragraphs
>  - fix

LGTM

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1983#pullrequestreview-3556698389

From lkostyra at openjdk.org  Tue Dec  9 10:44:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 9 Dec 2025 10:44:53 GMT
Subject: RFR: 8359759: Remove the FXPermission class
Message-ID: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>

As PR title says, this change removes the FXPermission class.

The class was not used in any place in JavaFX. It was marked deprecated in JFX24 and also marked for-removal, with plans to remove it in 26.

I ran both local Windows tests and CI tests with this change and, as expected, there was no difference in test results (all passed).

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

Commit messages:
 - Remove FXPermission

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

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

From jpereda at openjdk.org  Tue Dec  9 10:46:15 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 9 Dec 2025 10:46:15 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <ebrrce9GKJbX0g474pVI0nDn94QUgnUSNiuSZVGrdpA=.1613e3ce-daa0-461f-bdfb-6797f83a2bb2@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <XmT4aBenwGQoI4A2EXbNqVQd0zFG7T3M_u_BxhrBVPc=.e8c25c35-ae41-4342-9242-2c6832a7735a@github.com>
 <z1JAr7WIsbGjF_Mx5l8WRkTfWK4EMLRAgEBPOC5ANeo=.1dcdc726-e16e-42de-ba7b-580025b88133@github.com>
 <ebrrce9GKJbX0g474pVI0nDn94QUgnUSNiuSZVGrdpA=.1613e3ce-daa0-461f-bdfb-6797f83a2bb2@github.com>
Message-ID: <P-cToD_U4-tMqEJTz0gD8VEBNQeb78ujwm8LQ4X7tZA=.0aa4114c-01ba-48d2-bc1d-5e69b43862fe@github.com>

On Mon, 10 Nov 2025 22:13:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> There is a reason for it, otherwise I wouldn't have modified `Screen`.
>> 
>> If you run the [test](https://bugs.openjdk.org/secure/attachment/112708/Menu_RenderScale_8346281.java) in the JBS issue, on Windows with two monitors (primary with scale > 100%), with the changes from `GlassWindow.cpp` only, without changing `Screen`, when you open the File menu of the window in the secondary display, the context menu is misplaced:
>> 
>> <img width="404" height="341" alt="Screenshot 2025-11-08 143811" src="https://github.com/user-attachments/assets/5844155e-c6cb-4b9a-9edb-c81b1140b8bb" />
>> 
>> Adding some debugging info, it can be seen that, when the application starts (without doing any external change in Windows settings), there is a DPI event, that calls `notifySettingsChanged`, at a point where there is only a `Window` instance (the one in the primary screen), instead of two. The two screens get disposed (that is, `Screen.ptr = 0`), and later on, when the secondary window is created, it gets assigned the disposed secondary screen, with this `ptr = 0`. 
>> 
>> When opening the `File` menu of the secondary window, another DPI event is triggered, `notifySettingsChanged` is called, but since there was no real change in the screens, the new screens are the same as the old ones (the valid  `ptr` didn't change after the event). However, the valid secondary screen is not assigned to the secondary Window, because the if test, (ptr from old screen was 0, and new screen ptr >0 doesn't match), so it keeps the old screen instance with `ptr = 0`.
>> 
>> This causes some unexpected issues for instance in `WinWindow::notifyMoving`, as there is a mixture of valid screens (from `Screen.getScreens()`) and invalid one in `Window::getScreen`, and the equality checks (`screen1 == screen2`) fails, ultimately providing wrong screen information for the popup.
>> 
>> So the change in `Screen` that I propose in this PR removes the disposal of screens if these are not assigned to a window yet.
>> 
>> Does that make sense?
>
> Hmm. I see what you are saying, and can confirm the behavior. With your proposed fix, though, it seems like we will still have a situation where an in-use screen object is no longer in the list of screens. When this happens it will point to the same native screen object as one of the newly-created screens. This seems fragile.
> 
> Maybe we could still dispose all old screens, but do it in a way that allows it to later be mapped to a new screen? Or, thinking out loud, maybe "put back" the screens that didn't actually change as the result of the DPI change notification?
> 
> I'll want to think about this and take a closer look, but it will be a couple days before I can get to it.

@kevinrushforth did you have the chance to have a look at this?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2602088383

From angorya at openjdk.org  Tue Dec  9 15:32:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 9 Dec 2025 15:32:53 GMT
Subject: RFR: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs [v2]
In-Reply-To: <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
 <TjqV10jz2UKFcrDTScS_-MhT8z-tU4cD56oGOKMCFAs=.1c5531a2-c71d-4bfc-94c1-19da3f9a02ea@github.com>
Message-ID: <b4hlZ-cpxYNUsgdattw2N97DwX3jBSgPafyMNDE2i3Q=.1d966939-d4c2-403b-8285-52793992abad@github.com>

On Tue, 2 Dec 2025 17:10:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
>> 
>> Test cases:
>> 
>>     @Test
>>     public void addTextAfterRegion() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addParagraph(() -> new Region());
>>         m.addNodeSegment(() -> new Region());
>>         assertEquals(2, m.size());
>>     }
>> 
>>     @Test
>>     public void addTextAfterRegionAfterText() {
>>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>>         m.addNodeSegment(() -> new Region());
>>         m.addParagraph(() -> new Region());
>>         m.addSegment("text");
>>         assertEquals(3, m.size());
>>     }
>
> Andy Goryachev 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8372438.non.text.paragraphs
>  - fix

Thank you all!

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

PR Comment: https://git.openjdk.org/jfx/pull/1983#issuecomment-3632869571

From angorya at openjdk.org  Tue Dec  9 15:35:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 9 Dec 2025 15:35:55 GMT
Subject: Integrated: 8372438: SimpleViewOnlyStyledModel: non-text paragraphs
In-Reply-To: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
References: <y3RICKp_WRviJ2HGfqv19u0hKCgdGcSP8XqjmkuWEEw=.db932531-97e1-480e-bbe3-3b6f723eccae@github.com>
Message-ID: <MnTWq23ZCou0LaA_2tD8c15nhImJpClaDG4CY6Qfabg=.e155bd90-2ef0-462e-918a-f20e426edd75@github.com>

On Mon, 24 Nov 2025 20:23:28 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixing a bug in `SimpleViewOnlyStyledModel.lastParagraph()` which breaks adding text segments after a `Region`-based paragraph.
> 
> Test cases:
> 
>     @Test
>     public void addTextAfterRegion() {
>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>         m.addParagraph(() -> new Region());
>         m.addNodeSegment(() -> new Region());
>         assertEquals(2, m.size());
>     }
> 
>     @Test
>     public void addTextAfterRegionAfterText() {
>         SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel();
>         m.addNodeSegment(() -> new Region());
>         m.addParagraph(() -> new Region());
>         m.addSegment("text");
>         assertEquals(3, m.size());
>     }

This pull request has now been integrated.

Changeset: 03612e1b
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/03612e1b4855c178febe63160070af66e82f9ee1
Stats:     83 lines in 2 files changed: 67 ins; 0 del; 16 mod

8372438: SimpleViewOnlyStyledModel: non-text paragraphs

Reviewed-by: zelmidaoui, lkostyra

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

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

From lukasz.kostyra at oracle.com  Tue Dec  9 15:36:54 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Tue, 9 Dec 2025 15:36:54 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9B6FC6AF955C783A9EA92AFEA6A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io>
 <DM3PPF3367D7B9B751B25F083A68EF6D7F0FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <c21d8e4a-7269-4290-8a70-54cbccd8a782@xpipe.io>
 <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io>
 <IA3PR10MB8682C066B2046DBD40631D0CFEC9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <IA3PR10MB8682E4623B0A4251DBAF9AAEFEDCA@IA3PR10MB8682.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>
Message-ID: <DM3PPF3367D7B9B9292A1E528D3FB529977FEA3A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Hi Christopher,

I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved.

Thanks,
-Lukasz

From: openjfx-dev <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>
Cc: OpenJFX <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 01DC692A.05CD3630]

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 01DC692A.05CD3630]

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/20251209/fe7ee41d/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/20251209/fe7ee41d/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/20251209/fe7ee41d/image002-0001.png>

From angorya at openjdk.org  Tue Dec  9 15:45:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 9 Dec 2025 15:45:33 GMT
Subject: RFR: 8359759: Remove the FXPermission class
In-Reply-To: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
References: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
Message-ID: <4ZipxrfWsKxOd9xcDXbo1LU-7jHxBKnIenvew_OmEE0=.65624fd7-cd9d-473e-9121-db9ab43c20e5@github.com>

On Tue, 9 Dec 2025 10:38:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> As PR title says, this change removes the FXPermission class.
> 
> The class was not used in any place in JavaFX. It was marked deprecated in JFX24 and also marked for-removal, with plans to remove it in 26.
> 
> I ran both local Windows tests and CI tests with this change and, as expected, there was no difference in test results (all passed).

The class is not used anymore (as reported by Eclipse).
The build builds.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2002#pullrequestreview-3558162355

From crschnick at xpipe.io  Tue Dec  9 16:10:11 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 9 Dec 2025 17:10:11 +0100
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <DM3PPF3367D7B9B9292A1E528D3FB529977FEA3A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io>
 <DM3PPF3367D7B9B751B25F083A68EF6D7F0FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <c21d8e4a-7269-4290-8a70-54cbccd8a782@xpipe.io>
 <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io>
 <IA3PR10MB8682C066B2046DBD40631D0CFEC9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <IA3PR10MB8682E4623B0A4251DBAF9AAEFEDCA@IA3PR10MB8682.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>
Message-ID: <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io>

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 
> . Let me know how it works and if the problem has been resolved.
>
> Thanks,
>
> -Lukasz
>
> *From:*openjfx-dev <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>
> *Cc:* OpenJFX <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/20251209/78f84577/attachment-0001.htm>
-------------- 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/20251209/78f84577/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/20251209/78f84577/image002-0001.png>

From kcr at openjdk.org  Tue Dec  9 18:30:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Dec 2025 18:30:16 GMT
Subject: RFR: 8359759: Remove the FXPermission class
In-Reply-To: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
References: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
Message-ID: <-TQhEa6c8apud2J06ffaOYwjY2vzcfgBW-lXP-HHsMk=.466637c5-4038-45cf-aa46-5887d1cff14b@github.com>

On Tue, 9 Dec 2025 10:38:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> As PR title says, this change removes the FXPermission class.
> 
> The class was not used in any place in JavaFX. It was marked deprecated in JFX24 and also marked for-removal, with plans to remove it in 26.
> 
> I ran both local Windows tests and CI tests with this change and, as expected, there was no difference in test results (all passed).

This needs two reviewers and a CSR!

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

PR Comment: https://git.openjdk.org/jfx/pull/2002#issuecomment-3633657462

From kcr at openjdk.org  Tue Dec  9 18:33:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Dec 2025 18:33:57 GMT
Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes [v2]
In-Reply-To: <P-cToD_U4-tMqEJTz0gD8VEBNQeb78ujwm8LQ4X7tZA=.0aa4114c-01ba-48d2-bc1d-5e69b43862fe@github.com>
References: <tcHd1vxOJAH0dYAkU1O1snUqoUNC7_opqH71gl40gC8=.70eb2eb1-653f-4edf-bb0a-a3d8e3d6f754@github.com>
 <V37RQXYmkadZJv01bSMprvEAmWaUgyDi3m38DeWZ7OU=.9dc834c1-07ac-44af-b8c9-07701077293a@github.com>
 <XmT4aBenwGQoI4A2EXbNqVQd0zFG7T3M_u_BxhrBVPc=.e8c25c35-ae41-4342-9242-2c6832a7735a@github.com>
 <z1JAr7WIsbGjF_Mx5l8WRkTfWK4EMLRAgEBPOC5ANeo=.1dcdc726-e16e-42de-ba7b-580025b88133@github.com>
 <ebrrce9GKJbX0g474pVI0nDn94QUgnUSNiuSZVGrdpA=.1613e3ce-daa0-461f-bdfb-6797f83a2bb2@github.com>
 <P-cToD_U4-tMqEJTz0gD8VEBNQeb78ujwm8LQ4X7tZA=.0aa4114c-01ba-48d2-bc1d-5e69b43862fe@github.com>
Message-ID: <JJu5qKZQgGj7tPnUQ121Tnrdg0pqWfuDB0wse3fIG94=.338088d8-f8ae-4f47-ae7d-58a6347b860c@github.com>

On Tue, 9 Dec 2025 10:43:36 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Hmm. I see what you are saying, and can confirm the behavior. With your proposed fix, though, it seems like we will still have a situation where an in-use screen object is no longer in the list of screens. When this happens it will point to the same native screen object as one of the newly-created screens. This seems fragile.
>> 
>> Maybe we could still dispose all old screens, but do it in a way that allows it to later be mapped to a new screen? Or, thinking out loud, maybe "put back" the screens that didn't actually change as the result of the DPI change notification?
>> 
>> I'll want to think about this and take a closer look, but it will be a couple days before I can get to it.
>
> @kevinrushforth did you have the chance to have a look at this?

Sorry for the delay. I'm pretty backed up on reviews and plan to get to this soon.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1964#discussion_r2603841051

From kcr at openjdk.org  Tue Dec  9 18:56:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Dec 2025 18:56:44 GMT
Subject: RFR: 8359759: Remove the FXPermission class
In-Reply-To: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
References: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
Message-ID: <y_jEflIA13w0jclQNjBhPvQrdIYlwcROi0sOu8F55YY=.7d6608ae-8a64-4cff-9582-ba2709935826@github.com>

On Tue, 9 Dec 2025 10:38:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> As PR title says, this change removes the FXPermission class.
> 
> The class was not used in any place in JavaFX. It was marked deprecated in JFX24 and also marked for-removal, with plans to remove it in 26.
> 
> I ran both local Windows tests and CI tests with this change and, as expected, there was no difference in test results (all passed).

LGTM

@lukostyra You can create the CSR when ready.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/2002#pullrequestreview-3559183342

From mstrauss at openjdk.org  Wed Dec 10 00:08:10 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 00:08:10 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
Message-ID: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>

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 would go off-screen" capability for popups. This complements the existing `PopupWindow.anchorLocation` / `PopupWindow.autoFix` behavior: applications can keep using `PopupWindow.anchorLocation` to express the preferred anchor, while `PopupWindow.anchorPolicy` controls how the popup may flip that anchor as a fallback when the preferred placement wouldn't fit within screen bounds.

## Edge constraints
`screenPadding` specifies per-edge padding relative to the screen, expressed as an `Insets`:

* An inset value >= 0 enables a constraint for that edge and specifies the minimum distance in pixels that the stage must keep from that screen edge.
* An inset value < 0 disables the constraint for that edge.

Enabled constraints effectively shrink the usable screen area by the given insets.

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

Commit messages:
 - add relocate() overload that accepts Screen
 - refactor
 - small changes
 - doc fixes
 - tweaks
 - refactor everything
 - javadocs
 - ensure screenPadding is not negative
 - add clampPolicy and screenPadding
 - update tests
 - ... and 2 more: https://git.openjdk.org/jfx/compare/43d39204...e5dfb0eb

Changes: https://git.openjdk.org/jfx/pull/1986/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1986&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372530
  Stats: 1654 lines in 10 files changed: 1565 ins; 54 del; 35 mod
  Patch: https://git.openjdk.org/jfx/pull/1986.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1986/head:pull/1986

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

From mhanl at openjdk.org  Wed Dec 10 00:08:13 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 10 Dec 2025 00:08:13 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: <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@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...

I will test and review this. Especially test with the scenarios where I used the workaround described in the mailing list. 
And give feedback accordingly (API and Functionality-wise).
Will probably take a bit, as there are some other things (like Direct3D12) on my list.

modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1298:

> 1296:     @Override
> 1297:     public void centerOnScreen() {
> 1298:         relocationRequest = null; // cancel previous relocation request

As far as I understand, with the new anchor system, a center on screen can easily be achieved as well? I wonder if we could also deprecate this method instead. But not sure if I understand it correctly.

modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1459:

> 1457:      * @since 26
> 1458:      */
> 1459:     public static final class Anchor {

This could be a record too

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 1120:

> 1118:                     }
> 1119: 
> 1120:                     // Give subclasses a chance to adjust the window bounds

Unrelated to this Enhancement, but I wonder if the `centerOnScreen` line before could also be rewritten using this system (at one point). Now, it looks like he might be centering the `Window`, and then fix the bounds to something else, wasting some time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1986#issuecomment-3585241787
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2570081956
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2563846982
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2563859678

From angorya at openjdk.org  Wed Dec 10 00:08:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 00:08:15 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: <aOFn8TQIDaGT5eFZu0FVRcwKwxRS0lLQwIokvBi8bsI=.5e74440b-b631-4e49-93f6-d22b5d3d8a56@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...

modules/javafx.graphics/src/main/java/javafx/stage/ClampPolicy.java line 36:

> 34:  * @since 26
> 35:  */
> 36: public enum ClampPolicy {

maybe call it `RelocationPolicy`?

modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 325:

> 323:      * @since 26
> 324:      */
> 325:     public final void show(double anchorX, double anchorY, AnchorPoint anchor) {

would it make more sense to move these new methods to `Window`, so they can also work for the `Popup` and its hierarchy ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2565968723
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2565559963

From mstrauss at openjdk.org  Wed Dec 10 00:08:16 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 00:08:16 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <aOFn8TQIDaGT5eFZu0FVRcwKwxRS0lLQwIokvBi8bsI=.5e74440b-b631-4e49-93f6-d22b5d3d8a56@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <aOFn8TQIDaGT5eFZu0FVRcwKwxRS0lLQwIokvBi8bsI=.5e74440b-b631-4e49-93f6-d22b5d3d8a56@github.com>
Message-ID: <zrL9t7Lmy6yOijyAAboPBBMhQieEKL-OV6xrxK5sCLk=.92187cc5-4531-4482-ad6a-0484c461aa0d@github.com>

On Wed, 26 Nov 2025 15:55:50 GMT, Andy Goryachev <angorya 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").
>> 
>> ### PopupW...
>
> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 325:
> 
>> 323:      * @since 26
>> 324:      */
>> 325:     public final void show(double anchorX, double anchorY, AnchorPoint anchor) {
> 
> would it make more sense to move these new methods to `Window`, so they can also work for the `Popup` and its hierarchy ?

`PopupWindow` works differently, it has a `anchorLocation` property which is a bit limited. We also couldn't move `PopupWindow.AnchorLocation` anywhere else (as this would be a breaking change), which would make the signature of the show() method very awkward: On `Stage.show(x, y, PopupWindow.AnchorLocation)` you'd have a parameter that is declared on an unrelated class.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2565651731

From angorya at openjdk.org  Wed Dec 10 00:08:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 00:08:16 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <zrL9t7Lmy6yOijyAAboPBBMhQieEKL-OV6xrxK5sCLk=.92187cc5-4531-4482-ad6a-0484c461aa0d@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <aOFn8TQIDaGT5eFZu0FVRcwKwxRS0lLQwIokvBi8bsI=.5e74440b-b631-4e49-93f6-d22b5d3d8a56@github.com>
 <zrL9t7Lmy6yOijyAAboPBBMhQieEKL-OV6xrxK5sCLk=.92187cc5-4531-4482-ad6a-0484c461aa0d@github.com>
Message-ID: <i-eqCLdK11z_8AZcfqpZ6VqFXYP1IjacjfdzIqS8FpU=.7f805b16-7abf-401c-af75-bf106662f3dd@github.com>

On Wed, 26 Nov 2025 16:23:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 325:
>> 
>>> 323:      * @since 26
>>> 324:      */
>>> 325:     public final void show(double anchorX, double anchorY, AnchorPoint anchor) {
>> 
>> would it make more sense to move these new methods to `Window`, so they can also work for the `Popup` and its hierarchy ?
>
> `PopupWindow` works differently, it has a `anchorLocation` property which is a bit limited. We also couldn't move `PopupWindow.AnchorLocation` anywhere else (as this would be a breaking change), which would make the signature of the show() method very awkward: On `Stage.show(x, y, PopupWindow.AnchorLocation)` you'd have a parameter that is declared on an unrelated class.

Yeah, this is unfortunate.
Can we do anything to make the positioning of Popups and its hierarchy easier?  Maybe add another `show()` with a `ClampPolicy` argument?

Use case: I want to open a PopupWindow below the owner node, but: if the popup cannot be placed there because the whole thing is too close to the bottom of the screen, I want the popup to be **above** the node, and not on top of it as it works currently.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2565965017

From mstrauss at openjdk.org  Wed Dec 10 00:08:17 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 00:08:17 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <i-eqCLdK11z_8AZcfqpZ6VqFXYP1IjacjfdzIqS8FpU=.7f805b16-7abf-401c-af75-bf106662f3dd@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <aOFn8TQIDaGT5eFZu0FVRcwKwxRS0lLQwIokvBi8bsI=.5e74440b-b631-4e49-93f6-d22b5d3d8a56@github.com>
 <zrL9t7Lmy6yOijyAAboPBBMhQieEKL-OV6xrxK5sCLk=.92187cc5-4531-4482-ad6a-0484c461aa0d@github.com>
 <i-eqCLdK11z_8AZcfqpZ6VqFXYP1IjacjfdzIqS8FpU=.7f805b16-7abf-401c-af75-bf106662f3dd@github.com>
Message-ID: <PgnecImzNw1TY5LNcXe0NxeyJVTM8uLEIi1BTeX1nvg=.eeacbbdb-4a99-4bc2-9db9-e4d1e3c96a41@github.com>

On Wed, 26 Nov 2025 17:48:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `PopupWindow` works differently, it has a `anchorLocation` property which is a bit limited. We also couldn't move `PopupWindow.AnchorLocation` anywhere else (as this would be a breaking change), which would make the signature of the show() method very awkward: On `Stage.show(x, y, PopupWindow.AnchorLocation)` you'd have a parameter that is declared on an unrelated class.
>
> Yeah, this is unfortunate.
> Can we do anything to make the positioning of Popups and its hierarchy easier?  Maybe add another `show()` with a `ClampPolicy` argument?
> 
> Use case: I want to open a PopupWindow below the owner node, but: if the popup cannot be placed there because the whole thing is too close to the bottom of the screen, I want the popup to be **above** the node, and not on top of it as it works currently.

I've redesigned the feature a bit, and found that we can indeed make this compatible with `PopupWindow`. You now have the option to specify `PopupWindow.anchorPolicy`, which defaults to the current behavior, but can also be specified to work as you describe (using `AnchorPolicy.AUTO`).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2570059453

From mstrauss at openjdk.org  Wed Dec 10 00:08:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 00:08:18 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@github.com>
Message-ID: <ZwL7bDPebg_RJP4XRFh8m6wGz5GyTD7h1qLRSSuFLX4=.58bb3e44-176f-42a2-832c-7dc794e478d9@github.com>

On Thu, 27 Nov 2025 23:10:15 GMT, Marius Hanl <mhanl 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").
>> 
>> ### PopupW...
>
> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1298:
> 
>> 1296:     @Override
>> 1297:     public void centerOnScreen() {
>> 1298:         relocationRequest = null; // cancel previous relocation request
> 
> As far as I understand, with the new anchor system, a center on screen can easily be achieved as well? I wonder if we could also deprecate this method instead. But not sure if I understand it correctly.

No, the anchor is always a point _on the window being shown_, not on the screen. All anchor APIs require you to specify an explicit screen location, and the window is then moved so that the anchor coincides with that screen location. So to emulate `centerOnScreen()`, you'd have to manually get the screen bounds, and then calculate the center.

> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1459:
> 
>> 1457:      * @since 26
>> 1458:      */
>> 1459:     public static final class Anchor {
> 
> This could be a record too

Yes it could, but I don't like the boolean parameter that it would expose. Boolean parameters are usually not a good idea, as they lead to "boolean blindness" at the call site. I've moved this entire class to `javafx.geometry`, as it might be useful for other code in the future, and I don't want to proliferate two nested versions of an anchor point (one in `Stage`, the other in `PopupWindow`).

> modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 1120:
> 
>> 1118:                     }
>> 1119: 
>> 1120:                     // Give subclasses a chance to adjust the window bounds
> 
> Unrelated to this Enhancement, but I wonder if the `centerOnScreen` line before could also be rewritten using this system (at one point). Now, it looks like he might be centering the `Window`, and then fix the bounds to something else, wasting some time.

I've re-implemented `centerOnScreen` in terms of `WindowLocationAlgorithm`, so it now uses the same code paths as the `relocate()` methods.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2570158460
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2565054489
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2604714657

From angorya at openjdk.org  Wed Dec 10 00:08:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 00:08:19 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <ZwL7bDPebg_RJP4XRFh8m6wGz5GyTD7h1qLRSSuFLX4=.58bb3e44-176f-42a2-832c-7dc794e478d9@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@github.com>
 <ZwL7bDPebg_RJP4XRFh8m6wGz5GyTD7h1qLRSSuFLX4=.58bb3e44-176f-42a2-832c-7dc794e478d9@github.com>
Message-ID: <8L59E5_HE8adIRqlMwkMGrgNnZ-0C9Mbfm9kTKN2uR4=.71da99a0-37cb-4f78-96d4-7476a6d2868a@github.com>

On Fri, 28 Nov 2025 00:09:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1298:
>> 
>>> 1296:     @Override
>>> 1297:     public void centerOnScreen() {
>>> 1298:         relocationRequest = null; // cancel previous relocation request
>> 
>> As far as I understand, with the new anchor system, a center on screen can easily be achieved as well? I wonder if we could also deprecate this method instead. But not sure if I understand it correctly.
>
> No, the anchor is always a point _on the window being shown_, not on the screen. All anchor APIs require you to specify an explicit screen location, and the window is then moved so that the anchor coincides with that screen location. So to emulate `centerOnScreen()`, you'd have to manually get the screen bounds, and then calculate the center.

Is there something that prevents us to invent a new anchor type?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2600499939

From mstrauss at openjdk.org  Wed Dec 10 00:08:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 00:08:19 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <8L59E5_HE8adIRqlMwkMGrgNnZ-0C9Mbfm9kTKN2uR4=.71da99a0-37cb-4f78-96d4-7476a6d2868a@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@github.com>
 <ZwL7bDPebg_RJP4XRFh8m6wGz5GyTD7h1qLRSSuFLX4=.58bb3e44-176f-42a2-832c-7dc794e478d9@github.com>
 <8L59E5_HE8adIRqlMwkMGrgNnZ-0C9Mbfm9kTKN2uR4=.71da99a0-37cb-4f78-96d4-7476a6d2868a@github.com>
Message-ID: <LjSGUZRKdxnOXZSawggrD1cdOqgj1IOnoJrmw9cYDag=.a4d09c5a-8aa5-4c0d-b402-13ef58b2f1df@github.com>

On Mon, 8 Dec 2025 23:28:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> No, the anchor is always a point _on the window being shown_, not on the screen. All anchor APIs require you to specify an explicit screen location, and the window is then moved so that the anchor coincides with that screen location. So to emulate `centerOnScreen()`, you'd have to manually get the screen bounds, and then calculate the center.
>
> Is there something that prevents us to invent a new anchor type?

Maybe we can specify two anchors:

void Stage.relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);


Then, if you want to center the window on the screen, you can do:

myStage.relocate(AnchorPoint.proportional(0.5, 0.5), AnchorPoint.proportional(0.5, 0.5));
// or myStage.relocate(AnchorPoint.CENTER, AnchorPoint.CENTER);

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2600619105

From angorya at openjdk.org  Wed Dec 10 00:08:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 00:08:20 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <LjSGUZRKdxnOXZSawggrD1cdOqgj1IOnoJrmw9cYDag=.a4d09c5a-8aa5-4c0d-b402-13ef58b2f1df@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@github.com>
 <ZwL7bDPebg_RJP4XRFh8m6wGz5GyTD7h1qLRSSuFLX4=.58bb3e44-176f-42a2-832c-7dc794e478d9@github.com>
 <8L59E5_HE8adIRqlMwkMGrgNnZ-0C9Mbfm9kTKN2uR4=.71da99a0-37cb-4f78-96d4-7476a6d2868a@github.com>
 <LjSGUZRKdxnOXZSawggrD1cdOqgj1IOnoJrmw9cYDag=.a4d09c5a-8aa5-4c0d-b402-13ef58b2f1df@github.com>
Message-ID: <GWmIpTFHiIW0y6GgxqLaRM5oPsXcUtFY2Q_vYNSxx9Q=.17a09b35-5ab2-4613-8fd7-15a6a1268ce7@github.com>

On Tue, 9 Dec 2025 00:28:00 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Is there something that prevents us to invent a new anchor type?
>
> Maybe we can specify two anchors:
> 
> void Stage.relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);
> 
> 
> Then, if you want to center the window on the screen, you can do:
> 
> myStage.relocate(AnchorPoint.proportional(0.5, 0.5), AnchorPoint.proportional(0.5, 0.5));
> // or myStage.relocate(AnchorPoint.CENTER, AnchorPoint.CENTER);

I like it, because we can easily cover almost all the possible cases.  

Should we also allow to specify the `Screen`?  In a third parameter to this extended method?  And if the `Screen` is `null`, the logic would use the default screen or the owner's one?  What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2603354322

From mstrauss at openjdk.org  Wed Dec 10 00:08:20 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 00:08:20 GMT
Subject: RFR: 8372530: Easier placement of windows with positioning anchor
In-Reply-To: <GWmIpTFHiIW0y6GgxqLaRM5oPsXcUtFY2Q_vYNSxx9Q=.17a09b35-5ab2-4613-8fd7-15a6a1268ce7@github.com>
References: <Wd32EkUDk5c_JqFglXdGaeF8rCpS8amI6ljqJMAplwU=.fc13c921-a37b-4005-abd6-33f9762760b1@github.com>
 <JpIvzcxCOwDl2BedY5IDE7Oh-qspu1mEDHZhQLEUvAQ=.f3d8db40-7ac9-4441-8efc-63b876f9eb43@github.com>
 <ZwL7bDPebg_RJP4XRFh8m6wGz5GyTD7h1qLRSSuFLX4=.58bb3e44-176f-42a2-832c-7dc794e478d9@github.com>
 <8L59E5_HE8adIRqlMwkMGrgNnZ-0C9Mbfm9kTKN2uR4=.71da99a0-37cb-4f78-96d4-7476a6d2868a@github.com>
 <LjSGUZRKdxnOXZSawggrD1cdOqgj1IOnoJrmw9cYDag=.a4d09c5a-8aa5-4c0d-b402-13ef58b2f1df@github.com>
 <GWmIpTFHiIW0y6GgxqLaRM5oPsXcUtFY2Q_vYNSxx9Q=.17a09b35-5ab2-4613-8fd7-15a6a1268ce7@github.com>
Message-ID: <ObuFlCgwUkD5k_a4QU8Hsmcw-9ew5lfHI9EdRZPqK8U=.faf54b7c-266d-4c24-bbfd-e47db0927257@github.com>

On Tue, 9 Dec 2025 16:13:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Maybe we can specify two anchors:
>> 
>> void Stage.relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);
>> 
>> 
>> Then, if you want to center the window on the screen, you can do:
>> 
>> myStage.relocate(AnchorPoint.proportional(0.5, 0.5), AnchorPoint.proportional(0.5, 0.5));
>> // or myStage.relocate(AnchorPoint.CENTER, AnchorPoint.CENTER);
>
> I like it, because we can easily cover almost all the possible cases.  
> 
> Should we also allow to specify the `Screen`?  In a third parameter to this extended method?  And if the `Screen` is `null`, the logic would use the default screen or the owner's one?  What do you think?

I've added another overload that accepts a `Screen`. The overloads _without_ the screen parameter will always refer to the _current_ screen. This allows users to relocate a stage on its current screen as if it was the primary screen (i.e. with `(0, 0)` being the top-left corner).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2604705791

From mstrauss at openjdk.org  Wed Dec 10 05:42:16 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 05:42:16 GMT
Subject: RFR: 8367557: Extended stage seems to hang after drag and drop
Message-ID: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>

An extended stage seems to hang after a drag and drop operation. Note that in the attached reproducer, the application seems unresponsive until the mouse cursor leaves and re-enters the application window:


import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.input.ClipboardContent;
import javafx.scene.input.Dragboard;
import javafx.scene.input.TransferMode;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.HBox;
import javafx.scene.layout.HeaderBar;
import javafx.stage.Stage;
import javafx.stage.StageStyle;

public class DragDropTest extends Application {

    @Override
    public void start(Stage primaryStage) {

        primaryStage.initStyle(StageStyle.EXTENDED);

        // Create drag source
        Label dragSource = new Label("Drag me!");
        dragSource.setStyle("-fx-background-color: lightblue; -fx-padding: 10px");

        // Create drop target
        Label dropTarget = new Label("Drop here!");
        dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;");

        // Set up drag detection
        dragSource.setOnDragDetected(event -> {
            Dragboard dragboard = dragSource.startDragAndDrop(TransferMode.COPY);
            ClipboardContent content = new ClipboardContent();
            content.putString("Hello from drag source!");
            dragboard.setContent(content);
            event.consume();
        });

        // Set up drag over
        dropTarget.setOnDragOver(event -> {
            if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) {
                event.acceptTransferModes(TransferMode.COPY);
            }
            event.consume();
        });

        // Set up drag entered (visual feedback)
        dropTarget.setOnDragEntered(event -> {
            if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) {
                dropTarget.setStyle("-fx-background-color: lightgreen; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;");
            }
            event.consume();
        });

        // Set up drag exited (reset visual feedback)
        dropTarget.setOnDragExited(event -> {
            dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;");
            event.consume();
        });

        // Set up drop
        dropTarget.setOnDragDropped(event -> {
            Dragboard dragboard = event.getDragboard();
            boolean success = false;

            if (dragboard.hasString()) {
                dropTarget.setText("Dropped: " + dragboard.getString());
                success = true;
            }

            event.setDropCompleted(success);
            event.consume();
        });

        // Layout
        HBox layout = new HBox(20);
        layout.getChildren().addAll(dragSource, dropTarget);
        layout.setStyle("-fx-padding: 20px;");

        var root = new BorderPane();
        root.setTop(new HeaderBar());
        root.setCenter(layout);

        Scene scene = new Scene(root, 400, 200);

        // Test with different stage styles
        // Change this line to test different styles:
        // primaryStage.initStyle(StageStyle.DECORATED); // Try: UNDECORATED, UTILITY, TRANSPARENT, etc.

        primaryStage.setTitle("Drag and Drop Test");
        primaryStage.setScene(scene);
        primaryStage.show();
    }
}


The cause for this bug is that a drag-and-drop operation can cause a spurious `WM_MOUSELEAVE` message to be sent to the window, even though the mouse cursor is still within the client area. This messes up the mouse tracking state in GlassWindow.

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

Commit messages:
 - fix spurious WM_MOUSELAVE on DnD

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

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

From sykora at openjdk.org  Wed Dec 10 08:33:06 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 10 Dec 2025 08:33:06 GMT
Subject: RFR: 8371855: Time stamps are missing on zip bundles with gradle 9
In-Reply-To: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
Message-ID: <eDptSWK0mhlbDbjKcKVn6sBnyRf3aTUQ60rzE3s-3Zg=.a17f3a80-0350-4da8-82ef-9497cb8d47ae@github.com>

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)
> 
> Under this change, there are two factors that affect our zip files.
> 1. Files have fixed timestamps (timestamps depends on the archive type).
> 2. File order in the archive is now deterministic.
> Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.
> 
> the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.
> 
> Verified that for all files extracted from generated zip files:
> 1. Timestamp is now not fixed, and reflects the CREATION date.
> 2. The file permissions are unchanged.

I can verify that the timestamps are now correctly applied to the files inside archives.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1993#pullrequestreview-3561324010

From lukasz.kostyra at oracle.com  Wed Dec 10 12:29:26 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Wed, 10 Dec 2025 12:29:26 +0000
Subject: JavaFX Direct3D 12 - Second EA release
In-Reply-To: <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io>
References: <DM3PPF3367D7B9B73450CB12325D0070943FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io>
 <DM3PPF3367D7B9B751B25F083A68EF6D7F0FECDA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>
 <c21d8e4a-7269-4290-8a70-54cbccd8a782@xpipe.io>
 <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io>
 <IA3PR10MB8682C066B2046DBD40631D0CFEC9A@IA3PR10MB8682.namprd10.prod.outlook.com>
 <IA3PR10MB8682E4623B0A4251DBAF9AAEFEDCA@IA3PR10MB8682.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>
Message-ID: <DM3PPF3367D7B9B7FDB5C3D88286A91852DFEA0A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

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<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 01DC69D9.0011AB90]

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 01DC69D9.0011AB90]

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/20251210/ed9ade2b/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/20251210/ed9ade2b/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/20251210/ed9ade2b/image002-0001.png>

From arapte at openjdk.org  Wed Dec 10 16:09:16 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 10 Dec 2025 16:09:16 GMT
Subject: Integrated: 8371855: Time stamps are missing on zip bundles with
 gradle 9
In-Reply-To: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
References: <7KIUK1vapmVGYyN6MHQXPfNJK7jQ5uU48NrJszHiN-E=.d75883e7-ad80-4069-9bd3-3ec98841babc@github.com>
Message-ID: <s7m7xRahynR-FY7JixjbZ_fyNzr11l1kcxTt134dKrU=.cc64ca57-6e66-4fd8-8eb5-4cfef473baf0@github.com>

On Mon, 1 Dec 2025 10:27:10 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 9 onwards, the [Archive tasks (Jar, Ear, War, Zip, AbstractArchiveTask) produce reproducible archives by default](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default)
> 
> Under this change, there are two factors that affect our zip files.
> 1. Files have fixed timestamps (timestamps depends on the archive type).
> 2. File order in the archive is now deterministic.
> Especially the timestamp is a concern, the files now have a fixed timestamp i.e. 1 Feb 1980 instead of the creation date.
> 
> the [gradle upgrading guide](https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#reproducible_archives_by_default) provides the solution on how to restore previous behavior. The fix picks 2 necessary flags.
> 
> Verified that for all files extracted from generated zip files:
> 1. Timestamp is now not fixed, and reflects the CREATION date.
> 2. The file permissions are unchanged.

This pull request has now been integrated.

Changeset: e776b372
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e776b3728f6f5710376870cf84e01f05a503b616
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8371855: Time stamps are missing on zip bundles with gradle 9

Reviewed-by: kcr, sykora

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

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

From mhanl at openjdk.org  Wed Dec 10 17:12:44 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 10 Dec 2025 17:12:44 GMT
Subject: RFR: 8359759: Remove the FXPermission class
In-Reply-To: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
References: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
Message-ID: <BWadJcahNGU3Z_nzfBq20GwDEpVxFwqqkCbC_v_Zklg=.cb9184a9-5fb3-49b9-9bbc-7acb7c59bc90@github.com>

On Tue, 9 Dec 2025 10:38:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> As PR title says, this change removes the FXPermission class.
> 
> The class was not used in any place in JavaFX. It was marked deprecated in JFX24 and also marked for-removal, with plans to remove it in 26.
> 
> I ran both local Windows tests and CI tests with this change and, as expected, there was no difference in test results (all passed).

Always good to remove unused code!

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/2002#pullrequestreview-3563627854

From mstrauss at openjdk.org  Wed Dec 10 17:27:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Dec 2025 17:27:25 GMT
Subject: RFR: 8369836: Update HeaderBar API [v5]
In-Reply-To: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <dUHzjffcEil7ZQgUMAFQXT6qFxfqUUxNbPZMNj4i2VU=.e87391f2-7736-4e76-83ca-f1a4afe40450@github.com>

> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
> 
> With this in mind, there are three changes for the `HeaderBar` control:
> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
> 3. Make `leftSystemInset`, `rightSystemInset`, and `minSystemHeight` attached properties for `Stage`.
> 
> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

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

  stage doc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1936/files
  - new: https://git.openjdk.org/jfx/pull/1936/files/f6a93537..02b1150c

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

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

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

From angorya at openjdk.org  Wed Dec 10 18:33:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 18:33:45 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v8]
In-Reply-To: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
Message-ID: <HtXMUBSykK_KoZPNFq5qVF-I-pa_jaJuJJOsU2WkbjA=.571b8f57-407f-4d28-b9a1-982b660860ce@github.com>

> This PR addresses the user feedback:
> 
> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
> 
> 
> The problem being solved here is to allow the developers to easily add functionality to the existing `RichTextModel` (and its storage implementation) without creating a new model from scratch.
> 
> This is done in two parts:
> 
> 1. Allowing the custom model to alter the paragraph by giving access to its Builder via a new protected method
> 
> 
> protected RichParagraph.Builder buildParagraph(int index)
> 
> 
> 2. Adding two methods that give access to the segments in the `RichParagraph` and `RichParagraph.Builder` classes:
> 
> - getSegmentCount()
> - getSegment(int index)
> 
> NOTE: Even though returning an (immutable) List might be considered "more useful", doing so would necessitate creating a copy - something I do want to avoid.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - javadoc
 - cleanup
 - Merge branch 'master' into 8366198.rbuilder
 - rich paragraph builder api
 - Merge branch 'master' into 8371070.enhance
 - npe
 - merge
 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - Merge branch 'master' into 8371070.enhance
 - ... and 2 more: https://git.openjdk.org/jfx/compare/03612e1b...05136fe1

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

Changes: https://git.openjdk.org/jfx/pull/1966/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1966&range=07
  Stats: 253 lines in 8 files changed: 176 ins; 43 del; 34 mod
  Patch: https://git.openjdk.org/jfx/pull/1966.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1966/head:pull/1966

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

From angorya at openjdk.org  Wed Dec 10 18:33:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 18:33:47 GMT
Subject: RFR: 8371070: RichParagraph enhancements [v7]
In-Reply-To: <YF-9J6a1Lj_bJaIhjyaBlcFs66woFdpInSU4XoE2sQw=.66787b08-2154-47f7-84cc-80a99e4bda8b@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
 <YF-9J6a1Lj_bJaIhjyaBlcFs66woFdpInSU4XoE2sQw=.66787b08-2154-47f7-84cc-80a99e4bda8b@github.com>
Message-ID: <vlspOvtoWavTxUv-btFXQUZ1lGDYMKiWLcz-I5XxOSQ=.074a4a79-4b1c-4ec7-931e-de3b2e8d6e85@github.com>

On Fri, 5 Dec 2025 17:09:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR addresses the user feedback:
>> 
>> In RichParagraph you have a note to make getSegments() public.  It would be helpful if it was.
>> 
>> 
>> The problem being solved here is to allow the developers to easily add functionality to the existing `RichTextModel` (and its storage implementation) without creating a new model from scratch.
>> 
>> This is done in two parts:
>> 
>> 1. Allowing the custom model to alter the paragraph by giving access to its Builder via a new protected method
>> 
>> 
>> protected RichParagraph.Builder buildParagraph(int index)
>> 
>> 
>> 2. Adding two methods that give access to the segments in the `RichParagraph` and `RichParagraph.Builder` classes:
>> 
>> - getSegmentCount()
>> - getSegment(int index)
>> 
>> NOTE: Even though returning an (immutable) List might be considered "more useful", doing so would necessitate creating a copy - something I do want to avoid.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into 8371070.enhance
>  - npe
>  - merge
>  - Merge branch 'master' into 8371070.enhance
>  - Merge branch 'master' into 8371070.enhance
>  - Merge branch 'master' into 8371070.enhance
>  - test
>  - expose segments

There is an alternative.

Instead of adding `getSegmentCount()` / `getSegment(int)` methods to the `RichParagraph`, we might expose the `RichParagraph.Builder` used to build the paragraph by the model via

protected RichParagraph.Builder buildParagraph(int index)



method added to the `RichTextModel` class (and possibly to the `CodeTextModel` as well).

Doing so would allow custom models easily add custom attributes that generate highlights or wavy underlines (which might span segments or apply to partial segments), as can be seen in the following example:

https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java

<img width="592" height="316" alt="Screenshot 2025-12-09 at 10 48 20" src="https://github.com/user-attachments/assets/47acd986-6f5d-471a-94e1-ad1b4c0f3b32" />

Exposing the builder would also necessitate adding `getSegmentCount()` / `getSegment(int)` methods to the `RichParagraph.Builder`.

What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1966#issuecomment-3634052681

From angorya at openjdk.org  Wed Dec 10 18:39:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 18:39:24 GMT
Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't
 reach VFlow [v5]
In-Reply-To: <jxbrGDlwgQGy5c8S8pReOBvemiXbf64V6E1_7CXrwlU=.183ac0a3-f923-4b6a-aabf-469af7ee27b8@github.com>
References: <jxbrGDlwgQGy5c8S8pReOBvemiXbf64V6E1_7CXrwlU=.183ac0a3-f923-4b6a-aabf-469af7ee27b8@github.com>
Message-ID: <0U919wMlKFH4iuG5pQqkQDqRuSikos3g4PJl6nHBFNw=.6d552b4b-83d9-4784-9f96-5382be787935@github.com>

> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`.
> 
> 
> ### NOTES
> 
> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved)
> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> <img width="1232" height="741" alt="Screenshot 2025-11-17 at 13 43 12" src="https://github.com/user-attachments/assets/58b2ef77-094c-45bd-8a04-3caaa4672df1" />

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into 8371067.request.layout
 - Merge branch 'master' into 8371067.request.layout
 - updated test
 - Merge branch 'master' into 8371067.request.layout
 - add text segment
 - Merge branch 'master' into 8371067.request.layout
 - test
 - request layout
 - test
 - fix

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

Changes: https://git.openjdk.org/jfx/pull/1975/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1975&range=04
  Stats: 100 lines in 4 files changed: 94 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1975.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1975/head:pull/1975

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

From angorya at openjdk.org  Wed Dec 10 22:51:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 22:51:08 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: <a8e0kAgXGYndf_VBARYvFjRtU7VTI_0IF2o_E5A5G3k=.bcc9f872-4280-40d5-af4d-02fb2bc177d5@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...

modules/javafx.graphics/src/main/java/com/sun/javafx/stage/WindowRelocator.java line 105:

> 103:             } else {
> 104:                 gravityX = stageAnchor.getX() / windowWidth;
> 105:                 gravityY = stageAnchor.getY() / windowHeight;

It might be a good idea to explain what "gravity" is, maybe in `ComputedLocation` or `WindowLocationAlgorithm`.

Here, for example, L101 tells us the gravity is measured in pixels, while L104 indicates the gravity is dimensionless.

modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1322:

> 1320:      * @since 26
> 1321:      */
> 1322:     public final void relocate(Screen screen, AnchorPoint screenAnchor, Insets screenPadding,

would it be conceptually simpler to offer just one new method with all the possible parameters (screen anchors, insets) instead of several?  I presume these new methods will be rarely used.
or, if there is one frequent case, provide an additional utility method for that case?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2608315565
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2608469098

From angorya at openjdk.org  Wed Dec 10 23:01:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Dec 2025 23:01:39 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: <Rz2GgP8xO6D-p24H4X0KAPYPO2Io6XC7ClYiUkVvkys=.72d6b735-153c-4cf3-9adb-5a2eb9f92697@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...

some preliminary comments, I'll test it more in the next couple of days.

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

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

From arapte at openjdk.org  Thu Dec 11 04:26:42 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 11 Dec 2025 04:26:42 GMT
Subject: RFR: 8269630: Bad clipboard data causes JVM to crash [v2]
In-Reply-To: <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
 <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
Message-ID: <nEGaiDB2vybPgB36QJKOoVXGkQeNCZdm5JLON0Ft50c=.19719fbe-282d-4a3d-8a39-001cfd2581bc@github.com>

On Mon, 8 Dec 2025 15:11:08 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This commit fixes the JVM crash caused by bad Clipboard data on Linux.
>> 
>> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.
>> 
>> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.
>> 
>> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.
>> 
>> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Move jstring cast

lgtm

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1999#pullrequestreview-3565555224

From lkostyra at openjdk.org  Thu Dec 11 11:44:42 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 11 Dec 2025 11:44:42 GMT
Subject: Integrated: 8359759: Remove the FXPermission class
In-Reply-To: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
References: <q_DhG2FQO1BgYPyL8k2BSQ4jqFEa32JO_9gRVl_6MDw=.dddc4e20-4e1e-4174-8b6b-a2598fc12794@github.com>
Message-ID: <RbtVD6JT98K2wSTgX29nerfdPNBefMp2MbqgD1ZvHWM=.6823c823-c028-46b1-aa17-1132a1c0bf1b@github.com>

On Tue, 9 Dec 2025 10:38:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> As PR title says, this change removes the FXPermission class.
> 
> The class was not used in any place in JavaFX. It was marked deprecated in JFX24 and also marked for-removal, with plans to remove it in 26.
> 
> I ran both local Windows tests and CI tests with this change and, as expected, there was no difference in test results (all passed).

This pull request has now been integrated.

Changeset: 843338e7
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/843338e7fdd2a0d3fe306b1a8a69f405948f0906
Stats:     71 lines in 1 file changed: 0 ins; 71 del; 0 mod

8359759: Remove the FXPermission class

Reviewed-by: angorya, kcr, mhanl

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

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

From lkostyra at openjdk.org  Thu Dec 11 12:21:18 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 11 Dec 2025 12:21:18 GMT
Subject: RFR: 8373193: RichTextArea: exceptions specifying position beyond
 the document end
In-Reply-To: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>
References: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>
Message-ID: <UGnCe-MetCpT5FyCSRiFoaHmNeIGlFZ96k_V7BCpZgI=.1c912c32-1942-48a8-b145-5c3a4fd00adc@github.com>

On Mon, 8 Dec 2025 20:38:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Tying loose ends: clamping start/end positions in the `StyledTextModel` mutation operations to avoid problems down the road.

LGTM, a quick test run and manual check works fine

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2001#pullrequestreview-3567169936

From zelmidaoui at openjdk.org  Thu Dec 11 15:32:58 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Dec 2025 15:32:58 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode [v2]
In-Reply-To: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
Message-ID: <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>

> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
> Tested with monkeyTester and the test in the bug

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

  Fixed incorrect layout when resizing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1995/files
  - new: https://git.openjdk.org/jfx/pull/1995/files/4571e9bb..049e555f

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

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

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

From zelmidaoui at openjdk.org  Thu Dec 11 15:33:01 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Dec 2025 15:33:01 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <DCfBTt604t3LUYdkjBPYYIDFl46czgyHLqIC2OH0PyY=.cc3e2094-6774-42cd-a3da-36fe5ebbbb23@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <9mdEmiM2gME2yppSL2ru6ivSI7mnAfaVl_CZtYIqfwM=.cbad938d-493e-47f8-bc15-59144170cf98@github.com>
 <DCfBTt604t3LUYdkjBPYYIDFl46czgyHLqIC2OH0PyY=.cc3e2094-6774-42cd-a3da-36fe5ebbbb23@github.com>
Message-ID: <SXVGgs39-vxo3MyrZ9qS3Dgx_J2cqU1G8wrwbWwPWX8=.e3875d19-f258-430c-a44b-48177a3129db@github.com>

On Wed, 3 Dec 2025 22:03:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Notice how the layout is still not right in some places when the window is resized (the screenshots are from a combined branch of this PR + #1988 but the result is still the same, I think):

I have fixed this issue could you please re-review

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3642474698

From angorya at openjdk.org  Thu Dec 11 15:34:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Dec 2025 15:34:45 GMT
Subject: RFR: 8373193: RichTextArea: exceptions specifying position beyond
 the document end
In-Reply-To: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>
References: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>
Message-ID: <RDlWK1Sl0TJ-wuYTbeRn8q2_V4504rFudUl6JTKqFNs=.b35a483b-aba1-4a6e-a19e-0ba5d1cecb72@github.com>

On Mon, 8 Dec 2025 20:38:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Tying loose ends: clamping start/end positions in the `StyledTextModel` mutation operations to avoid problems down the road.

many thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/2001#issuecomment-3642475392

From angorya at openjdk.org  Thu Dec 11 15:34:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Dec 2025 15:34:45 GMT
Subject: Integrated: 8373193: RichTextArea: exceptions specifying position
 beyond the document end
In-Reply-To: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>
References: <jEIKNSc5mEKSjn0_jjp9DmarIoUvY4Ddd9_U8MmNMtg=.5d1fb514-7784-4f9e-b47b-84a1921dc7fc@github.com>
Message-ID: <i2n0p22zoMTE2NIuG7RXWDQVhKwarXl0xts3MlKwvBI=.0b3c4fac-16ec-4441-a79d-42367d0ae21d@github.com>

On Mon, 8 Dec 2025 20:38:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Tying loose ends: clamping start/end positions in the `StyledTextModel` mutation operations to avoid problems down the road.

This pull request has now been integrated.

Changeset: 32e667df
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/32e667dfca9c5e9a19cb20f0bdd0553ca1ff765f
Stats:     20 lines in 2 files changed: 17 ins; 0 del; 3 mod

8373193: RichTextArea: exceptions specifying position beyond the document end

Reviewed-by: lkostyra

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

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

From zelmidaoui at openjdk.org  Thu Dec 11 15:40:15 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Dec 2025 15:40:15 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <w9hVl11t7Tb3DDBCqRHvwlb7ILFcpUQCXEUzN-4F-BQ=.6d88966c-322f-40cd-9ff3-ebd3e0651fb1@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <w9hVl11t7Tb3DDBCqRHvwlb7ILFcpUQCXEUzN-4F-BQ=.6d88966c-322f-40cd-9ff3-ebd3e0651fb1@github.com>
Message-ID: <61zSIA7IhBfjRIlftbcZQWhtRNlNf__rvn-SFMNIeJs=.11aaad1d-92fe-4d37-9a55-d105798a9924@github.com>

On Wed, 3 Dec 2025 23:24:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Another thing you might want to check is whether the LayoutInfo and related APIs (caretShape, etc) report correct information.

There is another bug for this issue [JDK-8319050](https://bugs.openjdk.org/browse/JDK-8319050) which I'm still working on

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3642507435

From angorya at openjdk.org  Fri Dec 12 00:08:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Dec 2025 00:08:24 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: <AI9gV0TfckWpK8uWNvY8thyE-Xj5x09dWckyywUw3c4=.e60d89ce-7d77-4c0c-b9a5-5b4c60d9ba0f@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...

So far looks very good.  I'll continue testing tomorrow.

FYI:
I've added new options to the Popup/Stage pages in the standalone Monkey Tester on a separate branch:

https://github.com/andy-goryachev-oracle/MonkeyTest/tree/window.relocation

modules/javafx.graphics/src/main/java/javafx/stage/AnchorPolicy.java line 52:

> 50:      * is biased towards the edge that is closer to the anchor.
> 51:      */
> 52:     FIXED,

should we mention that this one corresponds to the default behavior?

modules/javafx.graphics/src/main/java/javafx/stage/AnchorPolicy.java line 90:

> 88:      * If this is not possible, the window is biased towards the edge that is closer to the anchor.
> 89:      */
> 90:     AUTO

Is there a need for something like NONE, where the dev wants to force a particular behavior regardless of the constraints, even if the popup spans the screens?
(I don't suppose we do, but wanted to ask)

modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 645:

> 643:      * horizontally or vertically, or an anchor location may be selected automatically.
> 644:      * <p>
> 645:      * If no alternative anchor location yields a better placement, the specified {@code anchorLocation} is used.

what happens when the policy is set to `null`?

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

PR Review: https://git.openjdk.org/jfx/pull/1986#pullrequestreview-3568254143
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2611224413
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2611229483
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2611919699

From jdv at openjdk.org  Fri Dec 12 08:27:05 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 12 Dec 2025 08:27:05 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D metal
 textures
Message-ID: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>

Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.

Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.

We don't update the filters/addressing modes for 3D textures once created.
We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.

Functional and performance testing is green with this update.

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

Commit messages:
 - revert default MTL
 - force MTL
 - Use set device parameters for 3D call
 - 8373232: Set default filters for 3D metal textures

Changes: https://git.openjdk.org/jfx/pull/2005/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2005&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373232
  Stats: 83 lines in 7 files changed: 73 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/2005.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2005/head:pull/2005

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

From jdv at openjdk.org  Fri Dec 12 08:27:06 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 12 Dec 2025 08:27:06 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures
In-Reply-To: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
Message-ID: <t27IqVBzVk8kEzNAc3RHZn9UumdNI9VVxn6Mb0Ig-0k=.d3f68273-ceb5-4640-adbe-bb23ac835f7f@github.com>

On Fri, 12 Dec 2025 08:18:14 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
> 
> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
> 
> We don't update the filters/addressing modes for 3D textures once created.
> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
> 
> Functional and performance testing is green with this update.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 85:

> 83:             hTexture = mtlTex.getNativeHandle();
> 84:         }
> 85:         context.setMap(nativeHandle, map.getType().ordinal(), hTexture, useMipmap);

We use mipmapping only when `(!PlatformUtil.isEmbedded()) && (i == PhongMaterial.DIFFUSE || i == PhongMaterial.SELF_ILLUM);`. We need to pass mipmap information, so that we can pick appropriate sampler state in native code.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2005#discussion_r2613347288

From lkostyra at openjdk.org  Fri Dec 12 13:58:41 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 12 Dec 2025 13:58:41 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures
In-Reply-To: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
Message-ID: <bSwjvZ820yaKycDfm4y0QvU5FsQBQo_e8bPA0zZje74=.9301cb6a-5de2-418b-9f2a-2c676d8bd0cb@github.com>

On Fri, 12 Dec 2025 08:18:14 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
> 
> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
> 
> We don't update the filters/addressing modes for 3D textures once created.
> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
> 
> Functional and performance testing is green with this update.

In general looks good, but I have one question to double-check something I couldn't find.

The sampler is chosen based on whether we use mipmaps or not. In cases where mipmaps are not used, are we still generating them?

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

PR Review: https://git.openjdk.org/jfx/pull/2005#pullrequestreview-3571922911

From angorya at openjdk.org  Fri Dec 12 17:02:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Dec 2025 17:02:12 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: <TisKZ1-WqeZ7nN54oPD4tFLgu3r8NIsD3a14ZWOAZco=.39a7085b-301e-446b-83c8-705665c1e3de@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...

Looks good!

I wonder if it would make sense to create an exhaustive test for all possible combinations of parameters in relocation policy.  For example, the test cases can be generated programmatically, the combination and the outcome can be captured to a CSV file to be used as a source file for the actual unit test.
Just a suggestion, I think the current tests are probably sufficient.

modules/javafx.graphics/src/main/java/javafx/geometry/AnchorPoint.java line 112:

> 110:     private final boolean proportional;
> 111: 
> 112:     private AnchorPoint(double x, double y, boolean proportional) {

Do we want to specify what happens when numerical values are NaN?
I suppose the infinities are ok, since they will be clamped accordingly.

modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 651:

> 649:      */
> 650:     private final ObjectProperty<AnchorPolicy> anchorPolicy =
> 651:             new SimpleObjectProperty<>(this, "anchorPolicy", AnchorPolicy.FIXED);

perhaps this property should be lazily created?

(I wish Java would have added the `lazy` keyword:

private final lazy ObProp anchorPolicy = new SimObProp(...);

)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1986#pullrequestreview-3572674421
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2614867822
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2614908060

From angorya at openjdk.org  Fri Dec 12 18:50:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Dec 2025 18:50:09 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode [v2]
In-Reply-To: <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
Message-ID: <9UEBpcAwA5CK3ta9N717NzggZJU3V1vzm1NmXHuINg0=.4a41f54d-5c2d-4b7a-9449-ce61e0b9a385@github.com>

On Thu, 11 Dec 2025 15:32:58 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
>> Tested with monkeyTester and the test in the bug
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed incorrect layout when resizing

Excellent work, @Ziad-Mid !

Tested with the reproducer TextFlow_ExtraSpace_8330559 as well as the monkey tester, on macOS 26.1 (there are no platform-specific changes).  I think one reviewer is sufficient.

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 1401:

> 1399:             float contentWidth = bounds.getWidth();
> 1400:             if (isMirrored()) {
> 1401:                 float runWidth = 0;

I checked if it makes sense to cache runWidth in the PrismTextLine - it does not, so this implementation is ok.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1995#pullrequestreview-3573138216
PR Review Comment: https://git.openjdk.org/jfx/pull/1995#discussion_r2615224868

From zelmidaoui at openjdk.org  Fri Dec 12 20:14:06 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 12 Dec 2025 20:14:06 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode [v2]
In-Reply-To: <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
Message-ID: <QizjDb5yhf2oAYhYntl9sIbfWoA9_2RzVGvqIKMU3TQ=.625e5242-13c4-41ee-8c9d-cfe799c57471@github.com>

On Thu, 11 Dec 2025 15:32:58 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
>> Tested with monkeyTester and the test in the bug
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed incorrect layout when resizing

Thank you for review Andy.
I guess we should merge this PR too https://github.com/openjdk/jfx/pull/1988

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3647989873

From angorya at openjdk.org  Fri Dec 12 20:21:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Dec 2025 20:21:11 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode [v2]
In-Reply-To: <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
Message-ID: <5cFwoIyQ9JEDqPmSAY2Rs_bQpKeihG6EOAirgt_MdwI=.97b2e2e6-fdb2-47cc-8de3-8963002c0e78@github.com>

On Thu, 11 Dec 2025 15:32:58 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
>> Tested with monkeyTester and the test in the bug
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed incorrect layout when resizing

you could merge, but then it will complain about unrelated changes.

since the two are independent, you can integrate this first, once this PR is integrated, you can simply sync up #1988 with the master branch.

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3648012813

From zelmidaoui at openjdk.org  Sat Dec 13 03:30:09 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Sat, 13 Dec 2025 03:30:09 GMT
Subject: RFR: 8318095: TextArea/TextFlow: wrong layout in RTL mode [v2]
In-Reply-To: <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
 <ihJbOnEFzm84aWFoVZ719Hq38hjwPUYrHUDk1nOOPF0=.1add7602-11bd-4b28-9589-21321b49d3a4@github.com>
Message-ID: <GR49ALkch98tJKV5XENK6lvvOevOmof61l7lJtFFKPE=.e44489ec-e8ee-4b06-96e5-3c3b35d2641f@github.com>

On Thu, 11 Dec 2025 15:32:58 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
>> Tested with monkeyTester and the test in the bug
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed incorrect layout when resizing

Thank you for reviewing !

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

PR Comment: https://git.openjdk.org/jfx/pull/1995#issuecomment-3648854317

From zelmidaoui at openjdk.org  Sat Dec 13 03:30:10 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Sat, 13 Dec 2025 03:30:10 GMT
Subject: Integrated: 8318095: TextArea/TextFlow: wrong layout in RTL mode
In-Reply-To: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
References: <mW6G9HibrrvXlASkWjrbmUmlOmzQYAs2YaL6jbXTTnI=.c8b1d8e9-d4fb-4df2-af21-273c42a8417c@github.com>
Message-ID: <3ZDkVe_PJiqpEMLDRlB_OL2zL29kbm5YPPm2P4hmB_c=.0170c5c6-ec18-4453-b476-f227412e2d0f@github.com>

On Wed, 3 Dec 2025 13:33:31 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed issue with TextArea/TextFlow added a check `isMirrored()` in `PrismTextLayout.setWrapWidth` which makes the text right aligned in RTL.
> Tested with monkeyTester and the test in the bug

This pull request has now been integrated.

Changeset: 8e49ea4a
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/8e49ea4af53376583e3cb9ce4288caa3f275ab93
Stats:     14 lines in 1 file changed: 12 ins; 0 del; 2 mod

8318095: TextArea/TextFlow: wrong layout in RTL mode

Reviewed-by: angorya

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

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

From mstrauss at openjdk.org  Sat Dec 13 04:31:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 13 Dec 2025 04:31:05 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v2]
In-Reply-To: <TlKuzy70qOY8mEy1bpzofyCRPvZRnReSGvAWRVfqLVI=.d2113d98-b6c0-42b0-bc56-34ccafe60a29@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <TlKuzy70qOY8mEy1bpzofyCRPvZRnReSGvAWRVfqLVI=.d2113d98-b6c0-42b0-bc56-34ccafe60a29@github.com>
Message-ID: <WPBGRqUxT5rKV-kHS4EsjBc0mOqWVXGqlgTchwSO82k=.844dadae-e353-4475-ac65-898d6bc372db@github.com>

On Wed, 3 Dec 2025 00:48:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
>> 
>> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
>> 
>> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
>> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
>> 
>> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
>> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
>> 
>> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

With this fix applied, the problem described in [JDK-8285983](https://bugs.openjdk.org/browse/JDK-8285983) disappears and the reported position and size of a full-screen window is as a sane person would expect it to be (position = 0,0 and size = visual bounds of the screen).

I suggest we re-open the bug (which was closed as "not an issue") and add it to this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1982#issuecomment-3648909539

From mfox at openjdk.org  Sat Dec 13 22:15:06 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 13 Dec 2025 22:15:06 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v2]
In-Reply-To: <TlKuzy70qOY8mEy1bpzofyCRPvZRnReSGvAWRVfqLVI=.d2113d98-b6c0-42b0-bc56-34ccafe60a29@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <TlKuzy70qOY8mEy1bpzofyCRPvZRnReSGvAWRVfqLVI=.d2113d98-b6c0-42b0-bc56-34ccafe60a29@github.com>
Message-ID: <8FtTIkZ5Rphl1KtT5m-jjoxEugpvyUraz6V2S3fvmQg=.99ca0b20-898c-4b76-80df-d19bb9874afb@github.com>

On Wed, 3 Dec 2025 00:48:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
>> 
>> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
>> 
>> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
>> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
>> 
>> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
>> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
>> 
>> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

The existing changes look fine. GitHub doesn't allow me to comment on unchanged code so I'll just have to write up my comments here.

In GlassView.cpp the `_getX` and `_getY` routines return the location of the scene relative to the upper-left corner of the window. I believe these offsets should be relative to the extended frame bounds instead of GetWindowRect.

In GlassWindow.cpp there's a call to the Java routine `notifyMoving` (which lives in WinWindow.java). At that call site the x and y coordinates are based on GetWindowRect and the anchor is relative to GetWindowRect but the insets are relative to the extended frame bounds. `notifyMoving` is also called from the `setBounds` routine in WinWindow.java. In that case I believe it's being called with the coordinates of the extended frame bounds, an anchor relative to GetWindowRect, and insets relative to the extended frame bounds. I think this all needs further review.

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

Changes requested by mfox (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1982#pullrequestreview-3574587958

From jhendrikx at openjdk.org  Sun Dec 14 11:37:11 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 14 Dec 2025 11:37:11 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
Message-ID: <scQorNXFglc3SrDv6CpwqS2CIy-tjEWMK1PTDBp-9IQ=.af3459e6-e867-4a8e-8e87-96306b1efc6d@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

> First of all, I would like to thank you John for looking into the layout problems. We've got these long standing issues that are very difficult to debug and fix.
> 
> I think this is valuable work as it definitely improves the platform, so Danke sch?n.
> 
> The reason I asked about tests and test scenarios is the possibility of regression. Case in point - with this PR, on macOS with an external monitor at scale=1:
> 
> <img alt="Image" width="1184" height="340" src="https://private-user-images.githubusercontent.com/107069028/506202288-f55f0c01-c59a-49b5-8fc6-91470524eb9a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjU2NTgxODQsIm5iZiI6MTc2NTY1Nzg4NCwicGF0aCI6Ii8xMDcwNjkwMjgvNTA2MjAyMjg4LWY1NWYwYzAxLWM1OWEtNDliNS04ZmM2LTkxNDcwNTI0ZWI5YS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMjEzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTIxM1QyMDMxMjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zZTcyM2IzNDU2MTMzYzJmYTk4OTEwNDRjNGU0ODZmNTQ1YjZkZjk5MDc3NWJiNWFlZWQ5MDQ3YzUzZjZiMmIxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.be1JMTnxYZCqdktvyRJndSqj_PtKX5Hl2_e71hPRK4I">
> I would second @johanvos in suggesting that the regression is what we should be guarding against, and perhaps expanding the tests.

@andy-goryachev-oracle 

I've had access to a Mac for a bit, and I attached my 4K screen to it and set it to full resolution (which makes it scale=1).

What I found is that MonkeyTester indeed shows the bug with this change.  However, I am now convinced that it is more of a coincidence, as I can reproduce the bug also without this change.  In other words, there is a bug, and this one change just happens to make it more obvious in the MonkeyTester case.

What it looks like is that the render scale is not set correctly for a short time, causing calculations (and roundings) to be done with the wrong render scale. I created a small sample with an HBox and 3 labels (as I've already narrowed it down to labels; it is not the MenuBar, it is not the MenuButtons, it is not Buttons, it's Labels).  What happens is the following timeline:

- RenderScaleX = 1.0 (default value I guess)
- RenderScaleX becomes 2.0 (perhaps that's the built-in screen render scale)
- Three labels get asked their horizontal sizes; they round these results to multiples of 0.5 ->  (19.0, 43.5, 117.5)
- These sizes are used by HBox to set its width (it becomes 231.0 pixels label widths + padding 3x 17.0)
- The layout pass finishes and the three labels are laid out (they get the horizontal sizes 19.0, 43.5, 117.5) **correct**
- RenderScaleX becomes 1.0
- The labels get asked their sizes; this time they round these to multiples of 1.0
- The HBox is **not** adjusted
- The labels are laid out again, but they get sizes that are slightly too small: 17.0, 43.0, 117.0 **incorrect**

The conclusion here is that this is entirely expected as HBox is not being size adjusted the 2nd time, and so has to render 3 labels with slightly too little space. The result is that all 3 labels get an ellipsis.

This same thing happens for the MenuBar (it is basically a HBox with Buttons in it which are primarily labels).

So questions to ask:

- Why is render scale being adjusted twice?
- Why are layout calculations being done when render scale is not yet final?
- Why isn't all layout invalidated after a render scale change so HBox's size gets recalculated?

Things that are likely unrelated:
- The target monitor render scale is likely not relevant, it can occur with any other render scale, if there is a difference between primary screen and the target monitor; it just happens to show up much easier when going from scale=2 to scale=1 due to larger calculations differences that are not "absorbed" by snapping of the values.
- The MenuBar, Labels, Buttons, HBox; they all seem to be doing what they should be doing
  - I did notice that LabeledSkinBase is not snapping values of its text size calculations and is mixing snapped and unsnapped values (similar to https://bugs.openjdk.org/browse/JDK-8370652 ) but that's not the primary cause of the problem; I was worried that on Mac the text size calculations may have been "unstable" (until they're rendered on screen) but they return the exact same values both before and after the render scale changes.

The answers are likely to be found in how `sizeToScene` does things...

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3650745910

From jhendrikx at openjdk.org  Sun Dec 14 14:04:19 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 14 Dec 2025 14:04:19 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
Message-ID: <IQzcOn7MOKQOsMg6TYC33F_t7mUOdcDvPVTkn9QMdYI=.a7f1e8fa-063d-4b5d-b808-f058cb8d14ac@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

Update on previous reply:

I did some more investigation into how Scenes are sized.  In Window there is a huge invalidation listener when its showing state is invalidated.  It sets up the bounds and render scale of its peer, does an initial sizing of the scene, etcetera.

Now, the order of operations here is causing a slight issue.  Basically what happen is:
- Window is created but not visible
- Default location is somewhere on a scale=2 screen (even though the X value is already set on the Stage to be on a different screen)
- Window is shown, triggering the invalidation listener
- The render scale (still 2.0) is set on the peer
- For new windows, a "sizeToScene" type code is called on the Scene
  - This does layout calculations with render scale=2
- The invalidation listener then proceeds to adjust the size and position of the Window peer
  - This calls `applyBounds` which discovers the peer is on an entirely different screen, triggering a render scale change to 1.0
  - The render scale change doesn't trigger much of anything
- The invalidation listener (still the same callback) continues and calls `applyBounds` again
- It exits without doing anything further (scene is not resized again)

So to summarize:
- Scene is sized **before** it is moved to the correct location (which may be a different screen)
- Only after it is sized, it is discovered a different render scale should be in effect
- No action is taken to adjust the scene size, scene stays sized incorrectly

Quick fix I found:
- Call `applyBounds` before setting the renderscale on the peer or sizing the scene
  - The problem is now gone **AND** for an outside observer on RenderScale property it never changes from 1.0 -> 2.0 -> 1.0

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3651100681

From mstrauss at openjdk.org  Sun Dec 14 18:57:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 14 Dec 2025 18:57:50 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - resolve merge conflicts
 - Merge branch 'master' into feature/media-features-viewport-characteristics
   
   # Conflicts:
   #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
 - update cssref.html
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - whitespace, add final modifier
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Refactor context awareness
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

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

Changes: https://git.openjdk.org/jfx/pull/1844/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=09
  Stats: 2501 lines in 38 files changed: 1981 ins; 198 del; 322 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From jdv at openjdk.org  Mon Dec 15 04:34:36 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 15 Dec 2025 04:34:36 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures
In-Reply-To: <bSwjvZ820yaKycDfm4y0QvU5FsQBQo_e8bPA0zZje74=.9301cb6a-5de2-418b-9f2a-2c676d8bd0cb@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
 <bSwjvZ820yaKycDfm4y0QvU5FsQBQo_e8bPA0zZje74=.9301cb6a-5de2-418b-9f2a-2c676d8bd0cb@github.com>
Message-ID: <YrPNnix0pwFl1iTEXIQcR4eAT-00Js5fNCsom_FXDC0=.d040928b-a2ec-4887-bb82-3754278387ec@github.com>

On Fri, 12 Dec 2025 13:56:31 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> In general looks good, but I have one question to double-check something I couldn't find.
> 
> The sampler is chosen based on whether we use mipmaps or not. In cases where mipmaps are not used, are we still generating them?

@lukostyra Thanks for the review.
We use mipmap only for diffuse and self illumination maps : https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java#L100

We pass this mipmap flag to the native code when texture is getting created. And we use this flag and generate mipmaps only for the textures where this flag is true : https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m#L203

So for non-mipmapped 3D textures we don't generate mipmaps.

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

PR Comment: https://git.openjdk.org/jfx/pull/2005#issuecomment-3652836820

From mstrauss at openjdk.org  Mon Dec 15 06:18:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 15 Dec 2025 06:18:46 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
Message-ID: <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>

> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
> 
> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
> 
> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
> 
> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
> 
> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).

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

  handle edge cases

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1982/files
  - new: https://git.openjdk.org/jfx/pull/1982/files/defe0df7..f7232ce8

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

  Stats: 228 lines in 5 files changed: 204 ins; 17 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1982.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1982/head:pull/1982

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

From mstrauss at openjdk.org  Mon Dec 15 06:24:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 15 Dec 2025 06:24:11 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
Message-ID: <MkHUeS2QKJz6cmhyXoK5epUmEYiZ83YA3261NHHMjRI=.03da08dd-68e7-49c9-9c0c-b934baa93b99@github.com>

On Mon, 15 Dec 2025 06:18:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
>> 
>> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
>> 
>> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
>> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
>> 
>> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
>> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
>> 
>> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle edge cases

I've looked at every call to `GetWindowRect` and, where appropriate, replaced it with `GetExtendedFrameBounds`.
In addition to that, I also tested the case when JavaFX is running in a DPI-unaware process. I've added code that detects this situation and applies the correct mapping from physical coordinates into virtualized coordinates.

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

PR Comment: https://git.openjdk.org/jfx/pull/1982#issuecomment-3653583473

From zelmidaoui at openjdk.org  Mon Dec 15 11:53:22 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 15 Dec 2025 11:53:22 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode [v2]
In-Reply-To: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
Message-ID: <EU9F-fwsv8-FTyrZeZYvXwtP-MjtO0Z66JrQtPcSs7I=.6f75203f-1d41-4be4-a17e-0fb53e2accf1@github.com>

> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
> Added case to handle complex text in `getPosX` of `TextRun`
> Tested the changes with the code present in the bug.

Ziad El Midaoui 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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8319050.TextFlowRTL
 - Merge branch 'openjdk:master' into 8319050.TextFlowRTL
 - minor changes
 - Fix Trailing space in TextFlow in RTL

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1988/files
  - new: https://git.openjdk.org/jfx/pull/1988/files/1c49122c..b410db37

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

  Stats: 1448 lines in 35 files changed: 1184 ins; 158 del; 106 mod
  Patch: https://git.openjdk.org/jfx/pull/1988.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1988/head:pull/1988

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

From zelmidaoui at openjdk.org  Mon Dec 15 11:53:23 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 15 Dec 2025 11:53:23 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode
In-Reply-To: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
Message-ID: <mbMEas9pcNcfjwOsL43Ou71T0_bndtvvSOJZMOzSiQA=.e9856e71-82ec-4e6f-8dd9-f2a04c572254@github.com>

On Wed, 26 Nov 2025 15:25:44 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
> Added case to handle complex text in `getPosX` of `TextRun`
> Tested the changes with the code present in the bug.

Could you please re-review this PR

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

PR Comment: https://git.openjdk.org/jfx/pull/1988#issuecomment-3655209401

From jhendrikx at openjdk.org  Mon Dec 15 15:29:27 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 15 Dec 2025 15:29:27 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized
Message-ID: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>

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).

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

Commit messages:
 - Fix ellipsis shown on Labels when primary/target screen differ in scale

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

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

From angorya at openjdk.org  Mon Dec 15 17:25:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 17:25:08 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode [v2]
In-Reply-To: <EU9F-fwsv8-FTyrZeZYvXwtP-MjtO0Z66JrQtPcSs7I=.6f75203f-1d41-4be4-a17e-0fb53e2accf1@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
 <EU9F-fwsv8-FTyrZeZYvXwtP-MjtO0Z66JrQtPcSs7I=.6f75203f-1d41-4be4-a17e-0fb53e2accf1@github.com>
Message-ID: <xaSRJUyj7eAzvjQPdmPc_xIl-nLdJs7YzVOu-zTWkPs=.14cb27e4-793f-49f7-87b5-866287b5f1a6@github.com>

On Mon, 15 Dec 2025 11:53:22 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
>> Added case to handle complex text in `getPosX` of `TextRun`
>> Tested the changes with the code present in the bug.
>
> Ziad El Midaoui 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8319050.TextFlowRTL
>  - Merge branch 'openjdk:master' into 8319050.TextFlowRTL
>  - minor changes
>  - Fix Trailing space in TextFlow in RTL

The fix looks good.

Regarding the unit test(s): we can't really create one using stub text layout, it must be using the real one (in a headful environment).

The problem there is that we'd rely on LayoutInfo which is currently broken (see https://bugs.openjdk.org/browse/JDK-8319050 ).  I suggest we develop a set of tests as a part of or as a follow-up to that ticket.

The manual tests using the reproducer and the monkey tester are ok.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1988#pullrequestreview-3579343881

From angorya at openjdk.org  Mon Dec 15 18:56:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 18:56:41 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized
In-Reply-To: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
Message-ID: <sUo_xP8bpiUNPqkW5_jJLBHw_grrAfvUQoUBIllI9KE=.18a083a1-b1a2-4795-b3f7-1821b3a07833@github.com>

On Mon, 15 Dec 2025 15:23:27 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).

This fix introduces another issue in the monkey tester, breaking the layout (see the screenshot below).  The failure can be seen when the MT window appears on the primary (scale=2) as well as on the secondary (scale=1) monitor, running macOS 26.1.  

The layout gets fixed when the user resizes the window.

Interestingly, moving the window to another screen with a different scale **does not** fixes the issue.

<img width="1380" height="623" alt="Screenshot 2025-12-15 at 10 47 46" src="https://github.com/user-attachments/assets/0af65495-7e28-428d-9001-a94c68917833" />

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

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

From angorya at openjdk.org  Mon Dec 15 19:02:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 19:02:56 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <IQzcOn7MOKQOsMg6TYC33F_t7mUOdcDvPVTkn9QMdYI=.a7f1e8fa-063d-4b5d-b808-f058cb8d14ac@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
 <IQzcOn7MOKQOsMg6TYC33F_t7mUOdcDvPVTkn9QMdYI=.a7f1e8fa-063d-4b5d-b808-f058cb8d14ac@github.com>
Message-ID: <ra2LmcZW-apEqP7ybZtt2brbh7ulmWxVbwC97n0E2JI=.a768487d-632a-40da-a8c5-283da4771405@github.com>

On Sun, 14 Dec 2025 14:01:20 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> * Call `applyBounds` before setting the renderscale on the peer or sizing the scene

fixes the issue with the menu, but creates a different failure in layout, see https://github.com/openjdk/jfx/pull/2007#issuecomment-3657112663

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3657134694

From angorya at openjdk.org  Mon Dec 15 21:00:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 21:00:10 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
Message-ID: <po2wJ5mCYjbVEwYW-eytV-8PYKVCumQGv6Ay4RItOmI=.81fb5820-b784-4ef7-882c-62baa8ba5bbc@github.com>

On Sun, 14 Dec 2025 18:57:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - update cssref.html
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - whitespace, add final modifier
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Refactor context awareness
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

A CSS example (either in the ticket or the PR) would be nice, for ease of reviewing.

Here, I am trying to see if the button background will change when I move the monkey tester window from one monitor to another (one is 1900 px wide, the other is 2560).  I see no change:


    @media (width < 2000) {
        .button {
            -fx-background-color: red;
        }
    }


What am I doing wrong?

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3657576232

From mstrauss at openjdk.org  Mon Dec 15 21:04:51 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 15 Dec 2025 21:04:51 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <po2wJ5mCYjbVEwYW-eytV-8PYKVCumQGv6Ay4RItOmI=.81fb5820-b784-4ef7-882c-62baa8ba5bbc@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <po2wJ5mCYjbVEwYW-eytV-8PYKVCumQGv6Ay4RItOmI=.81fb5820-b784-4ef7-882c-62baa8ba5bbc@github.com>
Message-ID: <FTbgB4JPC06Nesy6qP0pFhCxOvu92iUM6MXwbMnBv7g=.1911cd64-944f-4809-8abc-f1dcb8525534@github.com>

On Mon, 15 Dec 2025 20:57:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> What am I doing wrong?

All of the new media features query the scene, not the screen. If you resize the window, you should see the background color change.

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3657591656

From mstrauss at openjdk.org  Mon Dec 15 21:15:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 15 Dec 2025 21:15:22 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <po2wJ5mCYjbVEwYW-eytV-8PYKVCumQGv6Ay4RItOmI=.81fb5820-b784-4ef7-882c-62baa8ba5bbc@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <po2wJ5mCYjbVEwYW-eytV-8PYKVCumQGv6Ay4RItOmI=.81fb5820-b784-4ef7-882c-62baa8ba5bbc@github.com>
Message-ID: <RqGtALROGCUC3e9uUIj1Fdkb5TCzMi0TcdmtD5NDHco=.9c4f58ff-3d2c-47bc-9713-f2e8a29d9026@github.com>

On Mon, 15 Dec 2025 20:57:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A CSS example (either in the ticket or the PR) would be nice, for ease of reviewing.

Added an example to the description of this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3657627758

From angorya at openjdk.org  Mon Dec 15 21:18:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 21:18:16 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
Message-ID: <uNNI5xTNYIyNsjQ2a2530SiitMMb_01_dx2V5nVHMVk=.9a74d900-d695-43bd-81e2-ff1666f378a6@github.com>

On Sun, 14 Dec 2025 18:57:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - update cssref.html
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - whitespace, add final modifier
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Refactor context awareness
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

Having both `aspect-ratio` and `orientation` is a bit redundant, isn't it?  Is it just for convenience?

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3657639924

From mstrauss at openjdk.org  Mon Dec 15 21:29:13 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 15 Dec 2025 21:29:13 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <uNNI5xTNYIyNsjQ2a2530SiitMMb_01_dx2V5nVHMVk=.9a74d900-d695-43bd-81e2-ff1666f378a6@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <uNNI5xTNYIyNsjQ2a2530SiitMMb_01_dx2V5nVHMVk=.9a74d900-d695-43bd-81e2-ff1666f378a6@github.com>
Message-ID: <L-cL0qnIB6qZgA8wtxSVNOwsE0g8Jd2HQIv8tGmAwtQ=.055f2487-0370-4c92-bef2-d33b4cce241b@github.com>

On Mon, 15 Dec 2025 21:15:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Having both `aspect-ratio` and `orientation` is a bit redundant, isn't it? Is it just for convenience?

It almost seems like there could be historical reasons, like one preceded the other or something like that. But as far as I can see, both media features appear at the [same time](https://www.w3.org/TR/2008/WD-css3-mediaqueries-20081015/) around 2008, and they've been around ever since. So I guess it's mostly convenience.

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3657678021

From angorya at openjdk.org  Mon Dec 15 21:36:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 21:36:11 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
Message-ID: <-8n4bBYxirWCMwihMET1WcaIDwqXu8cHb04ISoB5KAM=.e88514db-801a-4f23-a631-7bebd3d24a74@github.com>

On Sun, 14 Dec 2025 18:57:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - update cssref.html
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - whitespace, add final modifier
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Refactor context awareness
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

Why do I get stderr output with this:

WARNING: CSS Error parsing '    @media (aspect-ratio > 0.5) {
        .button {
            -fx-background-color: red;
        }
    }
: Invalid value <0.5> for media feature <aspect-ratio> at [1,30]

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3657699151

From angorya at openjdk.org  Mon Dec 15 21:42:38 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 21:42:38 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
Message-ID: <C6xD7xko0BWvt7RVwUFr_Mc3iZJdbQPB2KjbNKZrXaI=.913b8068-b5d8-47c5-9d68-3525c2f96a6e@github.com>

On Sun, 14 Dec 2025 18:57:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - update cssref.html
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - whitespace, add final modifier
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Refactor context awareness
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 969:

> 967:             <tr>
> 968:                 <td class="value">display-mode</td>
> 969:                 <td class="value">fullscreen | standalone</td>

what does "standalone" mean?

also, "fullscreen" applies to a window, but earlier it's mentioned that the media queries apply to Scene.

I don't see the fullscreen styles change when I use the monkey tester Stage page (the one that allows me to set the fullscreen `Stage` bit) with the following CSS:


    @media (display-mode: fullscreen) {
        .button {
            -fx-background-color: red;
        }
    }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2620940697

From angorya at openjdk.org  Mon Dec 15 22:32:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 22:32:21 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
Message-ID: <rgqcQPz99UCQ3UeNkg7iHji3GiQ7nTkIO7_sJm8b77g=.d980855e-cd25-4cb9-840d-67f22951ee2d@github.com>

On Sun, 14 Dec 2025 18:57:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - update cssref.html
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - whitespace, add final modifier
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Refactor context awareness
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaFeatures.java line 229:

> 227:         for (int i = 0; i < lowerCaseText.length(); i++) {
> 228:             if (!Character.isDigit(lowerCaseText.charAt(i))) {
> 229:                 unitIndex = i;

I think this is the place where the parser fails with fractional numbers...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621072700

From angorya at openjdk.org  Mon Dec 15 23:01:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Dec 2025 23:01:22 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
Message-ID: <-utZKfiakGL5uIJmoaqM7LQieCTUep5BtQ-bRPlIA6c=.5f34d5dd-ea19-4ec2-a011-bca3d3e5bdcd@github.com>

On Sun, 14 Dec 2025 18:57:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - update cssref.html
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - whitespace, add final modifier
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Refactor context awareness
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa

Changes requested by angorya (Reviewer).

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaFeatures.java line 250:

> 248:             case "pc" -> SizeUnits.PC;
> 249:             default -> throw new IllegalArgumentException(
> 250:                 String.format("Invalid value <%s> for media feature <%s>", lowerCaseText, featureName));

is this a new code?
could we add a unit test for all the combinations of decimal values (integer, fractional, scientific), with and without the units?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/SizeQueryType.java line 60:

> 58:     }
> 59: 
> 60:     private static final SizeQueryType[] VALUES = values();

is this really needed?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/CssLexer.java line 53:

> 51:     public static final int GREATER = 27;
> 52:     public static final int LESS = 48;
> 53:     public static final int EQUALS = 49;

this **will** cause problems.  could we arrange these by value please (add new after `AT_KEYWORD`)?

modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 70:

> 68:      * Version 8: viewport characteristics media queries
> 69:      */
> 70:     final static int BINARY_CSS_VERSION = 8;

Does this impact backward compatibility with .bss files?
Should it be mentioned in the CSR?

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2776:

> 2774:             boolean widthChanged = w != Scene.this.getWidth();
> 2775:             boolean heightChanged = h != Scene.this.getHeight();
> 2776:             if (widthChanged) Scene.this.setWidth(w);

it might be my personal preference, but I would rather see one statement per line.  use case: stepping through in the debugger.  can we add { }'s please?

modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 675:

> 673:         assertEquals(1, stylesheet.getRules().size());
> 674:         assertEquals(
> 675:             List.of(EqualExpression.of(SizeQueryType.WIDTH, new Size(100, SizeUnits.PX))),

Could we add a test that verifies that the CSS parser accepts fractional decimals?  With or without the units specified?

Also, does it support scientific notation line `1e2` for `100` ?

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

PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3580478763
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621124272
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621103826
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621106888
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621112439
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621116371
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621121423

From almatvee at openjdk.org  Mon Dec 15 23:56:15 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 15 Dec 2025 23:56:15 GMT
Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS
 26
Message-ID: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>

Fixed two crashes:
- `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`.
- `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`.

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

Commit messages:
 - 8373058: Media crash when playing MP3 over JRT protocol on macOS 26

Changes: https://git.openjdk.org/jfx/pull/2008/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373058
  Stats: 102 lines in 3 files changed: 42 ins; 19 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/2008.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2008/head:pull/2008

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

From zelmidaoui at openjdk.org  Tue Dec 16 00:36:08 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 16 Dec 2025 00:36:08 GMT
Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow
 in RTL mode [v2]
In-Reply-To: <EU9F-fwsv8-FTyrZeZYvXwtP-MjtO0Z66JrQtPcSs7I=.6f75203f-1d41-4be4-a17e-0fb53e2accf1@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
 <EU9F-fwsv8-FTyrZeZYvXwtP-MjtO0Z66JrQtPcSs7I=.6f75203f-1d41-4be4-a17e-0fb53e2accf1@github.com>
Message-ID: <MSWFdtAs-wvMkHumP2RokdkenXtLyMf2N1b_Tx2MdVg=.23482475-73d7-4ca6-8b12-635b4448677c@github.com>

On Mon, 15 Dec 2025 11:53:22 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
>> Added case to handle complex text in `getPosX` of `TextRun`
>> Tested the changes with the code present in the bug.
>
> Ziad El Midaoui 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8319050.TextFlowRTL
>  - Merge branch 'openjdk:master' into 8319050.TextFlowRTL
>  - minor changes
>  - Fix Trailing space in TextFlow in RTL

Thank you for reviewing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1988#issuecomment-3658166111

From zelmidaoui at openjdk.org  Tue Dec 16 00:36:09 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 16 Dec 2025 00:36:09 GMT
Subject: Integrated: 8330559: Trailing space not rendering correctly in
 TextFlow in RTL mode
In-Reply-To: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
References: <9YBLOcueh9GZKb25W1ntyDE_sC744To-Ts0CxI201L4=.27113211-ce7b-49ce-8406-6b0c9105406e@github.com>
Message-ID: <jO_HyWnUf4aYM8mVrm_8zs2Tr4i0yxE5CJ2GZOrFQjA=.0b78298b-2b3f-4346-9d3f-db7f849c33c4@github.com>

On Wed, 26 Nov 2025 15:25:44 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fix trailing space present for complex text ( LTR text with RTL text ) Example: "Arabic: ???????"
> Added case to handle complex text in `getPosX` of `TextRun`
> Tested the changes with the code present in the bug.

This pull request has now been integrated.

Changeset: 14305d62
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/14305d623144934f8b9c88e1ddf434ab51902857
Stats:     11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8330559: Trailing space not rendering correctly in TextFlow in RTL mode

Reviewed-by: angorya

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

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

From mstrauss at openjdk.org  Tue Dec 16 01:48:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 01:48:49 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v11]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <ZLZuopSnThJCbvYCh7XBCHpI_WMhNQFRO2wWMUZN_UM=.2b4507c9-8989-4717-8cdf-1f9416057aef@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  separate range-based expressions into number/size variants

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/19cdaeaa..dc22aa43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=09-10

  Stats: 481 lines in 17 files changed: 299 ins; 67 del; 115 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From mstrauss at openjdk.org  Tue Dec 16 01:59:12 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 01:59:12 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <C6xD7xko0BWvt7RVwUFr_Mc3iZJdbQPB2KjbNKZrXaI=.913b8068-b5d8-47c5-9d68-3525c2f96a6e@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <C6xD7xko0BWvt7RVwUFr_Mc3iZJdbQPB2KjbNKZrXaI=.913b8068-b5d8-47c5-9d68-3525c2f96a6e@github.com>
Message-ID: <_Bs10UmpFSHALgY5fL7sBPRVzx1rJtnq647XJGPf_sk=.fb0a9632-1bfb-4457-ad8f-7b462bebc63e@github.com>

On Mon, 15 Dec 2025 21:39:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - resolve merge conflicts
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>>  - update cssref.html
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - whitespace, add final modifier
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Refactor context awareness
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa
>
> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 969:
> 
>> 967:             <tr>
>> 968:                 <td class="value">display-mode</td>
>> 969:                 <td class="value">fullscreen | standalone</td>
> 
> what does "standalone" mean?
> 
> also, "fullscreen" applies to a window, but earlier it's mentioned that the media queries apply to Scene.
> 
> I don't see the fullscreen styles change when I use the monkey tester Stage page (the one that allows me to set the fullscreen `Stage` bit) with the following CSS:
> 
> 
>     @media (display-mode: fullscreen) {
>         .button {
>             -fx-background-color: red;
>         }
>     }

"Standalone" matches when "fullscreen" doesn't match. The relevant part of the [specification](https://www.w3.org/TR/mediaqueries-5/#display-modes) says that it is a window with "[...] standard system UI elements, such as window decorations, a system status bar, and/or a system back button [...]".

"Fullscreen" matches when none of that is available and the scene extends across the entire display, which is the case when the scene is hosted in a full-screen window.

Note that media queries don't change CSS precedence rules. In your example, you could check whether another rule that sets `-fx-background-color` has a higher precedence. You could try adding `!important` to quickly figure out whether the rule has any effect at all.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/SizeQueryType.java line 60:
> 
>> 58:     }
>> 59: 
>> 60:     private static final SizeQueryType[] VALUES = values();
> 
> is this really needed?

It's not strictly needed. If we remove it, then the enum will allocate a new array on every iteration over its `values()`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621478173
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621479522

From mstrauss at openjdk.org  Tue Dec 16 02:03:09 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 02:03:09 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <-utZKfiakGL5uIJmoaqM7LQieCTUep5BtQ-bRPlIA6c=.5f34d5dd-ea19-4ec2-a011-bca3d3e5bdcd@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <-utZKfiakGL5uIJmoaqM7LQieCTUep5BtQ-bRPlIA6c=.5f34d5dd-ea19-4ec2-a011-bca3d3e5bdcd@github.com>
Message-ID: <4unl-yXbT-ZM0Wn0ZQ5fbTJICjSNKF7uHwlXqquRoTA=.6667a1fc-8d86-4932-91c0-d68d990a03a5@github.com>

On Mon, 15 Dec 2025 22:50:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - resolve merge conflicts
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>>  - update cssref.html
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - whitespace, add final modifier
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Refactor context awareness
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa
>
> modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 70:
> 
>> 68:      * Version 8: viewport characteristics media queries
>> 69:      */
>> 70:     final static int BINARY_CSS_VERSION = 8;
> 
> Does this impact backward compatibility with .bss files?
> Should it be mentioned in the CSR?

BSS files are not specified to be backwards-compatible in the sense that an older version of JavaFX can read a newer BSS file. It is mentioned in the CSR, though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621485010

From mstrauss at openjdk.org  Tue Dec 16 02:09:47 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 02:09:47 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v12]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <aCk03R4G6v1VFO1EszrjcJ-vtA0uP1JT61hgsr4GrgA=.0b5fd61c-3c6e-401b-91f2-1de7421bc4a8@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/dc22aa43..98a014f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=10-11

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

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

From mstrauss at openjdk.org  Tue Dec 16 02:09:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 02:09:50 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <rgqcQPz99UCQ3UeNkg7iHji3GiQ7nTkIO7_sJm8b77g=.d980855e-cd25-4cb9-840d-67f22951ee2d@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <rgqcQPz99UCQ3UeNkg7iHji3GiQ7nTkIO7_sJm8b77g=.d980855e-cd25-4cb9-840d-67f22951ee2d@github.com>
Message-ID: <snpqZWOv05mc68ZdWfY041JQIrd4QBRpxlzU0wy1BBY=.b1fea831-9255-4d60-9d99-441cc9cbcab3@github.com>

On Mon, 15 Dec 2025 22:29:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - resolve merge conflicts
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>>  - update cssref.html
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - whitespace, add final modifier
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Refactor context awareness
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaFeatures.java line 229:
> 
>> 227:         for (int i = 0; i < lowerCaseText.length(); i++) {
>> 228:             if (!Character.isDigit(lowerCaseText.charAt(i))) {
>> 229:                 unitIndex = i;
> 
> I think this is the place where the parser fails with fractional numbers...

Yes. It turns out that we need to differentiate `<size>` and `<number>` values, as the latter don't have a unit (and can never have one). I've refactored the code a bit to handle both types of ranges.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621494309

From mstrauss at openjdk.org  Tue Dec 16 02:43:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 02:43:44 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v13]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  use CssParser.size() to parse sizes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/98a014f5..0edf4392

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=11-12

  Stats: 187 lines in 6 files changed: 100 ins; 46 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From mstrauss at openjdk.org  Tue Dec 16 02:47:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 02:47:07 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <-utZKfiakGL5uIJmoaqM7LQieCTUep5BtQ-bRPlIA6c=.5f34d5dd-ea19-4ec2-a011-bca3d3e5bdcd@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <-utZKfiakGL5uIJmoaqM7LQieCTUep5BtQ-bRPlIA6c=.5f34d5dd-ea19-4ec2-a011-bca3d3e5bdcd@github.com>
Message-ID: <IgHTV3AAoqikE23dM2i_aY86I0g1qldTYZXX2WcK2fc=.ab1035a0-46c9-4e8f-9459-949b754e5d6e@github.com>

On Mon, 15 Dec 2025 22:57:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - resolve merge conflicts
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>>  - update cssref.html
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - whitespace, add final modifier
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Refactor context awareness
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/32e667df...19cdaeaa
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaFeatures.java line 250:
> 
>> 248:             case "pc" -> SizeUnits.PC;
>> 249:             default -> throw new IllegalArgumentException(
>> 250:                 String.format("Invalid value <%s> for media feature <%s>", lowerCaseText, featureName));
> 
> is this a new code?
> could we add a unit test for all the combinations of decimal values (integer, fractional, scientific), with and without the units?

I've removed the custom parsing, and instead delegate to `CssParser` to parse sizes. This means we won't have to worry about any of this as part of this PR; whatever `CssParser` is doing right or wrong, media queries will use that.

> modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 675:
> 
>> 673:         assertEquals(1, stylesheet.getRules().size());
>> 674:         assertEquals(
>> 675:             List.of(EqualExpression.of(SizeQueryType.WIDTH, new Size(100, SizeUnits.PX))),
> 
> Could we add a test that verifies that the CSS parser accepts fractional decimals?  With or without the units specified?
> 
> Also, does it support scientific notation line `1e2` for `100` ?

Even though the CSS accepts scientific notation, `CssLexer` apparently does not. This could be a future enhancement.
I've removed all custom code with regards to parsing numbers, and just delegate to `CssParser`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621551123
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2621553367

From jhendrikx at openjdk.org  Tue Dec 16 07:31:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Dec 2025 07:31:03 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v2]
In-Reply-To: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
Message-ID: <I_gNo6aneZke-e2ARMOT4TZKF28XytpjUE0MT00305c=.d91ca1f9-4608-457d-b1dc-abff792cf9ff@github.com>

> 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 one additional commit since the last revision:

  Add debug output

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2007/files
  - new: https://git.openjdk.org/jfx/pull/2007/files/3afd9536..cf9cf570

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

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

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

From jhendrikx at openjdk.org  Tue Dec 16 07:44:53 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Dec 2025 07:44:53 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v3]
In-Reply-To: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
Message-ID: <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>

> 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 one additional commit since the last revision:

  Add more debug output

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2007/files
  - new: https://git.openjdk.org/jfx/pull/2007/files/cf9cf570..dc02573a

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

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

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

From jhendrikx at openjdk.org  Tue Dec 16 08:01:11 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Dec 2025 08:01:11 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized
In-Reply-To: <sUo_xP8bpiUNPqkW5_jJLBHw_grrAfvUQoUBIllI9KE=.18a083a1-b1a2-4795-b3f7-1821b3a07833@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <sUo_xP8bpiUNPqkW5_jJLBHw_grrAfvUQoUBIllI9KE=.18a083a1-b1a2-4795-b3f7-1821b3a07833@github.com>
Message-ID: <mMDCDCp3i9x_aShPVQ5dOgm8Ga84tywfmUIRCtoTVT4=.ba695d3a-99fd-4506-9ad9-3f0711051479@github.com>

On Mon, 15 Dec 2025 18:53:59 GMT, Andy Goryachev <angorya 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).
>
> This fix introduces another issue in the monkey tester, breaking the layout (see the screenshot below).  The failure can be seen when the MT window appears on the primary (scale=2) as well as on the secondary (scale=1) monitor, running macOS 26.1.  
> 
> The layout gets fixed when the user resizes the window.
> 
> Interestingly, moving the window to another screen with a different scale **does not** fixes the issue.
> 
> <img width="1380" height="623" alt="Screenshot 2025-12-15 at 10 47 46" src="https://github.com/user-attachments/assets/0af65495-7e28-428d-9001-a94c68917833" />
> 
> More observations:
> - it does fixes the menu bar issue mentioned in https://github.com/openjdk/jfx/pull/1945#pullrequestreview-3385140013
> - also tested in combination with #1945 , the layout issue is present in the combined version

@andy-goryachev-oracle  Well, this is going a bit beyond what I'm trying to fix.  I don't see any of the issues you're showing, not with test programs, nor with MonkeyTester.  In fact, I saw several positive things after applying this fix (Windows are no longer sized with unused empty space when immediately shown on a different monitor).

As this again seems to be Mac specific, I have very limited means to "fix" this further, so perhaps you could have a look yourself.  I've added some debug output that will be helpful (you can share it here).  Look specifically at what `setBounds` is called with.

MonkeyTester is setting X/Y/width/height of its Window explicitly when it has some settings stored from a previous run.  This means it generally follows a slightly different code path when the window is shown, since all the "explicit" flags for x, y, width and height will be true.  Still, that doesn't explain how you get some unused empty space.

Here's an example of the output on my system, where MonkeyTester is shown on the 1.0 monitor on the right side of a 1.5 monitor:


Window/invalidationListener: shown changed to: true
Window/invalidationListener: screen=javafx.stage.Screen at 21e4df3b bounds:Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1440.0, width=2560.0, height=1440.0] visualBounds:Rectangle2D [minX=0.0, minY=0.0, maxX=2560.0, maxY=1400.0, width=2560.0, height=1400.0] dpi:93.0 outputScale:(1.5,1.5)
Window/peer: setBounds(2698.0, 61.0, true, true, winW:1463.0, 708.0, clientW:-1.0, -1.0, 0.0, 0.0, rsx:0.0, rsy:0.0)
Window/invalidationListener: after applying bounds screen=javafx.stage.Screen at 55e0e86c bounds:Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0, width=1920.0, height=1200.0] visualBounds:Rectangle2D [minX=2560.0, minY=-194.0, maxX=4480.0, maxY=1006.0, width=1920.0, height=1200.0] dpi:94.0 outputScale:(1.0,1.0)
Window/invalidationListener: output scale used before sizing scene: 1.0
Window/invalidationListener: size from scene: 517.0x2646.0
Window/peer: setBounds(2698.0, 61.0, true, true, winW:1471.0, 727.0, clientW:-1.0, -1.0, 0.0, 0.0, rsx:1.0, rsy:1.0)
Window/invalidationListener: exit invalidation listener

What you see above here is that initially the window screen is still the primary screen (at minXY=0,0); after `applyBounds` this changes to the correct screen.  The scene size code is then called with the correct values (render scale 1.0).  The scene size is however a bit weird; it is very wide, probably because there are many controls in your Scene that have a wide preferred width. 
 It's possible this is somehow the cause of that empty space -- still, on my system, those values are unused as MonkeyTester sets its own width/height, which you can see in the final `setBounds` call -- effectively, the scene sizing is ignored, and it should re-layout with the final size.

Come to think of it, the scene size call is basically superfluous; if width/height is explicit, we could skip that completely.

Anyway, let me know what you find.  I'm not seeing any issues with the above outputs, but perhaps something odd pops up on your system that may point us in the right direction.

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

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

From lkostyra at openjdk.org  Tue Dec 16 09:08:14 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 16 Dec 2025 09:08:14 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures
In-Reply-To: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
Message-ID: <SXyk3Eypv0nt1sJfU1X_8ZQia-Bq1AkSE4zuRx_ORNs=.d84ce24e-26c7-4440-bdef-68d31bfc0c47@github.com>

On Fri, 12 Dec 2025 08:18:14 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
> 
> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
> 
> We don't update the filters/addressing modes for 3D textures once created.
> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
> 
> Functional and performance testing is green with this update.

Thanks for responding. I found one thing that could be improved, will run some tests on this later on.

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

> 237: 
> 238: - (void) create3DSamplerStates
> 239: {

I think we could add something here to skip re-creating the sampler descriptors. This can be called every time we switch to 3D (from `nSetDeviceParametersFor3D`) and that way we could optimize this transition a bit.

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

PR Review: https://git.openjdk.org/jfx/pull/2005#pullrequestreview-3582050397
PR Review Comment: https://git.openjdk.org/jfx/pull/2005#discussion_r2622408565

From jose.pereda at gluonhq.com  Tue Dec 16 10:57:57 2025
From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=)
Date: Tue, 16 Dec 2025 11:57:57 +0100
Subject: JavaFX Application Thread as daemon thread on macOS
Message-ID: <CAGMSBrKh5PWSB7rOrPaqYs=s=3WkaNbgzVHa2TjrYeAQ5m13UA@mail.gmail.com>

When running test suites, there are scenarios where each test must wait
until the JavaFX shutdown has fully completed before the next one begins.

Currently, there is no dedicated API to determine when shutdown is
complete. Developers often rely on workarounds, such as sleep times or
inspecting Thread.getAllStackTraces() to verify that no JavaFX threads
remain alive. For instance, this approach was used for
userThreadIsShutdownOnPlatformExitTest in HeadlessApplication2Test
(JDK-8369306):

assertFalse(Thread.getAllStackTraces().keySet().stream().anyMatch(t ->
"JavaFX Application Thread".equals(t.getName())));

Starting with JavaFX 24 (JDK-8339178), the JavaFX Application Thread was
changed from a non-daemon to a daemon thread on macOS. While this may not
impact most use cases, it might affect the testing context described above.
In fact, if userThreadIsShutdownOnPlatformExitTest is run headfully it will
fail on macOS, but work on the other platforms.

What is the recommended approach for this specific use case? Should a
reliable API be introduced to monitor this state?

-- 
Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251216/7cbf5355/attachment.htm>

From jdv at openjdk.org  Tue Dec 16 11:49:31 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 16 Dec 2025 11:49:31 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures [v2]
In-Reply-To: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
Message-ID: <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>

> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
> 
> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
> 
> We don't update the filters/addressing modes for 3D textures once created.
> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
> 
> Functional and performance testing is green with this update.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  create sampler states only once

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2005/files
  - new: https://git.openjdk.org/jfx/pull/2005/files/80fdcc8c..7fb54da4

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

  Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/2005.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2005/head:pull/2005

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

From jdv at openjdk.org  Tue Dec 16 11:49:33 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 16 Dec 2025 11:49:33 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures [v2]
In-Reply-To: <SXyk3Eypv0nt1sJfU1X_8ZQia-Bq1AkSE4zuRx_ORNs=.d84ce24e-26c7-4440-bdef-68d31bfc0c47@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
 <SXyk3Eypv0nt1sJfU1X_8ZQia-Bq1AkSE4zuRx_ORNs=.d84ce24e-26c7-4440-bdef-68d31bfc0c47@github.com>
Message-ID: <xDJGjfGhn5MMvw_zk25t52wqqHNnGtBzC7t8LmNVF9E=.b46ba59d-f4ea-4eda-a58c-eeeed15e99e9@github.com>

On Tue, 16 Dec 2025 09:05:04 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   create sampler states only once
>
> modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 239:
> 
>> 237: 
>> 238: - (void) create3DSamplerStates
>> 239: {
> 
> I think we could add something here to skip re-creating the sampler descriptors. This can be called every time we switch to 3D (from `nSetDeviceParametersFor3D`) and that way we could optimize this transition a bit.

That's a good point.
Actually not just descriptors even the samplers states should be created only once. Updated the code.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2005#discussion_r2622950228

From mhanl at openjdk.org  Tue Dec 16 12:13:16 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 16 Dec 2025 12:13:16 GMT
Subject: RFR: 8333146: Move maven publication logic from build.gradle [v6]
In-Reply-To: <j8jqAT5DTkxuDzqDXFMaS7Htt4qIiHwtjp2WrmORRLM=.3c1496ad-08ca-4f8e-a3f4-a675de5ba00f@github.com>
References: <wf49A9Cv05TOHVrHB13numUo2qfwyrg-UnvUbc1JS6M=.26a864df-3429-43fb-85e9-a9e0b52eb7bc@github.com>
 <Vg6y2XoT0s-zXM6hI3Lcas6VXGhCouWGHHb9DACRSLQ=.a36939a5-8fe7-4309-933e-959336a92e57@github.com>
 <C-fprMy8fhJH4o7kSvcD9w4-E1547ARZcofiKykNzzo=.5d8f67ed-4624-4f37-a17a-d55baddb1232@github.com>
 <CC-SPDELW9jsPu3evQb0V5gZT5czmB5eB_MyQ_zE3d4=.6936067a-2342-4153-ba78-5c6b2f7a4df3@github.com>
 <E9v7qQHpqUY4nldrfwRmh7XGFmc-AqQwlNWCv9mA-64=.040dc771-d5c1-405c-a143-aae8d7b04c2a@github.com>
 <OyzUQexeptHH2a_rVcOEJeyVfXfUbzm-z0htY1OpNcY=.215d5a39-3a12-450a-beff-c93f6bf815f4@github.com>
 <g3fKq_bF0Q89jVGSMz0pcbS4OQqgKbgLYxqf2akiKIM=.4949e12c-0137-472a-b071-915c657ced61@github.com>
 <_IE0eaP3WCTKNcNlP9gC3yJN5OGi0lMmDKOmFD1u_OU=.316308c4-21f6-4c09-9447-b78d416d5ca3@github.com>
 <ie6qFlfd2Cb1P1Jo05owCHOOSFgUICSm8-27QRg42c4=.c5246e37-662d-4559-9ee2-ea685617ef45@github.com>
 <j8jqAT5DTkxuDzqDXFMaS7Htt4qIiHwtjp2WrmORRLM=.3c1496ad-08ca-4f8e-a3f4-a675de5ba00f@github.com>
Message-ID: <cMMumRRhpFfiTj2mU8NIG-dDwOSlSq-OWN0hs_d_ez0=.40efbb18-7a6f-47ec-a06e-7ebffed39701@github.com>

On Mon, 8 Dec 2025 11:47:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> I think you might have it backwards: `all` should depend on the task to build the publications, not the other way around. The goal is that `gradle all` should produce `build/publications`.

Here is an attempt to do that without coupling the build with maven-publish:
https://github.com/Maran23/jfx/commit/d325d9931b37c64641fb9064e5deadbfa5766fe8

This probably needs to be done with `compileTargets` then. But the idea is the same.

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

PR Comment: https://git.openjdk.org/jfx/pull/1970#issuecomment-3660207511

From mhanl at openjdk.org  Tue Dec 16 12:47:39 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 16 Dec 2025 12:47:39 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
Message-ID: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>

This is a small improvement that was noted back in https://github.com/openjdk/jfx/pull/1200#issuecomment-1671954361 by @mstr2, and was on my list since then.

The idea is to have only one place for assigning `adapter ordinals` ? within `Screen`. The corresponding setter `setAdapterOrdinal` can therefore be made private. This improves the separation of responsibilities a little. :-)

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

Commit messages:
 - 8314820: Unify Screen adapter ordinal logic

Changes: https://git.openjdk.org/jfx/pull/2009/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2009&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314820
  Stats: 24 lines in 3 files changed: 9 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/2009.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2009/head:pull/2009

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

From lkostyra at openjdk.org  Tue Dec 16 16:10:33 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 16 Dec 2025 16:10:33 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures [v2]
In-Reply-To: <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
 <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
Message-ID: <oFiipBQe-2AxBWJizYr85lOeJT3ddY26D2VcrPdeHZA=.87a1b9bc-1321-4358-a4d2-11b96eba16c3@github.com>

On Tue, 16 Dec 2025 11:49:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
>> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
>> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
>> 
>> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
>> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
>> 
>> We don't update the filters/addressing modes for 3D textures once created.
>> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
>> 
>> Functional and performance testing is green with this update.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create sampler states only once

LGTM

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2005#pullrequestreview-3583876203

From mfox at openjdk.org  Tue Dec 16 16:13:49 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 16 Dec 2025 16:13:49 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
Message-ID: <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>

On Mon, 15 Dec 2025 06:18:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`.
>> 
>> Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect.
>> 
>> For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges):
>> <img width="300" alt="window-size-1" src="https://github.com/user-attachments/assets/76ea6861-885f-4bea-aeb7-e8e6464b7199" />
>> 
>> What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders:
>> <img width="295" alt="window-size-2" src="https://github.com/user-attachments/assets/ca6bed73-e4e7-4df6-9491-d82792bb0866" />
>> 
>> The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle edge cases

modules/javafx.graphics/src/main/native-glass/win/Utils.cpp line 144:

> 142:                 GetProcAddress(hModule, "SetThreadDpiAwarenessContext"));
> 143: 
> 144:             // Only load GetProcessDpiAwareness if GetThreadDpiAwarenessContext is not available (pre-Win10).

What versions of Windows does JavaFX support? I just spent a half hour searching and couldn't find any statement on this for either JavaFX or the JDK.

As of October of this year the original version of Windows 10 left Microsoft's Long Term Servicing Channel. As of now the earliest version of Windows supported by Microsoft is Win10 2016 (1607), the version where the thread DPI awareness calls were first added. Is JavaFX supporting and testing earlier versions of Windows? If not you should be able to just make direct calls to the thread DPI awareness API's.

This is probably a topic for the mailing list. I'm still surprised I couldn't find this information anywhere.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2623902261

From lkostyra at openjdk.org  Tue Dec 16 16:19:06 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 16 Dec 2025 16:19:06 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures [v2]
In-Reply-To: <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
 <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
Message-ID: <E4A2nXEiRUgKzSuKlTMW7TjSpIToYRUKNzd26UqX4cI=.745fa262-ec0d-4bad-8725-bb38c8d5c5ae@github.com>

On Tue, 16 Dec 2025 11:49:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
>> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
>> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
>> 
>> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
>> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
>> 
>> We don't update the filters/addressing modes for 3D textures once created.
>> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
>> 
>> Functional and performance testing is green with this update.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create sampler states only once

I just noticed the ready label, but I think this requires two reviewers.

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

PR Comment: https://git.openjdk.org/jfx/pull/2005#issuecomment-3661340383

From angorya at openjdk.org  Tue Dec 16 16:30:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 16:30:05 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
In-Reply-To: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
Message-ID: <YDeq8gpP9Ib2xSpBK6CO7_MK2ttmyL2EWFuZ4z8V7jg=.d290f9da-11c3-47b7-b757-6a58d3301db0@github.com>

On Tue, 16 Dec 2025 12:42:05 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This is a small improvement that was noted back in https://github.com/openjdk/jfx/pull/1200#issuecomment-1671954361 by @mstr2, and was on my list since then.
> 
> The idea is to have only one place for assigning `adapter ordinals` ? within `Screen`. The corresponding setter `setAdapterOrdinal` can therefore be made private. This improves the separation of responsibilities a little. :-)

Looks like a minor cleanup, no functional changes whatsoever.

Note: next time, you may want to sync up with the latest master branch before making it RFR.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2009#pullrequestreview-3583960539

From angorya at openjdk.org  Tue Dec 16 16:42:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 16:42:22 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <_Bs10UmpFSHALgY5fL7sBPRVzx1rJtnq647XJGPf_sk=.fb0a9632-1bfb-4457-ad8f-7b462bebc63e@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <C6xD7xko0BWvt7RVwUFr_Mc3iZJdbQPB2KjbNKZrXaI=.913b8068-b5d8-47c5-9d68-3525c2f96a6e@github.com>
 <_Bs10UmpFSHALgY5fL7sBPRVzx1rJtnq647XJGPf_sk=.fb0a9632-1bfb-4457-ad8f-7b462bebc63e@github.com>
Message-ID: <MwHROE5_MACsa3MoeDDa2cTbR6sxUJapXaA4rFiWtT0=.3d45feac-2830-4a7e-a7cf-c82dc38c7fbb@github.com>

On Tue, 16 Dec 2025 01:55:15 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 969:
>> 
>>> 967:             <tr>
>>> 968:                 <td class="value">display-mode</td>
>>> 969:                 <td class="value">fullscreen | standalone</td>
>> 
>> what does "standalone" mean?
>> 
>> also, "fullscreen" applies to a window, but earlier it's mentioned that the media queries apply to Scene.
>> 
>> I don't see the fullscreen styles change when I use the monkey tester Stage page (the one that allows me to set the fullscreen `Stage` bit) with the following CSS:
>> 
>> 
>>     @media (display-mode: fullscreen) {
>>         .button {
>>             -fx-background-color: red;
>>         }
>>     }
>
> "Standalone" matches when "fullscreen" doesn't match. The relevant part of the [specification](https://www.w3.org/TR/mediaqueries-5/#display-modes) says that it is a window with "[...] standard system UI elements, such as window decorations, a system status bar, and/or a system back button [...]".
> 
> "Fullscreen" matches when none of that is available and the scene extends across the entire display, which is the case when the scene is hosted in a full-screen window.
> 
> Note that media queries don't change CSS precedence rules. In your example, you could check whether another rule that sets `-fx-background-color` has a higher precedence. You could try adding `!important` to quickly figure out whether the rule has any effect at all.

What I meant is to explain the meaning in the cssref.html.  We can't really refer to w3.org pages for JavaFX, in my opinion.  So, if you want to keep the standalone term in the values, I think you ought to explain what it is, using JavaFX or platform terminology.

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/SizeQueryType.java line 60:
>> 
>>> 58:     }
>>> 59: 
>>> 60:     private static final SizeQueryType[] VALUES = values();
>> 
>> is this really needed?
>
> It's not strictly needed. If we remove it, then the enum will allocate a new array on every iteration over its `values()`.

unless this code is in hot path, I'd suggest to remove the static.

>> modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 70:
>> 
>>> 68:      * Version 8: viewport characteristics media queries
>>> 69:      */
>>> 70:     final static int BINARY_CSS_VERSION = 8;
>> 
>> Does this impact backward compatibility with .bss files?
>> Should it be mentioned in the CSR?
>
> BSS files are not specified to be backwards-compatible in the sense that an older version of JavaFX can read a newer BSS file. It is mentioned in the CSR, though.

I was expecting it in the description - I could be wrong though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2623983617
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2623987953
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2623995218

From kcr at openjdk.org  Tue Dec 16 16:46:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Dec 2025 16:46:17 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
In-Reply-To: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
Message-ID: <FPuaKeIaj-X84TA3R2rciEJs-0Pv6pn3S-R0Qjm6IbE=.ae9daec0-049c-4ac5-b415-4ed60f44615e@github.com>

On Tue, 16 Dec 2025 12:42:05 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This is a small improvement that was noted back in https://github.com/openjdk/jfx/pull/1200#issuecomment-1671954361 by @mstr2, and was on my list since then.
> 
> The idea is to have only one place for assigning `adapter ordinals` ? within `Screen`. The corresponding setter `setAdapterOrdinal` can therefore be made private. This improves the separation of responsibilities a little. :-)

I want @lukostyra to also take a look at this.

(FWIW, I think this is fine, but since Lukasz is working on the Direct3D 12 pipeline, I wanted his take on it)

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

PR Comment: https://git.openjdk.org/jfx/pull/2009#issuecomment-3661448305
PR Comment: https://git.openjdk.org/jfx/pull/2009#issuecomment-3661454590

From angorya at openjdk.org  Tue Dec 16 16:56:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 16:56:39 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
In-Reply-To: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
Message-ID: <V4iH9RdSwwBc4ke70GlantUEkRPHSGN5-vxvb7YtvP8=.78c8304b-945d-409f-8098-ab28c3b3ed3e@github.com>

On Tue, 16 Dec 2025 12:42:05 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This is a small improvement that was noted back in https://github.com/openjdk/jfx/pull/1200#issuecomment-1671954361 by @mstr2, and was on my list since then.
> 
> The idea is to have only one place for assigning `adapter ordinals` ? within `Screen`. The corresponding setter `setAdapterOrdinal` can therefore be made private. This improves the separation of responsibilities a little. :-)

One thought nagged me during the review: why do we keep the ordinal (an index) when we could, in theory, keep a reference to the object?  Is there a potential for misalignment, perhaps a transient one?

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

PR Comment: https://git.openjdk.org/jfx/pull/2009#issuecomment-3661497743

From angorya at openjdk.org  Tue Dec 16 17:21:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 17:21:06 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v13]
In-Reply-To: <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>
Message-ID: <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>

On Tue, 16 Dec 2025 02:43:44 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use CssParser.size() to parse sizes

Thank you for making the changes!

However, `display-mode` does not seem to work on macOS 26.1.  To reproduce:

- run the standalone monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest
- open Tools -> CSS Playground, copy and paste the following stylesheet:


    @media (display-mode: fullscreen) {
        .button {
            -fx-background-color: red;
        }
    }
``` 
- click Update
- select the Button page
- use Window -> Fullscreen to enter the fullscreen
I expect the buttons to turn red, but this does not happen (the earlier test used the Stage page, same result).

Alternatively, if I use `display-mode: standalone ` query, the buttons immediately turn red, but remain unchanged in fullscreen.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaFeatures.java line 56:

> 54:         return switch (lowerCaseFeatureName) {
> 55:             // Discrete min-/max-features are just features in a range context in disguise.
> 56:             case "min-width" -> rangeQueryExpression(SizeQueryType.WIDTH, featureValue,

very minor suggestion:

case "min-width" ->
    rangeQueryExpression(SizeQueryType.WIDTH, featureValue, ComparisonOp.GREATER_OR_EQUAL.getExpressionSupplier());

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/RangeExpression.java line 118:

> 116: 
> 117:     public interface Supplier {
> 118:         RangeExpression getSizeExpression(SizeQueryType featureType, Size sizeValue);

minor: could we use a name other than Supplier to avoid clashing with java.util.function one (it is confusing).

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

PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3584024894
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624011066
PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624005715

From angorya at openjdk.org  Tue Dec 16 18:20:35 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 18:20:35 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v3]
In-Reply-To: <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
Message-ID: <2UfTGF567Q72Pl0KEIFuZP8RZ6XMwOZ3f-UoRY3rDgk=.89ba94e1-7604-467b-a79b-98b1c5d60771@github.com>

On Tue, 16 Dec 2025 07:44:53 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 one additional commit since the last revision:
> 
>   Add more debug output

I am testing on macOS 26.1 with this PR merged with the latest master branch.

Here is what I see when the MT shows up on the secondary (scale=1) monitor:


Window/invalidationListener: shown changed to: true
Window/invalidationListener: screen=javafx.stage.Screen at ce424859 bounds:Rectangle2D [minX=0.0, minY=0.0, maxX=1800.0, maxY=1169.0, width=1800.0, height=1169.0] visualBounds:Rectangle2D [minX=0.0, minY=40.0, maxX=1800.0, maxY=1117.0, width=1800.0, height=1077.0] dpi:151.0 outputScale:(2.0,2.0)
Window/peer: setBounds(459.0, -1437.0, true, true, winW:1165.0, 880.0, clientW:-1.0, -1.0, 0.0, 0.0, rsx:0.0, rsy:0.0)
Window/invalidationListener: after applying bounds screen=javafx.stage.Screen at 5fd7eb71 bounds:Rectangle2D [minX=-760.0, minY=-1440.0, maxX=1800.0, maxY=0.0, width=2560.0, height=1440.0] visualBounds:Rectangle2D [minX=-760.0, minY=-1440.0, maxX=1800.0, maxY=0.0, width=2560.0, height=1440.0] dpi:108.0 outputScale:(1.0,1.0)
Window/invalidationListener: output scale used before sizing scene: 1.0
Window/invalidationListener: size from scene: 791.0x726.0
Window/peer: setBounds(459.0, -1437.0, true, true, winW:1165.0, 880.0, clientW:-1.0, -1.0, 0.0, 0.0, rsx:1.0, rsy:1.0)
Window/invalidationListener: exit invalidation listener


<img width="1233" height="948" alt="Screenshot 2025-12-16 at 10 16 42" src="https://github.com/user-attachments/assets/45e35016-46f2-44e3-908e-048d6f5eb109" />

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

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

From angorya at openjdk.org  Tue Dec 16 18:24:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 18:24:37 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v3]
In-Reply-To: <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
Message-ID: <-Ur5n3V1VM9YSK80HC0e7-AC37zmuFVctTWb46FYybw=.65cc9707-f81a-470b-af56-74c640f0680d@github.com>

On Tue, 16 Dec 2025 07:44:53 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 one additional commit since the last revision:
> 
>   Add more debug output

And here is what's logged if the MT appears on the primary (scale=2) screen:

Window/invalidationListener: shown changed to: true
Window/invalidationListener: screen=javafx.stage.Screen at ce424859 bounds:Rectangle2D [minX=0.0, minY=0.0, maxX=1800.0, maxY=1169.0, width=1800.0, height=1169.0] visualBounds:Rectangle2D [minX=0.0, minY=40.0, maxX=1800.0, maxY=1117.0, width=1800.0, height=1077.0] dpi:151.0 outputScale:(2.0,2.0)
Window/peer: setBounds(410.0, 62.0, true, true, winW:1055.0, 655.0, clientW:-1.0, -1.0, 0.0, 0.0, rsx:0.0, rsy:0.0)
Window/invalidationListener: after applying bounds screen=javafx.stage.Screen at ce424859 bounds:Rectangle2D [minX=0.0, minY=0.0, maxX=1800.0, maxY=1169.0, width=1800.0, height=1169.0] visualBounds:Rectangle2D [minX=0.0, minY=40.0, maxX=1800.0, maxY=1117.0, width=1800.0, height=1077.0] dpi:151.0 outputScale:(2.0,2.0)
Window/invalidationListener: output scale used before sizing scene: 2.0
Window/invalidationListener: size from scene: 773.5x730.5
Window/peer: setBounds(410.0, 62.0, true, true, winW:1055.0, 655.0, clientW:-1.0, -1.0, 0.0, 0.0, rsx:2.0, rsy:2.0)
Window/invalidationListener: exit invalidation listener

<img width="1167" height="767" alt="Screenshot 2025-12-16 at 10 18 51" src="https://github.com/user-attachments/assets/afa041fd-e889-49e1-8f9f-102c5a455f3e" />

If I resize the window, the layout gets fixed, though I see no output logged.

Hope this helps.

We also need this checked on Linux[es]

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

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

From angorya at openjdk.org  Tue Dec 16 18:27:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 18:27:31 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v3]
In-Reply-To: <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
Message-ID: <wH9-xyvA2Kl9JmnRoew42XLuRcp-p1fUhtpUFD45qHM=.31f53403-f564-4432-a4b0-5e6fb6a350db@github.com>

On Tue, 16 Dec 2025 07:44:53 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 one additional commit since the last revision:
> 
>   Add more debug output

Note: I am using the latest standalone monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest but a similar issue is present in the one that's currently in the main repo.

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

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

From mstrauss at openjdk.org  Tue Dec 16 18:45:09 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 18:45:09 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
 <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
Message-ID: <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>

On Tue, 16 Dec 2025 16:11:03 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   handle edge cases
>
> modules/javafx.graphics/src/main/native-glass/win/Utils.cpp line 144:
> 
>> 142:                 GetProcAddress(hModule, "SetThreadDpiAwarenessContext"));
>> 143: 
>> 144:             // Only load GetProcessDpiAwareness if GetThreadDpiAwarenessContext is not available (pre-Win10).
> 
> What versions of Windows does JavaFX support? I just spent a half hour searching and couldn't find any statement on this for either JavaFX or the JDK.
> 
> As of October of this year the original version of Windows 10 left Microsoft's Long Term Servicing Channel. As of now the earliest version of Windows supported by Microsoft is Win10 2016 (1607), the version where the thread DPI awareness calls were first added. Is JavaFX supporting and testing earlier versions of Windows? If not you should be able to just make direct calls to the thread DPI awareness API's.
> 
> This is probably a topic for the mailing list. I'm still surprised I couldn't find this information anywhere.

Even if we didn't _officially_ support Windows 10, I think it's a little too early to remove functionality given that this OS still has a ~40% share of Windows installations.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2624351702

From kcr at openjdk.org  Tue Dec 16 18:45:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Dec 2025 18:45:09 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
 <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
 <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>
Message-ID: <sYR59YRQxsuyl3G5_9k2VSmuDTMhBT8IK0DRNidUll8=.c9bf4945-98b3-4fe2-be49-cbbce640d383@github.com>

On Tue, 16 Dec 2025 18:40:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/win/Utils.cpp line 144:
>> 
>>> 142:                 GetProcAddress(hModule, "SetThreadDpiAwarenessContext"));
>>> 143: 
>>> 144:             // Only load GetProcessDpiAwareness if GetThreadDpiAwarenessContext is not available (pre-Win10).
>> 
>> What versions of Windows does JavaFX support? I just spent a half hour searching and couldn't find any statement on this for either JavaFX or the JDK.
>> 
>> As of October of this year the original version of Windows 10 left Microsoft's Long Term Servicing Channel. As of now the earliest version of Windows supported by Microsoft is Win10 2016 (1607), the version where the thread DPI awareness calls were first added. Is JavaFX supporting and testing earlier versions of Windows? If not you should be able to just make direct calls to the thread DPI awareness API's.
>> 
>> This is probably a topic for the mailing list. I'm still surprised I couldn't find this information anywhere.
>
> Even if we didn't _officially_ support Windows 10, I think it's a little too early to remove functionality given that this OS still has a ~40% share of Windows installations.

Definitely. We don't need to worry about Windows 8 or earlier, but it's premature to break Windows 10.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2624357959

From mfox at openjdk.org  Tue Dec 16 19:05:57 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 16 Dec 2025 19:05:57 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <sYR59YRQxsuyl3G5_9k2VSmuDTMhBT8IK0DRNidUll8=.c9bf4945-98b3-4fe2-be49-cbbce640d383@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
 <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
 <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>
 <sYR59YRQxsuyl3G5_9k2VSmuDTMhBT8IK0DRNidUll8=.c9bf4945-98b3-4fe2-be49-cbbce640d383@github.com>
Message-ID: <ubkAgQ5RjhyxOI1osQStMzBa8MaEqfzTmLBDe323QIk=.6ee216ce-e6bd-4a29-97da-2c1c97eab4d1@github.com>

On Tue, 16 Dec 2025 18:42:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Even if we didn't _officially_ support Windows 10, I think it's a little too early to remove functionality given that this OS still has a ~40% share of Windows installations.
>
> Definitely. We don't need to worry about Windows 8 or earlier, but it's premature to break Windows 10.

I don't want to stop supporting Windows 10.  I'm referring specifically to Windows 10 RTM, the very first version of 10, which has fallen entirely out of Microsoft's support system. If we only need to support versions of Windows that Microsoft is supporting that would be Windows 10 2016 (1607) in which case there's no need to mess with all the DLL and function pointer retrieval in this code. You can just issue direct calls to SetThreadDpiAwarenessContext and friends.

I will add that though we might say in this thread that we don't need to worry about Windows 8 or earlier I really and truly could not find any public statement to that effect anywhere.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2624411145

From duke at openjdk.org  Tue Dec 16 19:18:43 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 16 Dec 2025 19:18:43 GMT
Subject: RFR: 8184166: SortedList does not free up memory
Message-ID: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>

Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,

Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

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

Commit messages:
 - 8184166: fixing duplicated comparator
 - 8184166: Adding a test, and improving readability of existing
 - 8184166: Updating SortedListTest's testNonRequiredInternalReferencesAreNull() to include additional comparators and combinations
 - Merge remote-tracking branch 'credmond/fixes/sortablelist-gc' into fixes/sortablelist-gc
 - 8184166: SortedList: nullify out-of-range elements and ensure tempElement is cleared, minor optimisations to aid GC
 - 8184166: SortedList: nullify out-of-range elements and ensure tempElement is cleared, minor optimisations to aid GC

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

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

From jhendrikx at openjdk.org  Tue Dec 16 19:18:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Dec 2025 19:18:46 GMT
Subject: RFR: 8184166: SortedList does not free up memory
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <U_uKB85iNvk4V3WIL8ebkW8xWjkpzWWvfNBeGCryx7g=.bafde531-520c-48eb-84b7-61a1956062ed@github.com>

On Sun, 7 Dec 2025 01:36:02 GMT, Cormac Redmond <duke at openjdk.org> wrote:

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

This looks pretty good, I left a remark about how you clear the unused part of the list.

modules/javafx.base/src/main/java/javafx/collections/transformation/SortedList.java line 284:

> 282:                 // Already null, stop checking further
> 283:                 break;
> 284:             }

I think this is unsafe, depending on where the `null`s are sorted in the list (especially with a `nullsFirst` comparator). It may be better to get the `size` at the start of this method, and then clear anything from `size` to `oldSize` unconditionally.

modules/javafx.base/src/test/java/test/javafx/collections/SortedListTest.java line 622:

> 620:         SortedList<String> unsortedSortedList = new SortedList<>(list);
> 621:         assertEquals(0, sortedList.size());
> 622:         assertEquals(0, unsortedSortedList.size());

You could consider making the test parameterized.

modules/javafx.base/src/test/java/test/javafx/collections/SortedListTest.java line 677:

> 675:         checkElementsBeyondSizeAreNull(1, ReflectionUtils.getFieldValue(sortedList, "sorted"));
> 676:         checkElementsBeyondSizeAreNull(1, ReflectionUtils.getFieldValue(unsortedSortedList,
> 677:                 "sorted"));

So I guess that `null`s are sorted towards the end?  I think this will fail when they are sorted near the beginning (won't clear element `z` and `y`).

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

PR Review: https://git.openjdk.org/jfx/pull/2000#pullrequestreview-3550364865
PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2597245820
PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2597241565
PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2597240243

From duke at openjdk.org  Tue Dec 16 19:18:46 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 16 Dec 2025 19:18:46 GMT
Subject: RFR: 8184166: SortedList does not free up memory
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <vw0Y0YwNR0pgbP8NWQnvjmndyoGFT04dKkpwrjKiIu0=.4a1c617c-1669-41fe-b270-78de0f71f9aa@github.com>

On Sun, 7 Dec 2025 01:36:02 GMT, Cormac Redmond <duke at openjdk.org> wrote:

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

I've moved this PR out of draft to open as I think the implementation is correct.

Also, I am still waiting on this OCA signatory status verification and I am unsure if it's being filtered out somewhere (i.e., unseen) because the PR was not fully open yet.

The unit tests, in my view, are probably verifying too much (via reflection). E.g., most would usually not write such tests to verify the state of internal arrays.

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

PR Comment: https://git.openjdk.org/jfx/pull/2000#issuecomment-3657878420

From duke at openjdk.org  Tue Dec 16 19:18:47 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 16 Dec 2025 19:18:47 GMT
Subject: RFR: 8184166: SortedList does not free up memory
In-Reply-To: <U_uKB85iNvk4V3WIL8ebkW8xWjkpzWWvfNBeGCryx7g=.bafde531-520c-48eb-84b7-61a1956062ed@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
 <U_uKB85iNvk4V3WIL8ebkW8xWjkpzWWvfNBeGCryx7g=.bafde531-520c-48eb-84b7-61a1956062ed@github.com>
Message-ID: <6hp4OjS0BkZI7H_rdLHtLdRQb1BjWxqRPcsh7f-J940=.eb86ba25-f8d1-4998-a7fb-e1e71001fd0e@github.com>

On Mon, 8 Dec 2025 06:51:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I think this is unsafe, depending on where the `null`s are sorted in the list (especially with a `nullsFirst` comparator). It may be better to get the `size` at the start of this method, and then clear anything from `size` to `oldSize` unconditionally.

I tried to create the issue as you outlined, but this code does not get called when there's a comparator set (`updateUnsorted()`). 

Every element (null or not) gets wrapped in an `Element` class (so there are no nulls), this just nulls these Element objects when they're out of range (again, only for the unsorted). And they should stay like that (unless source list increases again).

I could re-write (using oldSize) as you suggested but it might suggest something about the behaviour that cannot happen...? (I could be missing something fundamental -- correct me if so).

I updated the tests there, hopefully proving this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2600014350

From mstrauss at openjdk.org  Tue Dec 16 19:21:36 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 19:21:36 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <ubkAgQ5RjhyxOI1osQStMzBa8MaEqfzTmLBDe323QIk=.6ee216ce-e6bd-4a29-97da-2c1c97eab4d1@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
 <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
 <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>
 <sYR59YRQxsuyl3G5_9k2VSmuDTMhBT8IK0DRNidUll8=.c9bf4945-98b3-4fe2-be49-cbbce640d383@github.com>
 <ubkAgQ5RjhyxOI1osQStMzBa8MaEqfzTmLBDe323QIk=.6ee216ce-e6bd-4a29-97da-2c1c97eab4d1@github.com>
Message-ID: <8SoNDjJncPX8_4fcp1w22gyhNonu_suFi5uVuttiasY=.82144291-816a-4c54-aa69-e9b637fca946@github.com>

On Tue, 16 Dec 2025 19:02:41 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Definitely. We don't need to worry about Windows 8 or earlier, but it's premature to break Windows 10.
>
> I don't want to stop supporting Windows 10.  I'm referring specifically to Windows 10 RTM, the very first version of 10, which has fallen entirely out of Microsoft's support system. If we only need to support versions of Windows that Microsoft is supporting that would be Windows 10 2016 (1607) in which case there's no need to mess with all the DLL and function pointer retrieval in this code. You can just issue direct calls to SetThreadDpiAwarenessContext and friends.
> 
> I will add that though we might say in this thread that we don't need to worry about Windows 8 or earlier I really and truly could not find any public statement to that effect anywhere.

If we removed that path, then for Windows 10 < 1607, we wouldn't be able to skip coordinate mapping for the usual (99.9%) case when the Java process is running with per-monitor DPI awareness. This wouldn't cause JavaFX to stop working, we'd just be back at the status quo where we don't account for the visible window frame.

We still need to dynamically load the function though, as it definitely won't be available on Win10 < 1607.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2624450742

From mstrauss at openjdk.org  Tue Dec 16 20:02:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 20:02:50 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v14]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <QvGLogYPuX68ff5_8n5UBFLvB1HR_crQk-hA6r2Aey0=.3f68d5ed-cb4f-4da9-b133-aa516572f602@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  use ChangeListener instead of InvalidationListener

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/0edf4392..795d1e14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=12-13

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

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

From mstrauss at openjdk.org  Tue Dec 16 20:02:51 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 20:02:51 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v13]
In-Reply-To: <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>
 <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
Message-ID: <r-8W15nc7MUMgyckSVdE6BriGV_YiN2NcO3V0RPwxQU=.93ca1b73-0b63-44e8-b911-f86f8af6029b@github.com>

On Tue, 16 Dec 2025 17:18:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> However, `display-mode` does not seem to work on macOS 26.1. To reproduce: [...]

Fixed that. I was using an `InvalidationListener` that would not be called again if the value of the observable was not actually read.

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3662162075

From mstrauss at openjdk.org  Tue Dec 16 20:08:10 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 20:08:10 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v15]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <MhHu_wgRxTJTQCbkWw2N2mPJdXu0P-VXuprsYleKC50=.b6f398b1-2de0-4838-8b90-765b54237272@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  formatting

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/795d1e14..1c690d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=13-14

  Stats: 22 lines in 1 file changed: 6 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From mstrauss at openjdk.org  Tue Dec 16 20:08:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 20:08:14 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v13]
In-Reply-To: <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>
 <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
Message-ID: <SwrsdZv-LP9PTiFKmierZGQnnBX3oA-RXqU00b4mdOo=.8860171a-3dd7-4c48-b30e-3619fd582cf4@github.com>

On Tue, 16 Dec 2025 16:44:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use CssParser.size() to parse sizes
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaFeatures.java line 56:
> 
>> 54:         return switch (lowerCaseFeatureName) {
>> 55:             // Discrete min-/max-features are just features in a range context in disguise.
>> 56:             case "min-width" -> rangeQueryExpression(SizeQueryType.WIDTH, featureValue,
> 
> very minor suggestion:
> 
> case "min-width" ->
>     rangeQueryExpression(SizeQueryType.WIDTH, featureValue, ComparisonOp.GREATER_OR_EQUAL.getExpressionSupplier());

I've moved the code more towards the front of the line, similarly to how it's already done for the user-preference features later in the `switch`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624579561

From mstrauss at openjdk.org  Tue Dec 16 20:13:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 20:13:49 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v16]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <4eISVmmIPAsRCzmfT41giDyYw94xFAu9cB1LDQlew9s=.9f3e5858-9de9-4fc8-a3d5-3e268f25e41b@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/1c690d4f..d350da6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=14-15

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

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

From mstrauss at openjdk.org  Tue Dec 16 20:13:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 20:13:50 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v10]
In-Reply-To: <MwHROE5_MACsa3MoeDDa2cTbR6sxUJapXaA4rFiWtT0=.3d45feac-2830-4a7e-a7cf-c82dc38c7fbb@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <3dDZoqtf1c7fRXAsQU4RzEGAOgVXIEiAE0UodYUHREE=.45091747-cddd-4508-93a1-7e55a80bf4d3@github.com>
 <C6xD7xko0BWvt7RVwUFr_Mc3iZJdbQPB2KjbNKZrXaI=.913b8068-b5d8-47c5-9d68-3525c2f96a6e@github.com>
 <_Bs10UmpFSHALgY5fL7sBPRVzx1rJtnq647XJGPf_sk=.fb0a9632-1bfb-4457-ad8f-7b462bebc63e@github.com>
 <MwHROE5_MACsa3MoeDDa2cTbR6sxUJapXaA4rFiWtT0=.3d45feac-2830-4a7e-a7cf-c82dc38c7fbb@github.com>
Message-ID: <DsKRzb_xhraJTn33JLIdMektQfbfQqRvbDEpPvy1OIY=.c5d5d55f-de0a-4926-bfac-510b2ef8424b@github.com>

On Tue, 16 Dec 2025 16:36:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> "Standalone" matches when "fullscreen" doesn't match. The relevant part of the [specification](https://www.w3.org/TR/mediaqueries-5/#display-modes) says that it is a window with "[...] standard system UI elements, such as window decorations, a system status bar, and/or a system back button [...]".
>> 
>> "Fullscreen" matches when none of that is available and the scene extends across the entire display, which is the case when the scene is hosted in a full-screen window.
>> 
>> Note that media queries don't change CSS precedence rules. In your example, you could check whether another rule that sets `-fx-background-color` has a higher precedence. You could try adding `!important` to quickly figure out whether the rule has any effect at all.
>
> What I meant is to explain the meaning in the cssref.html.  We can't really refer to w3.org pages for JavaFX, in my opinion.  So, if you want to keep the standalone term in the values, I think you ought to explain what it is, using JavaFX or platform terminology.

I've added a description to cssref.html that says what the two values mean in JavaFX terms.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624595941

From jhendrikx at openjdk.org  Tue Dec 16 20:20:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 16 Dec 2025 20:20:15 GMT
Subject: RFR: 8373688: Wrong render scale is used if Window is on another
 screen when Scene is sized [v3]
In-Reply-To: <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
Message-ID: <vh4wjuiKmf8vLED5xayqKFSRqi8WiQ708VVs_RV_hzo=.43a5a99e-328b-4f50-9136-4cca37866408@github.com>

On Tue, 16 Dec 2025 07:44:53 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 one additional commit since the last revision:
> 
>   Add more debug output

Judging from how square the MT screen looks (700 x 700 orso), it seems that after the window is shown, it is not resizing it to fit the window.  It is actually keeping the `sizeToScene` information (which it is supposed to ignore as you're setting sizes from preferences stored), or it is not triggering a resize even though the window is a totally different size than the scene.  I think I can work with that to have a deeper look.

It's certainly odd, since I'm only moving the `applyBounds` call to be slightly earlier, so it uses the correct render scale.  Later it does it again anyway.  In my tests the calculated `sizeToScene` was usually larger than the Window settings, so perhaps shrinking the window works correctly, but not expanding it when it doesn't fit the scene.

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

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

From angorya at openjdk.org  Tue Dec 16 21:16:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 21:16:37 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v16]
In-Reply-To: <4eISVmmIPAsRCzmfT41giDyYw94xFAu9cB1LDQlew9s=.9f3e5858-9de9-4fc8-a3d5-3e268f25e41b@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <4eISVmmIPAsRCzmfT41giDyYw94xFAu9cB1LDQlew9s=.9f3e5858-9de9-4fc8-a3d5-3e268f25e41b@github.com>
Message-ID: <DNRSFjaAfJmhwxPwTGGSk1rc7LK5PGCeQq3l9ZkwrYs=.65a220da-d7a2-4a83-8dde-6116f332f48d@github.com>

On Tue, 16 Dec 2025 20:13:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 971:

> 969:                 <td class="value">fullscreen | standalone</td>
> 970:                 <td>discrete</td>
> 971:                 <td><code>fullscreen</code> if <code>Stage.isFullScreen()</code>, <code>standalone</code> otherwise</code></td>

This description is perfectly clear now, thanks!

One question though: at the beginning of the chapter, you say "A media query is a method of testing certain aspects of the [Scene](https://github.com/openjdk/jfx/javafx/scene/Scene.html)" but this is not strictly true, since the Stage is also involved.

Do you think we should mention "and/or Stage" or something like that?

Moreover, what if other media queries are added that depend on some other aspects?  Maybe we should specify whose properties we are looking at in the comments, like "width" -> "Scene width" ?  What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624758212

From angorya at openjdk.org  Tue Dec 16 21:21:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 21:21:24 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v16]
In-Reply-To: <4eISVmmIPAsRCzmfT41giDyYw94xFAu9cB1LDQlew9s=.9f3e5858-9de9-4fc8-a3d5-3e268f25e41b@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <4eISVmmIPAsRCzmfT41giDyYw94xFAu9cB1LDQlew9s=.9f3e5858-9de9-4fc8-a3d5-3e268f25e41b@github.com>
Message-ID: <DInrxBe746iMvGJZ_SC7aZoTSv9A37pyOh2Pzj0M6NQ=.305e2502-1422-48c9-9ec4-c3619d5d631e@github.com>

On Tue, 16 Dec 2025 20:13:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation

The feature looks good on macOS 26.1, excellent work!

This needs to be tested on Windows and Linux[es].

Side note: I realized the CSS Playground does not apply the stylesheet to newly created windows, only to already present ones.  Should be ok to test though, with newly added Windows -> Fullscreen etc. menus.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3584979469

From mstrauss at openjdk.org  Tue Dec 16 21:30:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 21:30:19 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v17]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <Z9gNT75QI9FdGYSrM9uvvlON0CBfW9TIgZMsT_UAYMY=.281f1d45-a34d-4aff-9961-2d4eaba78fad@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/d350da6a..411da071

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=15-16

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

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

From mstrauss at openjdk.org  Tue Dec 16 21:30:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 21:30:22 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v16]
In-Reply-To: <DNRSFjaAfJmhwxPwTGGSk1rc7LK5PGCeQq3l9ZkwrYs=.65a220da-d7a2-4a83-8dde-6116f332f48d@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <4eISVmmIPAsRCzmfT41giDyYw94xFAu9cB1LDQlew9s=.9f3e5858-9de9-4fc8-a3d5-3e268f25e41b@github.com>
 <DNRSFjaAfJmhwxPwTGGSk1rc7LK5PGCeQq3l9ZkwrYs=.65a220da-d7a2-4a83-8dde-6116f332f48d@github.com>
Message-ID: <kEPEhMQ589t0PEjsM_CNJZ88MwdMkAZdWNmnfTgkDLQ=.54bbff59-085f-4520-8e8d-4eddfb442f9c@github.com>

On Tue, 16 Dec 2025 21:13:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   documentation
>
> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 971:
> 
>> 969:                 <td class="value">fullscreen | standalone</td>
>> 970:                 <td>discrete</td>
>> 971:                 <td><code>fullscreen</code> if <code>Stage.isFullScreen()</code>, <code>standalone</code> otherwise</code></td>
> 
> This description is perfectly clear now, thanks!
> 
> One question though: at the beginning of the chapter, you say "A media query is a method of testing certain aspects of the [Scene](https://github.com/openjdk/jfx/javafx/scene/Scene.html)" but this is not strictly true, since the Stage is also involved.
> 
> Do you think we should mention "and/or Stage" or something like that?
> 
> Moreover, what if other media queries are added that depend on some other aspects?  Maybe we should specify whose properties we are looking at in the comments, like "width" -> "Scene width" ?  What do you think?

Good idea, I've added that to the description.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624789401

From mstrauss at openjdk.org  Tue Dec 16 21:30:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 21:30:24 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v13]
In-Reply-To: <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>
 <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
Message-ID: <9snyj5x00rnYO1-uHT0eNVCTvnFOnQAaa1xJ4la6Bc8=.ba25652f-fb4b-4a59-91de-7e5d0b6aeca8@github.com>

On Tue, 16 Dec 2025 16:43:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use CssParser.size() to parse sizes
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/RangeExpression.java line 118:
> 
>> 116: 
>> 117:     public interface Supplier {
>> 118:         RangeExpression getSizeExpression(SizeQueryType featureType, Size sizeValue);
> 
> minor: could we use a name other than Supplier to avoid clashing with java.util.function one (it is confusing).

I've thought about that, but then I never use that type unqualified (i.e. always as `RangeExpression.Supplier`), and because it's so localized, I don't want to make it a top-level interface. A more verbose name like `RangeExpression.ExpressionSupplier` looks very chatty...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624796222

From angorya at openjdk.org  Tue Dec 16 21:35:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 21:35:50 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v13]
In-Reply-To: <9snyj5x00rnYO1-uHT0eNVCTvnFOnQAaa1xJ4la6Bc8=.ba25652f-fb4b-4a59-91de-7e5d0b6aeca8@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <d62tULFNwV6Lm4_bXNrYdCFqmpTBhNDaXjIKzOjD3XQ=.96979301-670d-491e-9304-5d4edb5e8c65@github.com>
 <5jD26uuNDOxRnOnAE_wnB7NKNSnet6eIDAJLM1tmGn4=.80cea5c1-bb6c-4f6e-ba58-27096196480d@github.com>
 <9snyj5x00rnYO1-uHT0eNVCTvnFOnQAaa1xJ4la6Bc8=.ba25652f-fb4b-4a59-91de-7e5d0b6aeca8@github.com>
Message-ID: <5jlTuEfIrWaQU54X_M3G1Wn1Y4fAp73Iwn3_XDNsllY=.3a86d770-a5da-40ce-92f2-d369aa1f9ab8@github.com>

On Tue, 16 Dec 2025 21:27:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/RangeExpression.java line 118:
>> 
>>> 116: 
>>> 117:     public interface Supplier {
>>> 118:         RangeExpression getSizeExpression(SizeQueryType featureType, Size sizeValue);
>> 
>> minor: could we use a name other than Supplier to avoid clashing with java.util.function one (it is confusing).
>
> I've thought about that, but then I never use that type unqualified (i.e. always as `RangeExpression.Supplier`), and because it's so localized, I don't want to make it a top-level interface. A more verbose name like `RangeExpression.ExpressionSupplier` looks very chatty...

ESupplier? RProvider?  but if the access is always qualified, we are good.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2624813589

From mstrauss at openjdk.org  Tue Dec 16 22:21:52 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 22:21:52 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v18]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <LkImJCci_F_r4zAZC1RJQyn014uwC0FRmFv6BdSzPpM=.33a8f8a4-bfce-4dab-9713-7c9b153e740c@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
> 
> Here's a small example how the new media features can be used:
> 
>     @Override
>     public void start(Stage stage) {
>         var button = new Button("Toggle full-screen");
>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>         var label = new Label();
>         var root = new BorderPane(button, null, null, label, null);
>         var scene = new Scene(root, 650, 200);
>         BorderPane.setAlignment(label, Pos.CENTER);
>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>             @media (max-width: 500) {
>                 .button {
>                     -fx-background-color: red;
>                 }
>             }
> 
>             @media (600 < width <= 700) {
>                 .button {
>                     -fx-background-color: green;
>                 }
>             }
> 
>             @media (min-width: 800) {
>                 .button {
>                     -fx-background-color: yellow;
>                 }
>             }
> 
>             @media (display-mode: fullscreen) {
>                 .button {
>                     -fx-background-color: black !important;
>                 }
>             }
>             """.getBytes(StandardCharsets.UTF_8)));
> 
>         stage.initStyle(StageStyle.DECORATED);
>         stage.setScene(scene);
>         stage.show();
>     }

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

  if parser exception is thrown, include verbatim user value in the message, not lower-cased version

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/411da071..0fc311f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=16-17

  Stats: 17 lines in 1 file changed: 2 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From angorya at openjdk.org  Tue Dec 16 22:36:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Dec 2025 22:36:31 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v18]
In-Reply-To: <LkImJCci_F_r4zAZC1RJQyn014uwC0FRmFv6BdSzPpM=.33a8f8a4-bfce-4dab-9713-7c9b153e740c@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
 <LkImJCci_F_r4zAZC1RJQyn014uwC0FRmFv6BdSzPpM=.33a8f8a4-bfce-4dab-9713-7c9b153e740c@github.com>
Message-ID: <dPHoIA1-LHNbdhYI0wnW0bAMiU0tSYk4QNqIcxsJ0qA=.d40b2654-ce43-4b6e-8c0d-89b3ccdd8b42@github.com>

On Tue, 16 Dec 2025 22:21:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
>> * `width`
>> * `height`
>> * `aspect-ratio`: width / height
>> * `orientation`: `portrait`, `landscape`
>> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)
>> 
>> Here's a small example how the new media features can be used:
>> 
>>     @Override
>>     public void start(Stage stage) {
>>         var button = new Button("Toggle full-screen");
>>         button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen()));
>>         var label = new Label();
>>         var root = new BorderPane(button, null, null, label, null);
>>         var scene = new Scene(root, 650, 200);
>>         BorderPane.setAlignment(label, Pos.CENTER);
>>         label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue())));
>>         scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString("""
>>             @media (max-width: 500) {
>>                 .button {
>>                     -fx-background-color: red;
>>                 }
>>             }
>> 
>>             @media (600 < width <= 700) {
>>                 .button {
>>                     -fx-background-color: green;
>>                 }
>>             }
>> 
>>             @media (min-width: 800) {
>>                 .button {
>>                     -fx-background-color: yellow;
>>                 }
>>             }
>> 
>>             @media (display-mode: fullscreen) {
>>                 .button {
>>                     -fx-background-color: black !important;
>>                 }
>>             }
>>             """.getBytes(StandardCharsets.UTF_8)));
>> 
>>         stage.initStyle(StageStyle.DECORATED);
>>         stage.setScene(scene);
>>         stage.show();
>>     }
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   if parser exception is thrown, include verbatim user value in the message, not lower-cased version

for other reviewers: I've updated the monkey tester's CSS Playground to apply the stylesheets to the newly created windows.

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3662715971

From mstrauss at openjdk.org  Tue Dec 16 22:43:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 16 Dec 2025 22:43:35 GMT
Subject: RFR: 8326428: [Linux] UI scaling factor cannot be fractional when
 using KDE
In-Reply-To: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
References: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
Message-ID: <IksxaLz5S2boM35z1yud3s2lSF4YJq1ZugrtyBEH0j4=.8b903a20-e415-4a37-ab33-b36a72df63d2@github.com>

On Mon, 1 Dec 2025 17:57:30 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The standard way to determine the user interface scaling factor on Linux is to consult the reported monitor DPI and divide by 96 (which is also the way it's done on Windows). This allows the scaling factor to vary per-monitor and also achieve fractional values.
> 
> Before this became the standard the Gnome toolkit communicated the scaling factor using the "GDK_SCALE" environment variable or the "org.gnome.desktop.interface" "scaling-factor" gsetting. These were always integer values (no fractional scaling) and applied to all monitors. They became the de-facto way of communicating the scaling factor and were picked  by various toolkits including JavaFX. They are now obsolete within Gnome.
> 
> JavaFX will compute correct per-monitor scaling factors if GDK_SCALE and "scaling-factor" aren't set. Gnome no longer sets these but unfortunately the KDE desktop does in an attempt to get certain apps to scale (one bug report specifically called out IntelliJ). In KDE for Ubuntu 24 the "scaling-factor" is always set to the floor of the actual scaling factor which is preventing JavaFX from computing fractional scales. Either setting will prevent JavaFX from computing per-monitor scales.
> 
> This PR changes the priority of the ui scale tests. As always, the JavaFX "glass.gtk.uiScale" setting takes precedence. If that's not set the system uses the scaling computed based on the monitor DPI. It only consults the legacy settings if the reported DPI is 96.
> 
> Ignoring GDK_SCALE is problematic since there are certainly users who use this as a convenient way to influence JavaFX (if only to work around this bug). If we want to provide an environment variable for them we should create our own and not rely on the legacy variables of other toolkits.

LGTM, testing also looks good.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1994#pullrequestreview-3585259301

From arapte at openjdk.org  Wed Dec 17 07:26:13 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 17 Dec 2025 07:26:13 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures [v2]
In-Reply-To: <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
 <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
Message-ID: <ESwi_VPBEG3nsPXzuP0avPwa-hQBwF9Yu48x2gQ1hmg=.b8e822f3-5ad6-4f03-a213-77a86dc6b057@github.com>

On Tue, 16 Dec 2025 11:49:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Currently we don't set any texture filtering & addressing modes for 3D textures in Metal pipeline.
>> Default 3D texture filtering is "nearest" for Metal textures, but we use "linear" filtering by default for 3D textures in case of OpenGL.
>> Default addressing mode is "clamp_to_edge" in Metal textures, but we use "repeat" addressing mode for 3D textures in OpenGL.
>> 
>> Metal should use same default filtering & addressing modes for 3D textures as in OpenGL pipeline.
>> Under this issue we are trying only to match defaults of Metal to OpenGL pipeline.
>> 
>> We don't update the filters/addressing modes for 3D textures once created.
>> We have open enhancements like https://bugs.openjdk.org/browse/JDK-8324594 where we might provide API's to set sampler states for 3D textures in future.
>> 
>> Functional and performance testing is green with this update.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   create sampler states only once

Leaving a few queries regarding the changes.
I expect there should not be any behavior changes, correct ?

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

> 1154:  * Class:     com_sun_prism_mtl_MTLContext
> 1155:  * Method:    nSetDeviceParametersFor3D
> 1156:  * Signature: (J)J

minor :  `(J)J`  should be changed to  `(J)V`

modules/javafx.graphics/src/main/native-prism-mtl/MetalMeshView.m line 244:

> 242:                              atIndex:3];
> 243:     [phongEncoder setFragmentSamplerState:[material getSamplerState:SELFILLUMINATION]
> 244:                                   atIndex:0];

1. All `setFragmentSamplerState` are setting at index 0, should it not be 0,1,2,3?
2. Does this not require any changes to `PhongPS.metal`,  The shader functions in `PhongPS.metal` do not have a `sampler` parameter.
3. Currently the `PhongPS.metal` file creates two samplers in shader file itself and uses those for sampling. May be that should be modified to use these samplers that are set using `setFragmentSamplerState`

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2005#pullrequestreview-3586288154
PR Review Comment: https://git.openjdk.org/jfx/pull/2005#discussion_r2625834766
PR Review Comment: https://git.openjdk.org/jfx/pull/2005#discussion_r2625892527

From jdv at openjdk.org  Wed Dec 17 08:55:04 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 17 Dec 2025 08:55:04 GMT
Subject: RFR: 8373232: Set default filters and addressing modes for 3D
 metal textures [v2]
In-Reply-To: <ESwi_VPBEG3nsPXzuP0avPwa-hQBwF9Yu48x2gQ1hmg=.b8e822f3-5ad6-4f03-a213-77a86dc6b057@github.com>
References: <GS7NcxsGiIkKpPO_pFz5py_kCzH1Ic66jrEeb1ScnPI=.d58df82f-8b99-41de-bf00-864d412045a8@github.com>
 <SxUzQQRIa6cpO1Ta9ooK6dweoCVPUx-yEbnmVzcBi3A=.e26808e7-faeb-4447-9c2b-edee7512b13d@github.com>
 <ESwi_VPBEG3nsPXzuP0avPwa-hQBwF9Yu48x2gQ1hmg=.b8e822f3-5ad6-4f03-a213-77a86dc6b057@github.com>
Message-ID: <oNXwQ7bbl8WA-9lpWPhiki3ckgcZkc1d2IRb9Y5DZe4=.51d46c5e-d599-4093-860b-0752ade07ffd@github.com>

On Wed, 17 Dec 2025 07:21:59 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   create sampler states only once
>
> modules/javafx.graphics/src/main/native-prism-mtl/MetalMeshView.m line 244:
> 
>> 242:                              atIndex:3];
>> 243:     [phongEncoder setFragmentSamplerState:[material getSamplerState:SELFILLUMINATION]
>> 244:                                   atIndex:0];
> 
> 1. All `setFragmentSamplerState` are setting at index 0, should it not be 0,1,2,3?
> 2. Does this not require any changes to `PhongPS.metal`,  The shader functions in `PhongPS.metal` do not have a `sampler` parameter.
> 3. Currently the `PhongPS.metal` file creates two samplers in shader file itself and uses those for sampling. May be that should be modified to use these samplers that are set using `setFragmentSamplerState`

Thanks for the observations @arapte .
Yes these changes are needed and it also has to be tested properly. So moving this PR back to draft stage.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2005#discussion_r2626143073

From jhendrikx at openjdk.org  Wed Dec 17 10:10:49 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Dec 2025 10:10:49 GMT
Subject: RFR: 8184166: SortedList does not free up memory
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <eGSe5H_-_WRG-Y8Y80D1mMiC010uwlPcIT8RHxxp9JI=.b759d2da-84ac-4be6-a44f-926ce4b4d481@github.com>

On Sun, 7 Dec 2025 01:36:02 GMT, Cormac Redmond <duke at openjdk.org> wrote:

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

Thanks for clarifying my questions, this looks good!

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2000#pullrequestreview-3586964380

From mhanl at openjdk.org  Wed Dec 17 10:54:34 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 17 Dec 2025 10:54:34 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic [v2]
In-Reply-To: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
Message-ID: <YIr6xpiY358sRf0fIrSdLy9UcbZ_VDLA2qyKnQgruUM=.b71d3181-30c6-4bdc-aa20-74001de6ad4e@github.com>

> This is a small improvement that was noted back in https://github.com/openjdk/jfx/pull/1200#issuecomment-1671954361 by @mstr2, and was on my list since then.
> 
> The idea is to have only one place for assigning `adapter ordinals` ? within `Screen`. The corresponding setter `setAdapterOrdinal` can therefore be made private. This improves the separation of responsibilities a little. :-)

Marius Hanl 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 two additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jfx into 8314820-unify-screen-adapter
 - 8314820: Unify Screen adapter ordinal logic

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2009/files
  - new: https://git.openjdk.org/jfx/pull/2009/files/b49db9a9..112e2920

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

  Stats: 1366 lines in 34 files changed: 1189 ins; 89 del; 88 mod
  Patch: https://git.openjdk.org/jfx/pull/2009.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2009/head:pull/2009

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

From mhanl at openjdk.org  Wed Dec 17 11:05:49 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 17 Dec 2025 11:05:49 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
In-Reply-To: <V4iH9RdSwwBc4ke70GlantUEkRPHSGN5-vxvb7YtvP8=.78c8304b-945d-409f-8098-ab28c3b3ed3e@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
 <V4iH9RdSwwBc4ke70GlantUEkRPHSGN5-vxvb7YtvP8=.78c8304b-945d-409f-8098-ab28c3b3ed3e@github.com>
Message-ID: <j0HBpF-vALaF3yK-YRG827vkm5--F2le5gx1bgkVZFE=.323014cc-6462-4ab1-bcc7-dc44f0e7ce9b@github.com>

On Tue, 16 Dec 2025 16:53:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> One thought nagged me during the review: why do we keep the ordinal (an index) when we could, in theory, keep a reference to the object? Is there a potential for misalignment, perhaps a transient one?

My guess: Because the purpose is to be an Identifier (ID) only, so that a Screen can be later mapped to a Pipeline, if needed. The `MTLPipeline` does not need that, but e.g. `D3DPipeline` does. I guess using an object therefore could be possible, but makes sense only for some pipelines still.

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

PR Comment: https://git.openjdk.org/jfx/pull/2009#issuecomment-3664833001

From lkostyra at openjdk.org  Wed Dec 17 11:57:55 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 17 Dec 2025 11:57:55 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
In-Reply-To: <j0HBpF-vALaF3yK-YRG827vkm5--F2le5gx1bgkVZFE=.323014cc-6462-4ab1-bcc7-dc44f0e7ce9b@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
 <V4iH9RdSwwBc4ke70GlantUEkRPHSGN5-vxvb7YtvP8=.78c8304b-945d-409f-8098-ab28c3b3ed3e@github.com>
 <j0HBpF-vALaF3yK-YRG827vkm5--F2le5gx1bgkVZFE=.323014cc-6462-4ab1-bcc7-dc44f0e7ce9b@github.com>
Message-ID: <xOSClYLUzacCXeYMduxmoQvvU24Dt_cQ8icFc1y8LB0=.cdc42334-388f-4533-b15a-7a95c74c34db@github.com>

On Wed, 17 Dec 2025 11:02:54 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > One thought nagged me during the review: why do we keep the ordinal (an index) when we could, in theory, keep a reference to the object? Is there a potential for misalignment, perhaps a transient one?
> 
> My guess: Because the purpose is to be an Identifier (ID) only, so that a Screen can be later mapped to a Pipeline, if needed. The `MTLPipeline` does not need that, but e.g. `D3DPipeline` does. I guess using an object therefore could be possible, but makes sense only for some pipelines still.

That would be my guess too. In D3D9 there's a "lost device" event which applications need to handle properly - whenever ex. a screen resolution changes, a screen gets (un)plugged, the window gets minimized/restored, or even when the fullscreen app loses keyboard focus. When D3D9 loses the Device for any reason the rendering calls are silently ignored and runtime returns an appropriate error code - application needs to first "reset" the device and then recreate all resources (especially resources stored in VRAM).

I would suspect that a D3D9 device reset can have a possibility of changing how the system enumerates the screen, so we might need to be able to re-identify the screens in order to re-tie the respective Resource Factories. I wasn't there when this was written, but an ordinal seems to be the easiest way to go about it. Other backends probably don't really use it since they don't have a scenario like this.

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

PR Comment: https://git.openjdk.org/jfx/pull/2009#issuecomment-3665006186

From mhanl at openjdk.org  Wed Dec 17 13:49:56 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 17 Dec 2025 13:49:56 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling with
 Java 25
Message-ID: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>

When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).

The following warning appears:


> Task :controls:compileJava
C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
    private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
                                                                             ^
C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
    private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
                             ^
error: warnings found and -Werror specified
1 error
2 warnings

> Task :controls:compileJava FAILED


The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

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

Commit messages:
 - 8373885: Compilation failure due to a warning when compiling with Java 25

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

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

From kcr at openjdk.org  Wed Dec 17 15:07:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Dec 2025 15:07:00 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <GQpzay_R-ryRp_0r_7PbpBk9MlEk_MrhdEhXQnNbOmQ=.da09cac5-6283-4bf4-a018-6ae4b7e24894@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

Changes requested by kcr (Lead).

We don't see this warning in GHA builds nor our production builds, both of which use JDK 25 (25.0.1 to be precise) to build. I'd like to understand why before we proceed.

modules/javafx.controls/src/main/java/javafx/scene/control/SplitPane.java line 316:

> 314: 
> 315:     // Cache the divider positions if the items have not been created.
> 316:     private final Map<Integer, Double> dividerCache = new HashMap<>();

I don't understand why this would have anything to do with a compiler warning. Further, this will likely lead to a leak, so I doubt this is what we want.

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

PR Review: https://git.openjdk.org/jfx/pull/2010#pullrequestreview-3588181048
PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3665758215
PR Review Comment: https://git.openjdk.org/jfx/pull/2010#discussion_r2627427013

From mfox at openjdk.org  Wed Dec 17 15:11:08 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 17 Dec 2025 15:11:08 GMT
Subject: Integrated: 8326428: [Linux] UI scaling factor cannot be fractional
 when using KDE
In-Reply-To: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
References: <v5Pbw4qvcxXVIpxVzpbGF5FW8uLiiRlv3IN13q2UIO0=.850aab58-562c-4155-989f-c0004fccc840@github.com>
Message-ID: <8gHWci2bF9J9mPweKLciE-D25hTTy68u6-gnwZiJKY4=.a757b40c-b21d-4e25-b84c-394873ea0a06@github.com>

On Mon, 1 Dec 2025 17:57:30 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The standard way to determine the user interface scaling factor on Linux is to consult the reported monitor DPI and divide by 96 (which is also the way it's done on Windows). This allows the scaling factor to vary per-monitor and also achieve fractional values.
> 
> Before this became the standard the Gnome toolkit communicated the scaling factor using the "GDK_SCALE" environment variable or the "org.gnome.desktop.interface" "scaling-factor" gsetting. These were always integer values (no fractional scaling) and applied to all monitors. They became the de-facto way of communicating the scaling factor and were picked  by various toolkits including JavaFX. They are now obsolete within Gnome.
> 
> JavaFX will compute correct per-monitor scaling factors if GDK_SCALE and "scaling-factor" aren't set. Gnome no longer sets these but unfortunately the KDE desktop does in an attempt to get certain apps to scale (one bug report specifically called out IntelliJ). In KDE for Ubuntu 24 the "scaling-factor" is always set to the floor of the actual scaling factor which is preventing JavaFX from computing fractional scales. Either setting will prevent JavaFX from computing per-monitor scales.
> 
> This PR changes the priority of the ui scale tests. As always, the JavaFX "glass.gtk.uiScale" setting takes precedence. If that's not set the system uses the scaling computed based on the monitor DPI. It only consults the legacy settings if the reported DPI is 96.
> 
> Ignoring GDK_SCALE is problematic since there are certainly users who use this as a convenient way to influence JavaFX (if only to work around this bug). If we want to provide an environment variable for them we should create our own and not rely on the legacy variables of other toolkits.

This pull request has now been integrated.

Changeset: eaca7528
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/eaca75286abb43aa46fe6d0cd99c7938b649b3b3
Stats:     20 lines in 1 file changed: 8 ins; 0 del; 12 mod

8326428: [Linux] UI scaling factor cannot be fractional when using KDE

Reviewed-by: lkostyra, mstrauss

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

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

From kcr at openjdk.org  Wed Dec 17 15:15:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Dec 2025 15:15:35 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <S019onoXX28CEgMgibsKtVHGVwpqLsSky1tQ86T7ngQ=.24642776-e5e7-4ee9-b277-71d7ddb00007@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

Interestingly enough, I do see this warning with a simple test program (or with jshell). I wonder why we aren't seeing it in our GHA builds or in production.

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

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3665800667

From kcr at openjdk.org  Wed Dec 17 15:26:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Dec 2025 15:26:53 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <J6764-QfNP5FzuahxZkfKdzxbqpnUbCm-TwZnV1v-ik=.8a63b5b6-3a39-498f-bebe-08d73aef3557@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

I know why it isn't happening for our build. The warning only happens if you use `--release 25` (which is the default with JDK 25). We build JavaFX with `--release 24` so haven't yet hit this warning.

So this bug will prevent our being able to bump the minimum JDK to 25, which we plan to do per recent practice fairly early in the JavaFX 27 development cycle.

So back to the solution. We can either do what you suggest and move away from a WeakHashMap (not something I'd consider without evaluating the potential leak) or switch the type of the key to a record containing an int (basically inventing our own Integer class that has identity).

The Valhalla folks probably thought of this use case, so perhaps they have a suggested pattern to use?

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

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3665852889

From angorya at openjdk.org  Wed Dec 17 15:51:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Dec 2025 15:51:18 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic
In-Reply-To: <xOSClYLUzacCXeYMduxmoQvvU24Dt_cQ8icFc1y8LB0=.cdc42334-388f-4533-b15a-7a95c74c34db@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
 <V4iH9RdSwwBc4ke70GlantUEkRPHSGN5-vxvb7YtvP8=.78c8304b-945d-409f-8098-ab28c3b3ed3e@github.com>
 <j0HBpF-vALaF3yK-YRG827vkm5--F2le5gx1bgkVZFE=.323014cc-6462-4ab1-bcc7-dc44f0e7ce9b@github.com>
 <xOSClYLUzacCXeYMduxmoQvvU24Dt_cQ8icFc1y8LB0=.cdc42334-388f-4533-b15a-7a95c74c34db@github.com>
Message-ID: <dIy7f1rVNiQ7-dnFHKREr5pi9_pwAdwfUzXdz5mcrKw=.5b1a3f13-5829-43f4-b6ec-ca149786120a@github.com>

On Wed, 17 Dec 2025 11:54:48 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> an ordinal seems to be the easiest way to go about it.

thank you

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

PR Comment: https://git.openjdk.org/jfx/pull/2009#issuecomment-3665969944

From mhanl at openjdk.org  Wed Dec 17 16:17:12 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 17 Dec 2025 16:17:12 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <J6764-QfNP5FzuahxZkfKdzxbqpnUbCm-TwZnV1v-ik=.8a63b5b6-3a39-498f-bebe-08d73aef3557@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
 <J6764-QfNP5FzuahxZkfKdzxbqpnUbCm-TwZnV1v-ik=.8a63b5b6-3a39-498f-bebe-08d73aef3557@github.com>
Message-ID: <coHoL26DKSlaR1dIP72B5zfM-gz1AGCM-muaQxCPUBA=.4724f788-a957-4d98-9cc9-26c74b428b32@github.com>

On Wed, 17 Dec 2025 15:24:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I know why it isn't happening for our build. The warning only happens if you use `--release 25` (which is the default with JDK 25). We build JavaFX with `--release 24` so haven't yet hit this warning.

Yes, correct. That is what I meant with 'compiling with Java 25', but should have made this more clear.

> So back to the solution. We can either do what you suggest and move away from a WeakHashMap (not something I'd consider without evaluating the potential leak) or switch the type of the key to a record containing an int (basically inventing our own Integer class that has identity).

Using an Integer within a WeakRef makes no sense, does it? I don't think this will prevent anything from being garbage collected. We are using the small Integer (int) as well, as far as I can see. And Integers between -127 and 128 are cached as well. So I don't see how weak keys are useful for Integer in any case.

> The Valhalla folks probably thought of this use case, so perhaps they have a suggested pattern to use?

The reasoning is probably what I wrote above. But I will have a look! More information (and learning) is always good!

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

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3666082063

From lkostyra at openjdk.org  Wed Dec 17 16:34:39 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 17 Dec 2025 16:34:39 GMT
Subject: RFR: 8314820: Unify Screen adapter ordinal logic [v2]
In-Reply-To: <YIr6xpiY358sRf0fIrSdLy9UcbZ_VDLA2qyKnQgruUM=.b71d3181-30c6-4bdc-aa20-74001de6ad4e@github.com>
References: <pffpNZ-MSvHzZZp4tG2HhKp4yPmOloz0YBaJwAvH3OY=.6e26e00f-2cdc-4ab0-a348-446db1849341@github.com>
 <YIr6xpiY358sRf0fIrSdLy9UcbZ_VDLA2qyKnQgruUM=.b71d3181-30c6-4bdc-aa20-74001de6ad4e@github.com>
Message-ID: <ZU-htRf0Xdt4MtUd50s2k62tlIBcg4Gv-q8n09xQJbM=.40353391-9316-4111-b074-d95c3aac7add@github.com>

On Wed, 17 Dec 2025 10:54:34 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This is a small improvement that was noted back in https://github.com/openjdk/jfx/pull/1200#issuecomment-1671954361 by @mstr2, and was on my list since then.
>> 
>> The idea is to have only one place for assigning `adapter ordinals` ? within `Screen`. The corresponding setter `setAdapterOrdinal` can therefore be made private. This improves the separation of responsibilities a little. :-)
>
> Marius Hanl 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8314820-unify-screen-adapter
>  - 8314820: Unify Screen adapter ordinal logic

Looks good, quick local confidence check works fine.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2009#pullrequestreview-3588580232

From jhendrikx at openjdk.org  Wed Dec 17 16:57:45 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Dec 2025 16:57:45 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <EaCSsPxfVHpY2oMR5AOUiXiKyCYB6Fb9ugXIZ4rjlPY=.e805d000-eb56-4653-b753-88939d5dae71@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

This is certainly an interesting use of `WeakHashMap`, and IMHO one that can so easily be avoided completely.

There is no need for this cache.  Just create a `Divider` when one is set -- it is not a node, it's pretty light-weight, and you're gonna need it soon anyway -- a weak hash map entry + double object + integer object may well cost more than the `Divider`. If you do something stupid like `setDivider(Integer.MAX_VALUE, 1.0)` then you deserve a nice out of memory exception as you're implying there will be 2 billion dividers.

Also `Integer`s, even before JDK 25, are cached internally for values -127 to 128.  This `WeakHashMap` will simply not work for any reasonable amount of dividers, as those `Integer`s will never be weakly reachable.

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

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3666260570

From angorya at openjdk.org  Wed Dec 17 17:31:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Dec 2025 17:31:17 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <G6ggItRoCew0WjPsDq_V4W-BKT9EqtWFqaWCMriONfE=.8d470fad-040a-488d-b14c-ba0d712c1a3b@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

Marked as reviewed by angorya (Reviewer).

I agree with John - the original code makes no sense.  Perhaps it is the reason why we have so many bugs related to dividers?

I think we can go with the proposed fix for now (it's a map of `<Integer, Double>` so little danger of leaks), and then attempt to get rid of this map altogether in a followup.

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

PR Review: https://git.openjdk.org/jfx/pull/2010#pullrequestreview-3588809079
PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3666410765

From mfox at openjdk.org  Wed Dec 17 19:30:14 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 17 Dec 2025 19:30:14 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <8SoNDjJncPX8_4fcp1w22gyhNonu_suFi5uVuttiasY=.82144291-816a-4c54-aa69-e9b637fca946@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
 <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
 <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>
 <sYR59YRQxsuyl3G5_9k2VSmuDTMhBT8IK0DRNidUll8=.c9bf4945-98b3-4fe2-be49-cbbce640d383@github.com>
 <ubkAgQ5RjhyxOI1osQStMzBa8MaEqfzTmLBDe323QIk=.6ee216ce-e6bd-4a29-97da-2c1c97eab4d1@github.com>
 <8SoNDjJncPX8_4fcp1w22gyhNonu_suFi5uVuttiasY=.82144291-816a-4c54-aa69-e9b637fca946@github.com>
Message-ID: <BdgdF_ntGHXqxADNV1mxDSAE8jLUSh_38TIDasIDJzU=.1e748bcd-08a6-4323-9151-857c9414981a@github.com>

On Tue, 16 Dec 2025 19:17:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> We still need to dynamically load the function though, as it definitely won't be available on Win10 < 1607.

Officially you're doing the right thing by writing code that works on all versions of Windows 10. But this assumes there are users out there with the original release of Windows 10 (no updates past 2015) who will want to install a JavaFX 26-based app. Are there? Can we even test this code? I don't see how this is sustainable going forward.

This is not really a question for you. I should take it to the mailing list.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2628370936

From michaelstrau2 at gmail.com  Wed Dec 17 19:43:08 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 17 Dec 2025 20:43:08 +0100
Subject: Default event handlers
Message-ID: <CAJEpuXTDmyo_DEuZp0nH9rc6oVsP1Y2ftiwh8T_QW2WQAQShPg@mail.gmail.com>

This is a follow-up to last year's discussion on unconsumed event handlers:
https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050758.html

John correctly pointed out that last year's proposal was not entirely
consistent (discardUnconsumedEventHandlers() was still
order-dependent). Martin also cautioned that storing per-dispatch
state in Event instances can be brittle, because implementations might
not use Event.copyFor to derive event instances.

I've made two changes compared to the last proposal to address both concerns:

1. Event.discardUnconsumedEventHandlers() is replaced with
Event.preventDefault(). Calling this method at any time during event
dispatch causes default handlers not to be invoked.

2. Default handlers are not tracked in the Event instance, but as part
of the dispatch process.

Here is the PR with the proposed implementation:
https://github.com/openjdk/jfx/pull/2011

Andy preferred having explicit priorities. However, while default
handlers are conceptually quite simple (they are called in the order
they were registered, and you'll get the exact event as it existed
when the first-chance handler was called), a multi-dispatch
prioritized event system is conceptually more complicated. Currently,
events are ordered across phase x node-depth x event-type specificity.
Adding priorities would add another factor to this product, with
reverberations through the entire event system. In addition to that,
it would incentivize an arms race to higher priorities.

From liach at openjdk.org  Wed Dec 17 19:45:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Dec 2025 19:45:44 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <GQpzay_R-ryRp_0r_7PbpBk9MlEk_MrhdEhXQnNbOmQ=.da09cac5-6283-4bf4-a018-6ae4b7e24894@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
 <GQpzay_R-ryRp_0r_7PbpBk9MlEk_MrhdEhXQnNbOmQ=.da09cac5-6283-4bf4-a018-6ae4b7e24894@github.com>
Message-ID: <1sq1CyDrqtiI0vz2u3X1eKooRMFaTjEPse83dzZyb8o=.bceb38ed-2437-4391-8703-3e62badcb598@github.com>

On Wed, 17 Dec 2025 15:04:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
>> 
>> The following warning appears:
>> 
>> 
>>> Task :controls:compileJava
>> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>>                                                                              ^
>> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>>                              ^
>> error: warnings found and -Werror specified
>> 1 error
>> 2 warnings
>> 
>>> Task :controls:compileJava FAILED
>> 
>> 
>> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/SplitPane.java line 316:
> 
>> 314: 
>> 315:     // Cache the divider positions if the items have not been created.
>> 316:     private final Map<Integer, Double> dividerCache = new HashMap<>();
> 
> I don't understand why this would have anything to do with a compiler warning. Further, this will likely lead to a leak, so I doubt this is what we want.

I recommend using a LinkedHashMap that overrides `removeEldestEntry` for this cache instead.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2010#discussion_r2628410224

From mstrauss at openjdk.org  Wed Dec 17 19:48:51 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 17 Dec 2025 19:48:51 GMT
Subject: RFR: 8372415: Stage size should match visual window bounds [v3]
In-Reply-To: <BdgdF_ntGHXqxADNV1mxDSAE8jLUSh_38TIDasIDJzU=.1e748bcd-08a6-4323-9151-857c9414981a@github.com>
References: <Gbu9PzL46d0kdiXLPFBC4-AjsNxkLYLz3UKgoyxq5kY=.b415075a-758f-42a7-9187-f2c9765136cd@github.com>
 <83aBWeFc6HMvHTpkpUNiZTHM3rpNJ5EOAHZhiGXz664=.0afd2ecf-db04-4b60-8bee-0bdae47e4c24@github.com>
 <5G2prvooyrVP5ARZ9WVZFv953R2MRUgSs7XiWtx02xs=.5ab0da2c-e0b3-4e55-ad14-6c151a56e78e@github.com>
 <Xqlm04WWVya-Pnk-RtiFcANfQ9phb392g7wUqdrKPr4=.04eb2b33-1536-4e71-8029-031ca6588449@github.com>
 <sYR59YRQxsuyl3G5_9k2VSmuDTMhBT8IK0DRNidUll8=.c9bf4945-98b3-4fe2-be49-cbbce640d383@github.com>
 <ubkAgQ5RjhyxOI1osQStMzBa8MaEqfzTmLBDe323QIk=.6ee216ce-e6bd-4a29-97da-2c1c97eab4d1@github.com>
 <8SoNDjJncPX8_4fcp1w22gyhNonu_suFi5uVuttiasY=.82144291-816a-4c54-aa69-e9b637fca946@github.com>
 <BdgdF_ntGHXqxADNV1mxDSAE8jLUSh_38TIDasIDJzU=.1e748bcd-08a6-4323-9151-857c9414981a@github.com>
Message-ID: <QfrvjT6OC01ZKxTlUP3DB8EthjQUJkgJhNxcAR9EEds=.125e471b-629c-43d3-9f45-a9a36ba8e00f@github.com>

On Wed, 17 Dec 2025 19:28:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> If we removed that path, then for Windows 10 < 1607, we wouldn't be able to skip coordinate mapping for the usual (99.9%) case when the Java process is running with per-monitor DPI awareness. This wouldn't cause JavaFX to stop working, we'd just be back at the status quo where we don't account for the visible window frame.
>> 
>> We still need to dynamically load the function though, as it definitely won't be available on Win10 < 1607.
>
>> We still need to dynamically load the function though, as it definitely won't be available on Win10 < 1607.
> 
> Officially you're doing the right thing by writing code that works on all versions of Windows 10. But this assumes there are users out there with the original release of Windows 10 (no updates past 2015) who will want to install a JavaFX 26-based app. Are there? Can we even test this code? I don't see how this is sustainable going forward.
> 
> This is not really a question for you. I should take it to the mailing list.

I can't test this in a systematic way, as I can't be bothered to get an installation of an ancient version of Windows. However, in this particular case, I _did_ test what would happen if the new functions can't be loaded by simply commenting out the code that loads the new functions.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1982#discussion_r2628418795

From rriggs at openjdk.org  Wed Dec 17 20:38:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Dec 2025 20:38:38 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <rfvHIQDhjYiEJQn40mLgWkTnA9VEkAoO80bmOdGVLPg=.ff6d440e-c1e6-45a1-890b-eb06a1a755cb@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

$.02, From the Valhalla point of view.
As above, there is no reason for the WeakHashMap.  The object being cached is small so memory reclamation is not the goal.  The keys are small integers, currently cached so always exist, so never freed and nothing is reclaimed.
Its not clear why a map is used either but maybe thought to be an easier APIs to manage the set.
The simple switch to another Map implementation should be very low risk.
Regards, Roger

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

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3667060976

From kcr at openjdk.org  Wed Dec 17 21:05:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Dec 2025 21:05:19 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <jRW01xNnU4aXa2oiX02Sn_QqG7Ag5uD2koTkDbNsf7g=.e5dbb810-7ac5-4864-a323-39d1fd72e2aa@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/2010#pullrequestreview-3589648648

From kcr at openjdk.org  Wed Dec 17 21:05:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Dec 2025 21:05:20 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <rfvHIQDhjYiEJQn40mLgWkTnA9VEkAoO80bmOdGVLPg=.ff6d440e-c1e6-45a1-890b-eb06a1a755cb@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
 <rfvHIQDhjYiEJQn40mLgWkTnA9VEkAoO80bmOdGVLPg=.ff6d440e-c1e6-45a1-890b-eb06a1a755cb@github.com>
Message-ID: <h84ZGi8js7jU3ATcsZT_aRwE9gwsVuqG_9Yj2XBfYm4=.3f97a90a-307c-4115-8a1e-a8542c16328f@github.com>

On Wed, 17 Dec 2025 20:36:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
>> 
>> The following warning appears:
>> 
>> 
>>> Task :controls:compileJava
>> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>>                                                                              ^
>> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>>                              ^
>> error: warnings found and -Werror specified
>> 1 error
>> 2 warnings
>> 
>>> Task :controls:compileJava FAILED
>> 
>> 
>> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.
>
> $.02, From the Valhalla point of view.
> As above, there is no reason for the WeakHashMap.  The object being cached is small so memory reclamation is not the goal.  The keys are small integers, currently cached so always exist, so never freed and nothing is reclaimed.
> Its not clear why a map is used either but maybe thought to be an easier APIs to manage the set.
> The simple switch to another Map implementation should be very low risk.
> Regards, Roger

@RogerRiggs Thanks for the confirmation.

Let's continue with this PR then. We can explore removing the divider cache in a follow-up.

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

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3667140995

From angorya at openjdk.org  Wed Dec 17 23:32:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Dec 2025 23:32:12 GMT
Subject: RFR: 8184166: SortedList does not free up memory
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <Lo5qhYl5lm0bnIOzev6TlajkoOOFD76xs6AcfHzjw5c=.5877003d-066d-4811-b2a8-ef55b2295c06@github.com>

On Sun, 7 Dec 2025 01:36:02 GMT, Cormac Redmond <duke at openjdk.org> wrote:

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

modules/javafx.base/src/main/java/javafx/collections/transformation/SortedList.java line 280:

> 278: 
> 279:         // Null out out-of-range array elements to avoid maintaining object references
> 280:         for (int i = size; i < sorted.length; i++) {

Don't we need to null the unused entries only when the `sorted` array shrinks (i.e. when the `size` is reduced)?

so all we do is to handle L259 case `if (c.wasRemoved())` since everywhere else the references are null'ed (L379, L388)?

modules/javafx.base/src/test/addExports line 14:

> 12: --add-opens javafx.base/javafx.beans.value=ALL-UNNAMED
> 13: --add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED
> 14: #

we probably should add a newline char at the end of L14

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2628961363
PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2628963800

From duke at openjdk.org  Wed Dec 17 23:46:37 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Wed, 17 Dec 2025 23:46:37 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v2]
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <_jbypjS7in5yM7d22qTtOQerMcAupN9w8o5rR2Bzrhw=.64ba2342-0eda-4904-8c5f-3885cb428346@github.com>

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision:

  8184166: add back newline at end of file, mistakenly removed in a previous commit, to ensure no unexpected consequences

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2000/files
  - new: https://git.openjdk.org/jfx/pull/2000/files/48eda6dc..91c5098e

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

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

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

From duke at openjdk.org  Wed Dec 17 23:57:50 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Wed, 17 Dec 2025 23:57:50 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v2]
In-Reply-To: <Lo5qhYl5lm0bnIOzev6TlajkoOOFD76xs6AcfHzjw5c=.5877003d-066d-4811-b2a8-ef55b2295c06@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
 <Lo5qhYl5lm0bnIOzev6TlajkoOOFD76xs6AcfHzjw5c=.5877003d-066d-4811-b2a8-ef55b2295c06@github.com>
Message-ID: <2Y2fTnINyyxXSnSHp43MsJ-bYvI4MAkjzZOXzQ_FsyM=.2e090b08-3ac1-41a0-a63c-de7282d613ab@github.com>

On Wed, 17 Dec 2025 23:27:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8184166: add back newline at end of file, mistakenly removed in a previous commit, to ensure no unexpected consequences
>
> modules/javafx.base/src/main/java/javafx/collections/transformation/SortedList.java line 280:
> 
>> 278: 
>> 279:         // Null out out-of-range array elements to avoid maintaining object references
>> 280:         for (int i = size; i < sorted.length; i++) {
> 
> Don't we need to null the unused entries only when the `sorted` array shrinks (i.e. when the `size` is reduced)?
> 
> so all we do is to handle L259 case `if (c.wasRemoved())` since everywhere else the references are null'ed (L379, L388)?

Yes...and it works fine too if put inside the if(c.wasRemoved()) { } block too but if there are many other additions/permutations _also_ in the change set, then we might be wasting time/CPU nulling indexes that are going to be replaced anyway (i.e., thinking large lists). I felt it was cleaner/safer to just trim at the end of all changes applied in the while loop. 

Let me know what you think. I should add a comment though, at the very least to mention about it only solving the issue related to shrinking. I will do that now.

The other methods you mentioned are only called when a comparator is set, by the way, there's no nulling in this method (updateUnsorted())

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2629004227

From angorya at openjdk.org  Thu Dec 18 00:07:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Dec 2025 00:07:23 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v3]
In-Reply-To: <2Y2fTnINyyxXSnSHp43MsJ-bYvI4MAkjzZOXzQ_FsyM=.2e090b08-3ac1-41a0-a63c-de7282d613ab@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
 <Lo5qhYl5lm0bnIOzev6TlajkoOOFD76xs6AcfHzjw5c=.5877003d-066d-4811-b2a8-ef55b2295c06@github.com>
 <2Y2fTnINyyxXSnSHp43MsJ-bYvI4MAkjzZOXzQ_FsyM=.2e090b08-3ac1-41a0-a63c-de7282d613ab@github.com>
Message-ID: <qs7zi8cpu95jb-1M4bhavTHDBLKAuQYjTQPcUGPgEkw=.7c4929fb-6929-45ce-a63c-00e5c7ecb98c@github.com>

On Wed, 17 Dec 2025 23:55:23 GMT, Cormac Redmond <duke at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/collections/transformation/SortedList.java line 280:
>> 
>>> 278: 
>>> 279:         // Null out out-of-range array elements to avoid maintaining object references
>>> 280:         for (int i = size; i < sorted.length; i++) {
>> 
>> Don't we need to null the unused entries only when the `sorted` array shrinks (i.e. when the `size` is reduced)?
>> 
>> so all we do is to handle L259 case `if (c.wasRemoved())` since everywhere else the references are null'ed (L379, L388)?
>
> Yes...and it works fine too if put inside the if(c.wasRemoved()) { } block too but if there are many other additions/permutations _also_ in the change set, then we might be wasting time/CPU nulling indexes that are going to be replaced anyway (i.e., thinking large lists). I felt it was cleaner/safer to just trim at the end of all changes applied in the while loop.
> 
> Let me know what you think. It can be moved if you prefer. I have added comment anyway in the meantime, to mention why it's needed (i.e., only when shrinking). That's done now.
> 
> The other methods you mentioned are only called when a comparator is set, by the way, there's no nulling in this method (updateUnsorted())

The problem with the current change is we are wasting time/CPU always, instead of doing only what's strictly needed.  Just imagine if the `sorted` array is fairly large and contains only a few items - then you are overwriting many `null` entries with `nulls` needlessly.

Besides, we have the exact number of entries to null out (`c.getRemovedSize()`), which makes the life easier.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2629016001

From duke at openjdk.org  Thu Dec 18 00:07:21 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 18 Dec 2025 00:07:21 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v3]
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <esq3evz_ZQtgeoGGXtCXWY-cWTEnQ85E8VuH-DG98jk=.30c95b28-eafb-49cf-8af8-947921d77874@github.com>

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision:

  8184166: improved comment about why we null the unused elements in sorted array after a change set is applied

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2000/files
  - new: https://git.openjdk.org/jfx/pull/2000/files/91c5098e..c50c72d8

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

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

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

From jhendrikx at openjdk.org  Thu Dec 18 00:08:25 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 18 Dec 2025 00:08:25 GMT
Subject: RFR: 8373885: Compilation failure due to a warning when compiling
 with Java 25
In-Reply-To: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
References: <2r7fPbukPYxrh60plloD3rfZeTF67ZxhWYzWsoEex6E=.4716c3ae-a674-4b24-a0e2-e7ed9c8447e4@github.com>
Message-ID: <VpMRbYpFkzAImcA-I8O5os7BVJJyyaEna253Ag3bX0M=.4d1ffed7-158b-4653-9d31-701d4c7d3977@github.com>

On Wed, 17 Dec 2025 13:43:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
> 
> The following warning appears:
> 
> 
>> Task :controls:compileJava
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                                                                              ^
> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>                              ^
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> 
>> Task :controls:compileJava FAILED
> 
> 
> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/2010#pullrequestreview-3590108101

From duke at openjdk.org  Thu Dec 18 00:14:36 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 18 Dec 2025 00:14:36 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v3]
In-Reply-To: <qs7zi8cpu95jb-1M4bhavTHDBLKAuQYjTQPcUGPgEkw=.7c4929fb-6929-45ce-a63c-00e5c7ecb98c@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
 <Lo5qhYl5lm0bnIOzev6TlajkoOOFD76xs6AcfHzjw5c=.5877003d-066d-4811-b2a8-ef55b2295c06@github.com>
 <2Y2fTnINyyxXSnSHp43MsJ-bYvI4MAkjzZOXzQ_FsyM=.2e090b08-3ac1-41a0-a63c-de7282d613ab@github.com>
 <qs7zi8cpu95jb-1M4bhavTHDBLKAuQYjTQPcUGPgEkw=.7c4929fb-6929-45ce-a63c-00e5c7ecb98c@github.com>
Message-ID: <l1bQ44Pq_gJ9PhvZeLjwGxWlLQcKNqVwzkJaycuSg4Y=.deefa0ae-e28b-48fd-8aef-d9ae2c9b3990@github.com>

On Thu, 18 Dec 2025 00:03:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes...and it works fine too if put inside the if(c.wasRemoved()) { } block too but if there are many other additions/permutations _also_ in the change set, then we might be wasting time/CPU nulling indexes that are going to be replaced anyway (i.e., thinking large lists). I felt it was cleaner/safer to just trim at the end of all changes applied in the while loop.
>> 
>> Let me know what you think. It can be moved if you prefer. I have added comment anyway in the meantime, to mention why it's needed (i.e., only when shrinking). That's done now.
>> 
>> The other methods you mentioned are only called when a comparator is set, by the way, there's no nulling in this method (updateUnsorted())
>
> The problem with the current change is we are wasting time/CPU always, instead of doing only what's strictly needed.  Just imagine if the `sorted` array is fairly large and contains only a few items - then you are overwriting many `null` entries with `nulls` needlessly.
> 
> Besides, we have the exact number of entries to null out (`c.getRemovedSize()`), which makes the life easier.

I must be missing something. I don't see how that situation can occur, if sorted is large but only contains a few items, then the source list must have been large at one point, and shrunk, at which point to excess would be nulled, once.

There's a break there to stop subsequent calls from needlessly nulling anything out on subsequent changes.

On the other hand, putting inside the if statement means we're needlessly removing elements if they're just about to be overwritten from other changes in the same change set.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2629027195

From duke at openjdk.org  Thu Dec 18 00:28:20 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 18 Dec 2025 00:28:20 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v4]
In-Reply-To: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
Message-ID: <RlleEhsLtVmi9NnG4BnK4AJLJiGaGxtdIR8FTPOQdwo=.c30785d2-eb72-44ee-a598-dcaabac2a73f@github.com>

> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
> 
> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.

Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision:

  8184166: Move nulling of out-of-range elements to inside if (c.wasRemoved()) { } block, as this is only where it's required.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2000/files
  - new: https://git.openjdk.org/jfx/pull/2000/files/c50c72d8..d09a85b5

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

  Stats: 15 lines in 1 file changed: 5 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/2000.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/2000/head:pull/2000

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

From duke at openjdk.org  Thu Dec 18 00:28:21 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 18 Dec 2025 00:28:21 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v4]
In-Reply-To: <l1bQ44Pq_gJ9PhvZeLjwGxWlLQcKNqVwzkJaycuSg4Y=.deefa0ae-e28b-48fd-8aef-d9ae2c9b3990@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
 <Lo5qhYl5lm0bnIOzev6TlajkoOOFD76xs6AcfHzjw5c=.5877003d-066d-4811-b2a8-ef55b2295c06@github.com>
 <2Y2fTnINyyxXSnSHp43MsJ-bYvI4MAkjzZOXzQ_FsyM=.2e090b08-3ac1-41a0-a63c-de7282d613ab@github.com>
 <qs7zi8cpu95jb-1M4bhavTHDBLKAuQYjTQPcUGPgEkw=.7c4929fb-6929-45ce-a63c-00e5c7ecb98c@github.com>
 <l1bQ44Pq_gJ9PhvZeLjwGxWlLQcKNqVwzkJaycuSg4Y=.deefa0ae-e28b-48fd-8aef-d9ae2c9b3990@github.com>
Message-ID: <YwBIQEQVUmeFCsWaWSz3wzl245ijhK1lvQOGw51tJfU=.1f815e32-cf04-4690-8c58-fb943666f2de@github.com>

On Thu, 18 Dec 2025 00:11:32 GMT, Cormac Redmond <duke at openjdk.org> wrote:

>> The problem with the current change is we are wasting time/CPU always, instead of doing only what's strictly needed.  Just imagine if the `sorted` array is fairly large and contains only a few items - then you are overwriting many `null` entries with `nulls` needlessly.
>> 
>> Besides, we have the exact number of entries to null out (`c.getRemovedSize()`), which makes the life easier.
>
> I must be missing something. I don't see how that situation can occur, if sorted is large but only contains a few items, then the source list must have been large at one point, and shrunk, at which point the excess would be nulled, once.
> 
> There's a break there to stop subsequent calls from needlessly nulling anything out on subsequent changes.
> 
> On the other hand, putting inside the if statement means we're needlessly removing elements if they're just about to be overwritten from other changes in the same change set.

Anyway, that's moved inside now, and simplified a bit (there's no need for the null check + break any more).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2629045895

From jhendrikx at openjdk.org  Thu Dec 18 02:14:40 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 18 Dec 2025 02:14:40 GMT
Subject: RFR: 8373908: XYChart (ScatteredChart) leaks memory when removing data
Message-ID: <FeeXGT3ozdbLotQPqTDbOqGioiyTLkmNB7PJ5tuEdbI=.dc9805c0-2b94-44cd-b72b-059608ea3678@github.com>

Fixes a problem with leaked references in XYChart.  A few things conspire here to make this into a memory leak:

- The weak bindings used by StringBinding leave behind listener "stubs" when GC'd; that's just how they work, it is a "strong" listener that wraps a weak referenced listener.  The strong part remains behind, and is cleaned up when a new listener is added/removed by ExpressionHelper (and if that never happens, those stubs remain there indefinitely).
- The fluent bindings (map/flatMap/orElse) use normal listeners, but only when they are observed themselves (lazy listeners)
- The "stub" that is left behind counts as being observed, so the fluent bindings don't unsubscribe themselves

The leak has nothing to do with the node or the accessible property, but purely by the StringBinding leaving behind stubs on the flat mapped properties.

The leak is actually because the Series to which the Data object belongs is referencing the Data object.  The flatMaps track the series object so they added a listener to the series object, and they think they are observed indefinitely because of the listener stub.

The easiest solution here is to ensure the Series object is not tracked when not needed; this can be achieved by setting the series to `null` in the ListChangeListener for the Data list.

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

Commit messages:
 - Fix memory leak

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

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

From jhendrikx at openjdk.org  Thu Dec 18 02:19:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 18 Dec 2025 02:19:03 GMT
Subject: RFR: 8373908: XYChart (ScatteredChart) leaks memory when removing
 data [v2]
In-Reply-To: <FeeXGT3ozdbLotQPqTDbOqGioiyTLkmNB7PJ5tuEdbI=.dc9805c0-2b94-44cd-b72b-059608ea3678@github.com>
References: <FeeXGT3ozdbLotQPqTDbOqGioiyTLkmNB7PJ5tuEdbI=.dc9805c0-2b94-44cd-b72b-059608ea3678@github.com>
Message-ID: <r4-NiP80RBVpyO6nDZCg_1OpDlKdqrHNqyLmRcog3tM=.ee3d545a-65bd-489d-a4df-2bd8d6a66d6b@github.com>

> Fixes a problem with leaked references in XYChart.  A few things conspire here to make this into a memory leak:
> 
> - The weak bindings used by StringBinding leave behind listener "stubs" when GC'd; that's just how they work, it is a "strong" listener that wraps a weak referenced listener.  The strong part remains behind, and is cleaned up when a new listener is added/removed by ExpressionHelper (and if that never happens, those stubs remain there indefinitely).
> - The fluent bindings (map/flatMap/orElse) use normal listeners, but only when they are observed themselves (lazy listeners)
> - The "stub" that is left behind counts as being observed, so the fluent bindings don't unsubscribe themselves
> 
> The leak has nothing to do with the node or the accessible property, but purely by the StringBinding leaving behind stubs on the flat mapped properties.
> 
> The leak is actually because the Series to which the Data object belongs is referencing the Data object.  The flatMaps track the series object so they added a listener to the series object, and they think they are observed indefinitely because of the listener stub.
> 
> The easiest solution here is to ensure the Series object is not tracked when not needed; this can be achieved by setting the series to `null` in the ListChangeListener for the Data list.

John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Fix memory leak

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/2013/files
  - new: https://git.openjdk.org/jfx/pull/2013/files/fc08d30a..48e8f296

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

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

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

From lkostyra at openjdk.org  Thu Dec 18 15:13:02 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 18 Dec 2025 15:13:02 GMT
Subject: RFR: 8367557: Extended stage seems to hang after drag and drop
In-Reply-To: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
References: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
Message-ID: <Q7xDm5yTgUxP8m9CfEjXUo_1Y-q4lTo4DRGI7Ezz5Sg=.01c08a90-f065-48a6-bc5e-1e7f6ca45207@github.com>

On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> An extended stage seems to hang after a drag and drop operation. Note that in the attached reproducer, the application seems unresponsive until the mouse cursor leaves and re-enters the application window:
> 
> 
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.Label;
> import javafx.scene.input.ClipboardContent;
> import javafx.scene.input.Dragboard;
> import javafx.scene.input.TransferMode;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.HBox;
> import javafx.scene.layout.HeaderBar;
> import javafx.stage.Stage;
> import javafx.stage.StageStyle;
> 
> public class DragDropTest extends Application {
> 
>     @Override
>     public void start(Stage primaryStage) {
> 
>         primaryStage.initStyle(StageStyle.EXTENDED);
> 
>         // Create drag source
>         Label dragSource = new Label("Drag me!");
>         dragSource.setStyle("-fx-background-color: lightblue; -fx-padding: 10px");
> 
>         // Create drop target
>         Label dropTarget = new Label("Drop here!");
>         dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;");
> 
>         // Set up drag detection
>         dragSource.setOnDragDetected(event -> {
>             Dragboard dragboard = dragSource.startDragAndDrop(TransferMode.COPY);
>             ClipboardContent content = new ClipboardContent();
>             content.putString("Hello from drag source!");
>             dragboard.setContent(content);
>             event.consume();
>         });
> 
>         // Set up drag over
>         dropTarget.setOnDragOver(event -> {
>             if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) {
>                 event.acceptTransferModes(TransferMode.COPY);
>             }
>             event.consume();
>         });
> 
>         // Set up drag entered (visual feedback)
>         dropTarget.setOnDragEntered(event -> {
>             if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) {
>                 dropTarget.setStyle("-fx-background-color: lightgreen; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;");
>             }
>             event.consume();
>         });
> 
>         // Set up drag exited (reset visual feedback)
>         dropTarget.setOnDragExited(event -> {
>             dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;");
>             event.consume();
>         });
> 
>         // Set up drop
>         dropTarget.setOnD...

LGTM, is working properly on Windows.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/2003#pullrequestreview-3593505428

From angorya at openjdk.org  Thu Dec 18 16:05:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Dec 2025 16:05:28 GMT
Subject: RFR: 8184166: SortedList does not free up memory [v4]
In-Reply-To: <RlleEhsLtVmi9NnG4BnK4AJLJiGaGxtdIR8FTPOQdwo=.c30785d2-eb72-44ee-a598-dcaabac2a73f@github.com>
References: <C37OfEK7RJHV3gO4XUSdetLIM-J6yGVhwV3-rMR3OU4=.33641de8-7ed3-455d-8130-5c240f20f1f5@github.com>
 <RlleEhsLtVmi9NnG4BnK4AJLJiGaGxtdIR8FTPOQdwo=.c30785d2-eb72-44ee-a598-dcaabac2a73f@github.com>
Message-ID: <liG1dyodkfvjq7tzPDtUe0Qtn7CFEy-0OR_QacaK4K4=.0f350149-43cf-4a2c-8ae3-979cc0e1a357@github.com>

On Thu, 18 Dec 2025 00:28:20 GMT, Cormac Redmond <duke at openjdk.org> wrote:

>> Fix SortedList memory leak by clearing unused entries in the internal array when the source list shrinks. Also nullify tempElement.e after use,
>> 
>> Adding "--add-opens=javafx.base/javafx.collections.transformation=ALL-UNNAMED" to allow reflection access from tests.
>
> Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8184166: Move nulling of out-of-range elements to inside if (c.wasRemoved()) { } block, as this is only where it's required.

modules/javafx.base/src/main/java/javafx/collections/transformation/SortedList.java line 267:

> 265: 
> 266:                 // Null out out-of-range array elements to avoid maintaining object references
> 267:                 for (int i = size; i < (size + c.getRemovedSize()); i++) {

minor suggestion:

int ct = size + c.getRemovedSize();
for (int i = size; i < ct; i++) {

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2000#discussion_r2631666885

From angorya at openjdk.org  Thu Dec 18 16:43:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Dec 2025 16:43:48 GMT
Subject: RFR: 8373908: XYChart (ScatteredChart) leaks memory when removing
 data [v2]
In-Reply-To: <r4-NiP80RBVpyO6nDZCg_1OpDlKdqrHNqyLmRcog3tM=.ee3d545a-65bd-489d-a4df-2bd8d6a66d6b@github.com>
References: <FeeXGT3ozdbLotQPqTDbOqGioiyTLkmNB7PJ5tuEdbI=.dc9805c0-2b94-44cd-b72b-059608ea3678@github.com>
 <r4-NiP80RBVpyO6nDZCg_1OpDlKdqrHNqyLmRcog3tM=.ee3d545a-65bd-489d-a4df-2bd8d6a66d6b@github.com>
Message-ID: <vg9VMRQwvqKROhBKwTFJGJ5lLy9zKmZZQUDKNHtN9w0=.9aef9616-7625-49f3-ad18-e501bca70e72@github.com>

On Thu, 18 Dec 2025 02:19:03 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes a problem with leaked references in XYChart.  A few things conspire here to make this into a memory leak:
>> 
>> - The weak bindings used by StringBinding leave behind listener "stubs" when GC'd; that's just how they work, it is a "strong" listener that wraps a weak referenced listener.  The strong part remains behind, and is cleaned up when a new listener is added/removed by ExpressionHelper (and if that never happens, those stubs remain there indefinitely).
>> - The fluent bindings (map/flatMap/orElse) use normal listeners, but only when they are observed themselves (lazy listeners)
>> - The "stub" that is left behind counts as being observed, so the fluent bindings don't unsubscribe themselves
>> 
>> The leak has nothing to do with the node or the accessible property, but purely by the StringBinding leaving behind stubs on the flat mapped properties.
>> 
>> The leak is actually because the Series to which the Data object belongs is referencing the Data object.  The flatMaps track the series object so they added a listener to the series object, and they think they are observed indefinitely because of the listener stub.
>> 
>> The easiest solution here is to ensure the Series object is not tracked when not needed; this can be achieved by setting the series to `null` in the ListChangeListener for the Data list.
>
> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix memory leak

Excellent work, the memory leak is fixed, thank you so much @hjohn !

<img width="706" height="421" alt="Screenshot 2025-12-18 at 08 36 17" src="https://github.com/user-attachments/assets/f555a51d-c446-4a55-bbbf-469afddb9f68" />


Questions:

1. the seriesProperty holds the same object as the series field, can we remove the field?
2. could we apply the same treatment to PieChart (perhaps in a followup, unless it's an easy fix)?
3. perhaps, as a followup, we ought to add a parameterized test to make sure all other charts don't exhibit the same issue?

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

PR Comment: https://git.openjdk.org/jfx/pull/2013#issuecomment-3671158947

From angorya at openjdk.org  Thu Dec 18 17:33:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Dec 2025 17:33:11 GMT
Subject: RFR: 8373908: XYChart (ScatteredChart) leaks memory when removing
 data [v2]
In-Reply-To: <r4-NiP80RBVpyO6nDZCg_1OpDlKdqrHNqyLmRcog3tM=.ee3d545a-65bd-489d-a4df-2bd8d6a66d6b@github.com>
References: <FeeXGT3ozdbLotQPqTDbOqGioiyTLkmNB7PJ5tuEdbI=.dc9805c0-2b94-44cd-b72b-059608ea3678@github.com>
 <r4-NiP80RBVpyO6nDZCg_1OpDlKdqrHNqyLmRcog3tM=.ee3d545a-65bd-489d-a4df-2bd8d6a66d6b@github.com>
Message-ID: <hLLmXzrxhxnf8B7RZr72DfzAbj5R3Yylrz2SVI4xzkU=.8e98b6c4-4d8a-4056-899b-95f679362961@github.com>

On Thu, 18 Dec 2025 02:19:03 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes a problem with leaked references in XYChart.  A few things conspire here to make this into a memory leak:
>> 
>> - The weak bindings used by StringBinding leave behind listener "stubs" when GC'd; that's just how they work, it is a "strong" listener that wraps a weak referenced listener.  The strong part remains behind, and is cleaned up when a new listener is added/removed by ExpressionHelper (and if that never happens, those stubs remain there indefinitely).
>> - The fluent bindings (map/flatMap/orElse) use normal listeners, but only when they are observed themselves (lazy listeners)
>> - The "stub" that is left behind counts as being observed, so the fluent bindings don't unsubscribe themselves
>> 
>> The leak has nothing to do with the node or the accessible property, but purely by the StringBinding leaving behind stubs on the flat mapped properties.
>> 
>> The leak is actually because the Series to which the Data object belongs is referencing the Data object.  The flatMaps track the series object so they added a listener to the series object, and they think they are observed indefinitely because of the listener stub.
>> 
>> The easiest solution here is to ensure the Series object is not tracked when not needed; this can be achieved by setting the series to `null` in the ListChangeListener for the Data list.
>
> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix memory leak

FYI: don't see this issue with the PieChart
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/PieChart_OOM_8373909.java

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

PR Comment: https://git.openjdk.org/jfx/pull/2013#issuecomment-3671346500