From mstrauss at openjdk.org Sun Jun 1 21:46:35 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 1 Jun 2025 21:46:35 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window Message-ID: `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. ------------- Commit messages: - use EventHandlerProperty Changes: https://git.openjdk.org/jfx/pull/1819/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1819&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358255 Stats: 793 lines in 2 files changed: 50 ins; 694 del; 49 mod Patch: https://git.openjdk.org/jfx/pull/1819.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1819/head:pull/1819 PR: https://git.openjdk.org/jfx/pull/1819 From gpattnaik at openjdk.org Mon Jun 2 09:07:16 2025 From: gpattnaik at openjdk.org (Gopal Pattnaik) Date: Mon, 2 Jun 2025 09:07:16 GMT Subject: [jfx24u] RFR: 8354940: Fail to sign in to Microsoft sites with WebView Message-ID: A clean backport to jfx24u. This is a webkit fix, need to be back ported for the sources sync with the mainline. ------------- Commit messages: - Backport ac12979bc3100cf4f263a38669a59dac2b71fdce Changes: https://git.openjdk.org/jfx24u/pull/27/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=27&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354940 Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx24u/pull/27.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/27/head:pull/27 PR: https://git.openjdk.org/jfx24u/pull/27 From jvos at openjdk.org Mon Jun 2 10:03:10 2025 From: jvos at openjdk.org (Johan Vos) Date: Mon, 2 Jun 2025 10:03:10 GMT Subject: [jfx21u] RFR: 8354940: Fail to sign in to Microsoft sites with WebView Message-ID: Hi all, This pull request contains a backport of commit ac12979b from the openjdk/jfx repository. The commit being backported was authored by Gopal Pattnaik on 22 May 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar. Thanks! ------------- Commit messages: - Backport ac12979bc3100cf4f263a38669a59dac2b71fdce Changes: https://git.openjdk.org/jfx21u/pull/99/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=99&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354940 Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/99.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/99/head:pull/99 PR: https://git.openjdk.org/jfx21u/pull/99 From jvos at openjdk.org Mon Jun 2 10:03:39 2025 From: jvos at openjdk.org (Johan Vos) Date: Mon, 2 Jun 2025 10:03:39 GMT Subject: [jfx17u] RFR: 8354940: Fail to sign in to Microsoft sites with WebView Message-ID: Hi all, This pull request contains a backport of commit ac12979b from the openjdk/jfx repository. The commit being backported was authored by Gopal Pattnaik on 22 May 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar. Thanks! ------------- Commit messages: - Backport ac12979bc3100cf4f263a38669a59dac2b71fdce Changes: https://git.openjdk.org/jfx17u/pull/237/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354940 Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/237.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/237/head:pull/237 PR: https://git.openjdk.org/jfx17u/pull/237 From jhendrikx at openjdk.org Mon Jun 2 10:16:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 2 Jun 2025 10:16:04 GMT Subject: RFR: 8345348: CSS media feature queries [v27] In-Reply-To: <8J82wwQko11-toLs4WDZii_ah2_97_0LPvNGsZ6IEMc=.eefcaf40-d263-402f-9e56-e1edf97af454@github.com> References: <8J82wwQko11-toLs4WDZii_ah2_97_0LPvNGsZ6IEMc=.eefcaf40-d263-402f-9e56-e1edf97af454@github.com> Message-ID: <8y6mlgBUoUOGibOXPXrf2CpXLjzpxERPaV7K7BfKk7k=.ec018877-aa97-4a90-8ca6-085e59e8acb6@github.com> On Thu, 29 May 2025 15:47:20 GMT, Michael Strau? wrote: >> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > reorder Scene.Preferences.colorScheme Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2887688438 From thiago.sayao at gmail.com Mon Jun 2 11:36:03 2025 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 2 Jun 2025 08:36:03 -0300 Subject: Font on Ubuntu 24.04 Message-ID: Hi, For some reason when using the Ubuntu font-family, bold is not working - it chooses the Ubuntu Regular font. It works on Ubuntu 20.04, and does not work on Ubuntu 24.04. Something probably changed and needs to be updated on JavaFX. public class FontTest extends Application { @Override public void start(final Stage stage) throws Exception { Label label = new Label(); Label label2 = new Label(); label2.setStyle("-fx-font-weight: bold;"); Label label3 = new Label(); label3.setStyle("-fx-font-weight: bolder;"); Label label4 = new Label(); label4.setStyle("-fx-font-style: italic;"); VBox vBox = new VBox(label, label2, label3, label4); vBox.setStyle("-fx-font-family: Ubuntu"); Scene scene = new Scene(vBox, 200, 200); stage.setScene(scene); stage.setOnShown(e -> Platform.runLater(() -> List.of(label, label2, label3, label4).forEach(l -> l.setText(l.getFont().getName())))); stage.show(); } public static void main(String... args) { Application.launch(FontTest.class, args); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Mon Jun 2 15:16:23 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Jun 2025 15:16:23 GMT Subject: RFR: 8345348: CSS media feature queries [v28] In-Reply-To: References: Message-ID: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'master' into feature/media-queries - doc - reorder Scene.Preferences.colorScheme - move doc from Scene.Preferences to Platform.Preferences - Merge branch 'master' into feature/media-queries - add -fx vendor prefix to prefers-persistent-scrollbars - cssref documentation changes - added test - canonical modifier order - improve synchronization in PreferenceProperties - ... and 34 more: https://git.openjdk.org/jfx/compare/5d367530...25f369cd ------------- Changes: https://git.openjdk.org/jfx/pull/1655/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=27 Stats: 5272 lines in 42 files changed: 4110 ins; 1048 del; 114 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From arapte at openjdk.org Mon Jun 2 15:41:03 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 2 Jun 2025 15:41:03 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v4] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 16:09:52 GMT, Ziad El Midaoui wrote: >> When the Root TreeItem is set to null, need to relayout to show the children items > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Minor change : new line added modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java line 343: > 341: requestRebuildCells(); > 342: } > 343: This method updateItemCount() is invoked for multiple scenarios. Like for a scenario when a TreeItem is added or removed to root item. In this scenario, the issue does not occur as the root item is not changed and so it is not required to rebuild the cells. The reported issue occurs only when the root item itself is changed. So, I think the fix should be added to a listener to root item. i.e. `lh.addChangeListener(control.rootProperty(), true, (src, prev, root) -> {` --- a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java @@ -164,6 +164,10 @@ public class TreeTableViewSkin extends TableViewSkinBase, Tree } // fix for JDK-8094887 control.edit(-1, null); + + if (root == null || root.getValue() == null) { + requestRebuildCells(); + } updateItemCount(); }); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1767#discussion_r2121531809 From kevin.rushforth at oracle.com Mon Jun 2 21:35:15 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 2 Jun 2025 14:35:15 -0700 Subject: JavaFX 24.0.2 will be closed for fixes on June 9th Message-ID: <23d1bcb2-ade2-464f-abd4-785440384c26@oracle.com> All, If you have backports that you want to get into jfx24u for JavaFX 24.0.2, please do so by Monday, June 9th. 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-January/051817.html From bdunkley-smith at bigpond.com Tue Jun 3 00:33:02 2025 From: bdunkley-smith at bigpond.com (Bryon Dunkley-Smith) Date: Tue, 3 Jun 2025 10:33:02 +1000 Subject: JavaFX MediaView Problem After Win10 to Win11 Update Message-ID: <001301dbd41f$10e688a0$32b399e0$@bigpond.com> Hi All, First time poster and so I trust this is an appropriate question to ask here. I have a legacy JavaFX based application which in part displays a sequence of short (.MP4) videos which has functioned flawlessly for several years as demonstrated here https://www.youtube.com/watch?v=CMv6z_SIUXU. But since upgrading the laptop on which it runs from Win10 to Win11 some months ago, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown. I have tried many code changes to fix this unsuccessfully however a common "fix" across several machines is always just running it on a Win10 machine. I note there is an unresolved bug report Video sometimes does not start when reinitializing in Windows 11 https://bugs.openjdk.org/browse/JDK-8305842 which appears relevant. So I am wondering if others have encountered this problem and whether there is a plan to resolve this bug in an upcoming JavaFX release. Thanks, Bryon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Tue Jun 3 01:08:33 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 01:08:33 GMT Subject: RFR: 8345348: CSS media feature queries [v29] In-Reply-To: References: Message-ID: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix wrong
HTML tags ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1655/files - new: https://git.openjdk.org/jfx/pull/1655/files/25f369cd..ccecda9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=28 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=27-28 Stats: 24 lines in 1 file changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From mstrauss at openjdk.org Tue Jun 3 01:18:30 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 01:18:30 GMT Subject: RFR: 8358454: Wrong
tags in cssref.html Message-ID: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> Some `
` tags in cssref.html are written as `
` or `
`. It should be `
`, since it is a void element. A single reviewer is sufficient. ------------- Commit messages: - fix wrong
HTML tags Changes: https://git.openjdk.org/jfx/pull/1820/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1820&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358454 Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1820.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1820/head:pull/1820 PR: https://git.openjdk.org/jfx/pull/1820 From duke at openjdk.org Tue Jun 3 05:31:59 2025 From: duke at openjdk.org (duke) Date: Tue, 3 Jun 2025 05:31:59 GMT Subject: [jfx24u] RFR: 8354940: Fail to sign in to Microsoft sites with WebView In-Reply-To: References: Message-ID: <3VvpUl5zHlOSVmxcYT8otawTbrmV4geN6Z6lLyGom28=.e58f013d-dd87-4193-b94e-b1e717e75e15@github.com> On Mon, 2 Jun 2025 09:02:34 GMT, Gopal Pattnaik wrote: > A clean backport to jfx24u. This is a webkit fix, need to be back ported for the sources sync with the mainline. @Gopalora Your change (at version 749cc2446bbc0fa28a92fc93616ede9e8f384611) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx24u/pull/27#issuecomment-2933502721 From zelmidaoui at openjdk.org Tue Jun 3 11:08:01 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 3 Jun 2025 11:08:01 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v4] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 15:38:04 GMT, Ambarish Rapte wrote: >> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor change : new line added > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java line 343: > >> 341: requestRebuildCells(); >> 342: } >> 343: > > This method updateItemCount() is invoked for multiple scenarios. > Like for a scenario when a TreeItem is added or removed to root item. In this scenario, the issue does not occur as the root item is not changed and so it is not required to rebuild the cells. > > The reported issue occurs only when the root item itself is changed. > So, I think the fix should be added to a listener to root item. i.e. `lh.addChangeListener(control.rootProperty(), true, (src, prev, root) -> {` > > > --- a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java > +++ b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableViewSkin.java > @@ -164,6 +164,10 @@ public class TreeTableViewSkin extends TableViewSkinBase, Tree > } > // fix for JDK-8094887 > control.edit(-1, null); > + > + if (root == null || root.getValue() == null) { > + requestRebuildCells(); > + } > updateItemCount(); > }); Yes, It is actually more appropriate to put it there, I will push the new changes Thank you for your suggestion. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1767#discussion_r2123471614 From zelmidaoui at openjdk.org Tue Jun 3 11:12:19 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 3 Jun 2025 11:12:19 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v5] In-Reply-To: References: Message-ID: > When the Root TreeItem is set to null, need to relayout to show the children items Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem - Adding fix to root item listener ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1767/files - new: https://git.openjdk.org/jfx/pull/1767/files/dc0de460..70b5e34c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1767&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1767&range=03-04 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1767.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1767/head:pull/1767 PR: https://git.openjdk.org/jfx/pull/1767 From gpattnaik at openjdk.org Tue Jun 3 12:14:05 2025 From: gpattnaik at openjdk.org (Gopal Pattnaik) Date: Tue, 3 Jun 2025 12:14:05 GMT Subject: [jfx24u] Integrated: 8354940: Fail to sign in to Microsoft sites with WebView In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 09:02:34 GMT, Gopal Pattnaik wrote: > A clean backport to jfx24u. This is a webkit fix, need to be back ported for the sources sync with the mainline. This pull request has now been integrated. Changeset: 4e5160f3 Author: Gopal Pattnaik Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx24u/commit/4e5160f38daca0a6623af56c7e16045d1cd0227a Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod 8354940: Fail to sign in to Microsoft sites with WebView Backport-of: ac12979bc3100cf4f263a38669a59dac2b71fdce ------------- PR: https://git.openjdk.org/jfx24u/pull/27 From arapte at openjdk.org Tue Jun 3 12:15:06 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 3 Jun 2025 12:15:06 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v5] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:12:19 GMT, Ziad El Midaoui wrote: >> When the Root TreeItem is set to null, need to relayout to show the children items > > Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Adding fix to root item listener LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1767#pullrequestreview-2892069492 From kevin.rushforth at oracle.com Tue Jun 3 12:24:36 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Jun 2025 05:24:36 -0700 Subject: JavaFX MediaView Problem After Win10 to Win11 Update In-Reply-To: <001301dbd41f$10e688a0$32b399e0$@bigpond.com> References: <001301dbd41f$10e688a0$32b399e0$@bigpond.com> Message-ID: <52d450be-fa2b-4b53-baa2-e8a00b79e4ae@oracle.com> Another possibly related bug is https://bugs.openjdk.org/browse/JDK-8329227 which is fixed in JavaFX 25 ea build 14. You might try running with the latest JavaFX 25 build and see if that helps. If not, then it does seem likely that you are hitting https://bugs.openjdk.org/browse/JDK-8305842 which is being evaluated. -- Kevin On 6/2/2025 5:33 PM, Bryon Dunkley-Smith wrote: > > Hi All, > > First time poster and so I trust this is an appropriate question to > ask here. > > I have a legacy JavaFX based application which in part displays a > sequence of short (.MP4) videos which has functioned flawlessly for > several years as demonstrated here > https://www.youtube.com/watch?v=CMv6z_SIUXU. But since upgrading the > laptop on which it runs from Win10 to Win11 some months ago, there has > been intermittent/random failures of videos playing with a > ERROR_MEDIA_INVALID being thrown. I have tried many code changes to > fix this unsuccessfully however a common ?fix? across several machines > is always just running it on a Win10 machine. > > I note there is an unresolved bug report Video sometimes does not > start when reinitializing in Windows 11 > https://bugs.openjdk.org/browse/JDK-8305842 which appears relevant. > > So I am wondering if others have encountered this problem and whether > there is a plan to resolve this bug in an upcoming JavaFX release. > > Thanks, > > Bryon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zelmidaoui at openjdk.org Tue Jun 3 13:23:35 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 3 Jun 2025 13:23:35 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v6] In-Reply-To: References: Message-ID: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> > When the Root TreeItem is set to null, need to relayout to show the children items 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 eight additional commits since the last revision: - Merge branch 'openjdk:master' into 8341281.RootTreeItem - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem - Minor change : new line added - Adding fix to root item listener - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem - Merge branch 'openjdk:master' into 8341281.RootTreeItem - Headfull Test added - Fixed issue with TreeTableView not showing the root's children when set to null ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1767/files - new: https://git.openjdk.org/jfx/pull/1767/files/70b5e34c..5c55cc0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1767&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1767&range=04-05 Stats: 313 lines in 20 files changed: 303 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1767.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1767/head:pull/1767 PR: https://git.openjdk.org/jfx/pull/1767 From zelmidaoui at openjdk.org Tue Jun 3 13:48:59 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 3 Jun 2025 13:48:59 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v6] In-Reply-To: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> References: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> Message-ID: On Tue, 3 Jun 2025 13:23:35 GMT, Ziad El Midaoui wrote: >> When the Root TreeItem is set to null, need to relayout to show the children items > > 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 eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Minor change : new line added > - Adding fix to root item listener > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Headfull Test added > - Fixed issue with TreeTableView not showing the root's children when set to null I will integrate the changes by end of day if no more comments ------------- PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2935339116 From jvos at openjdk.org Tue Jun 3 13:52:58 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Jun 2025 13:52:58 GMT Subject: [jfx17u] Integrated: 8354940: Fail to sign in to Microsoft sites with WebView In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 09:58:58 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit ac12979b from the openjdk/jfx repository. > > The commit being backported was authored by Gopal Pattnaik on 22 May 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar. > > Thanks! This pull request has now been integrated. Changeset: 32a0e9ef Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/32a0e9ef6c9efac57de600e8fb8064b0e2497e28 Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod 8354940: Fail to sign in to Microsoft sites with WebView Backport-of: ac12979bc3100cf4f263a38669a59dac2b71fdce ------------- PR: https://git.openjdk.org/jfx17u/pull/237 From jvos at openjdk.org Tue Jun 3 13:54:03 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Jun 2025 13:54:03 GMT Subject: [jfx21u] Integrated: 8354940: Fail to sign in to Microsoft sites with WebView In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 09:58:32 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit ac12979b from the openjdk/jfx repository. > > The commit being backported was authored by Gopal Pattnaik on 22 May 2025 and was reviewed by Kevin Rushforth and Jay Bhaskar. > > Thanks! This pull request has now been integrated. Changeset: 5402bf20 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/5402bf209a7b64d85fe67413e2bcbe62d6bac022 Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod 8354940: Fail to sign in to Microsoft sites with WebView Backport-of: ac12979bc3100cf4f263a38669a59dac2b71fdce ------------- PR: https://git.openjdk.org/jfx21u/pull/99 From angorya at openjdk.org Tue Jun 3 14:40:02 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Jun 2025 14:40:02 GMT Subject: RFR: 8358454: Wrong
tags in cssref.html In-Reply-To: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> References: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> Message-ID: On Tue, 3 Jun 2025 01:14:04 GMT, Michael Strau? wrote: > Some `
` tags in cssref.html are written as `
` or `
`. It should be `
`, since it is a void element. > > A single reviewer is sufficient. left minor comments, otherwise looks good. modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1682: > 1680:

<easing-function>

> 1681:

linear | <cubic-bezier-easing-function> | <step-easing-function> | <fx-easing-function>

> 1682:

Linear linear
why is Linear looks like plain `linear` but Cubic B?zier Easing Functions has triangular brackets ``? modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1733: > 1731: steps > 1732: defines a step function with <integer> intervals > 1733: and an optional <step-position>;
if omitted, possible future enhancement: add thin grid lines to the tables, similar to other tables. ------------- PR Review: https://git.openjdk.org/jfx/pull/1820#pullrequestreview-2892762843 PR Review Comment: https://git.openjdk.org/jfx/pull/1820#discussion_r2124053590 PR Review Comment: https://git.openjdk.org/jfx/pull/1820#discussion_r2124058977 From mstrauss at openjdk.org Tue Jun 3 14:49:00 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 14:49:00 GMT Subject: RFR: 8358454: Wrong
tags in cssref.html In-Reply-To: References: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> Message-ID: <_a_famVlMR5iZav--xuihJNig5Q8igB5wfLiWQV44Fw=.208a19a6-9a7e-48fb-99fb-105367de37bc@github.com> On Tue, 3 Jun 2025 14:34:11 GMT, Andy Goryachev wrote: >> Some `
` tags in cssref.html are written as `
` or `
`. It should be `
`, since it is a void element. >> >> A single reviewer is sufficient. > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1682: > >> 1680:

<easing-function>

>> 1681:

linear | <cubic-bezier-easing-function> | <step-easing-function> | <fx-easing-function>

>> 1682:

Linear linear
> > why is Linear looks like plain `linear` but Cubic B?zier Easing Functions has triangular brackets ``? `linear` is a concrete value, whereas `` is defined later to be one of five possible concrete values. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1820#discussion_r2124095586 From angorya at openjdk.org Tue Jun 3 15:10:56 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Jun 2025 15:10:56 GMT Subject: RFR: 8358454: Wrong
tags in cssref.html In-Reply-To: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> References: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> Message-ID: On Tue, 3 Jun 2025 01:14:04 GMT, Michael Strau? wrote: > Some `
` tags in cssref.html are written as `
` or `
`. It should be `
`, since it is a void element. > > A single reviewer is sufficient. Marked as reviewed by angorya (Reviewer). minor doc changes, a single reviewer is probably sufficient. ------------- PR Review: https://git.openjdk.org/jfx/pull/1820#pullrequestreview-2892943992 PR Comment: https://git.openjdk.org/jfx/pull/1820#issuecomment-2935851630 From angorya at openjdk.org Tue Jun 3 15:14:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Jun 2025 15:14:57 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v6] In-Reply-To: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> References: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> Message-ID: On Tue, 3 Jun 2025 13:23:35 GMT, Ziad El Midaoui wrote: >> When the Root TreeItem is set to null, need to relayout to show the children items > > 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 eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Minor change : new line added > - Adding fix to root item listener > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Headfull Test added > - Fixed issue with TreeTableView not showing the root's children when set to null looks good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1767#pullrequestreview-2892970533 From angorya at openjdk.org Tue Jun 3 15:27:04 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Jun 2025 15:27:04 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strau? wrote: > `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. I like it very much. Also saves a few bytes. It's a trivial change, one reviewer is probably enough, but two is always better. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1819#pullrequestreview-2893041303 From kcr at openjdk.org Tue Jun 3 15:35:34 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Jun 2025 15:35:34 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strau? wrote: > `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. @arapte can be the second reviewer ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936001648 From nlisker at openjdk.org Tue Jun 3 16:12:59 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 3 Jun 2025 16:12:59 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strau? wrote: > `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. I've tried to do something similar for controls by replacing a lot of the anonymous classes with concrete ones. I can't find the issue/discussion right now, but Kevin measured a non-negligible increase in memory usage. I assume it's because constant folding is doable for the constants in the methods of the anonymous class, but not for the final fields in the concrete property (because they are not really final when considering reflection). Because an application doesn't have a lot of windows and scenes, it's possible that these changes won't have detrimental effects, but I suggest measuring. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936156979 From angorya at openjdk.org Tue Jun 3 16:29:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Jun 2025 16:29:57 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strau? wrote: > `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. To clarify, the difference is as follows: - on per-class basis, we are saving a few kilobytes by replacing a bunch of class data structures with one (with two, one for `Scene` and one for `Window`) - on per-instance basis, we are adding 2 pointers multiplied by the number of properties (39 for `Scene`), multiplied by the number of instances of `Scene`/`Windows`. So depending on the application, it might be a net win for a small app, or more memory used when the app devs create hundreds of windows and keep them hidden (I've seen those). Still, I think it's a good change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936218550 From kcr at openjdk.org Tue Jun 3 16:34:09 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Jun 2025 16:34:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v75] In-Reply-To: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com> References: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com> Message-ID: On Tue, 20 May 2025 19:01:26 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'master' into feature/extended-window > - javadoc > - Merge branch 'master' into feature/extended-window > - reapply overlay CSS > - Merge branch 'master' into feature/extended-window > - simplify header area picking > - Fix top resize border on Windows > - Merge branch 'master' into feature/extended-window > - doc change > - add HeaderDragType > - ... and 86 more: https://git.openjdk.org/jfx/compare/a14c2b33...dcbb68d0 I ran this through our CI build (after merging the latest master) and I get these failures: modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp: In member function 'virtual void WindowContextTop::show_system_menu(int, int)': modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp:1414:39: error: invalid conversion from 'gpointer' {aka 'void*'} to 'GdkWindow*' {aka '_GdkWindow*'} [-fpermissive] 1414 | buttonEvent->window = g_object_ref(gdk_window); | ~~~~~~~~~~~~^~~~~~~~~~~~ | | | gpointer {aka void*} modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp:1415:39: error: invalid conversion from 'gpointer' {aka 'void*'} to 'GdkDevice*' {aka '_GdkDevice*'} [-fpermissive] 1415 | buttonEvent->device = g_object_ref(device); | ~~~~~~~~~~~~^~~~~~~~ | | | gpointer {aka void*} > Task :graphics:ccLinuxGlassGlassgtk3 FAILED Our production CI systems compile against an older version of gtk3, which is likely the reason. This will need to be fixed using an explicit cast. A quick test shows that this fixes the problem. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2936232000 From mstrauss at openjdk.org Tue Jun 3 16:34:57 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 16:34:57 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 16:10:18 GMT, Nir Lisker wrote: > I've tried to do something similar for controls by replacing a lot of the anonymous classes with concrete ones. I can't find the issue/discussion right now, but Kevin measured a non-negligible increase in memory usage. I assume it's because constant folding is doable for the constants in the methods of the anonymous class, but not for the final fields in the concrete property (because they are not really final when considering reflection). > > Because an application doesn't have a lot of windows and scenes, it's possible that these changes won't have detrimental effects, but I suggest measuring. I don't think there's any constant folding here, because methods like `getName()` are not constant expressions. You can always alias a property instance dynamically by referencing, which is why the compiler can't inline the value into the calling expression. That being said, of course the nominal class stores two additional fields that the anonymous class didn't. But it doesn't store any more than that: the name strings come from literal expressions and are therefore interned, and the event types are references to static instances. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936235353 From mstrauss at openjdk.org Tue Jun 3 16:37:57 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 16:37:57 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 16:27:15 GMT, Andy Goryachev wrote: > when the app devs create hundreds of windows and keep them hidden (I've seen those) ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936246666 From jhendrikx at openjdk.org Tue Jun 3 16:47:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Jun 2025 16:47:04 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: <6g_-aP3sAZMj4hUsFk2Bg1tTYF9iiAsdQmzlwwkKH_g=.1e795605-4458-4c36-92e7-c1e0e70a7289@github.com> On Tue, 3 Jun 2025 16:32:21 GMT, Michael Strau? wrote: > I've tried to do something similar for controls by replacing a lot of the anonymous classes with concrete ones. I can't find the issue/discussion right now, but Kevin measured a non-negligible increase in memory usage. I assume it's because constant folding is doable for the constants in the methods of the anonymous class, but not for the final fields in the concrete property (because they are not really final when considering reflection). > > Because an application doesn't have a lot of windows and scenes, it's possible that these changes won't have detrimental effects, but I suggest measuring. I think that's not really needed; we'd be crippling any FX improvements if the criteria is that we can't use more memory than before? The better question is, is having less classes (improving the **common** case), and less code an acceptable trade-off versus the case where you have hundreds or thousands of scenes and windows? I think it is. These classes weigh-in at thousands of bytes already (and far more once their peer is created); we're not doing anyone any favors by being overly cautious here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936263900 From kcr at openjdk.org Tue Jun 3 16:47:06 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Jun 2025 16:47:06 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: <_vhtdAlSFW8FKqLAuUTfBXD0SzuU9VGNBZiqKlFwWsI=.9bc85e3e-2f0e-4ccb-9dc6-14917ec9e91b@github.com> On Tue, 3 Jun 2025 16:35:50 GMT, Michael Strau? wrote: > > when the app devs create hundreds of windows and keep them hidden (I've seen those) > > ? Window and Scene are heavy-weight classes that are reasonably limited in quantity, so I'm not at all worried about this. The concern I raised earlier (as I recall) was about properties in nodes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936270199 From mstrauss at openjdk.org Tue Jun 3 16:51:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 16:51:47 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v76] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: - add explicit cast in glass_window.cpp - Merge branch 'master' into feature/extended-window - Merge branch 'master' into feature/extended-window - javadoc - Merge branch 'master' into feature/extended-window - reapply overlay CSS - Merge branch 'master' into feature/extended-window - simplify header area picking - Fix top resize border on Windows - Merge branch 'master' into feature/extended-window - ... and 88 more: https://git.openjdk.org/jfx/compare/5d367530...b85f72f3 ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=75 Stats: 6805 lines in 76 files changed: 6114 ins; 517 del; 174 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From kcr at openjdk.org Tue Jun 3 16:51:48 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Jun 2025 16:51:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v75] In-Reply-To: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com> References: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com> Message-ID: <_Mj_gLo9_Vl6HbedOFpt6un-sRW8l4fzPsEgyE5yUQI=.ceef0395-20b4-4461-bfec-75efa7d657e9@github.com> On Tue, 20 May 2025 19:01:26 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'master' into feature/extended-window > - javadoc > - Merge branch 'master' into feature/extended-window > - reapply overlay CSS > - Merge branch 'master' into feature/extended-window > - simplify header area picking > - Fix top resize border on Windows > - Merge branch 'master' into feature/extended-window > - doc change > - add HeaderDragType > - ... and 86 more: https://git.openjdk.org/jfx/compare/a14c2b33...dcbb68d0 FYI, I am using the [test-pr-1605](https://github.com/kevinrushforth/jfx/tree/refs/heads/test-pr-1605) branch in my personal fork to run a CI build. The HEAD commit of that branch has the explicit cast that fixes the compilation error. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2936277015 From nlisker at gmail.com Tue Jun 3 16:51:55 2025 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 3 Jun 2025 19:51:55 +0300 Subject: Build logic renovation? In-Reply-To: References: Message-ID: Sorry for the late reply, I was stuck abroad due to flight cancellations :) This issue has been brought up before, including lengthy off-list discussions. As a result, I created an umbrella issue that collects issues regarding the Gradle file: https://bugs.openjdk.org/browse/JDK-8344728. The linked issues below are a;ready listed under this umbrella issue. I, like you, was in favor of modernizing the Gradle approach. Johan Vos was in favor of using the OpenJDK approach with config/make, which I'm not familiar with (I only built OpenJDK once and many years ago). I believe the informal verdict is to go with Johan's approach, which I'm fine with. Regardless, the Gradle file does more than building; it also contains publishing: https://bugs.openjdk.org/browse/JDK-8333146 (see the PR in the comments). So, there's more than the build logic to clean up. I've done some minimal simplifications to the Gradle file in https://bugs.openjdk.org/browse/JDK-8345063 (I'm not sure a catalog, as you suggest, would be a big improvement) and https://bugs.openjdk.org/browse/JDK-8344906. Splitting the file for each module (subproject) is also mentioned in the umbrella issue: "Splitting of the monolithic build file should be done with convention plugins. These encapsulate shared code that can then be applied to subprojects as needed." I believe that many of these cleanups still hold value since we'll need to "decipher and translate" the Gradle file to the OpenJDK approach, and it will be easier to deal with it after cleanups. If I'm correct about this, then simplifications to the Gradle build file(s) in some areas could still be welcomed. I'd venture a guess that simplifications that make the code more readable are desired, but maybe those that dig further into Gradle-specific approaches (like the new declarative Gradle or the native plugins) are not. Would like to hear thoughts on this. - Nir On Thu, May 29, 2025 at 8:20?AM Jesper Skov wrote: > Ah, good insight! > > Sounds like a renovation of the Gradle file is not really a move forward > then. > Cheers! > Jesper > > May 27, 2025, 21:29 by john at status6.com: > > > Hi, Jesper. My comments below are not meant to discourage you entirely > from your plans -- really! :-) -- but rather to help you understand, based > on my own experience, the scope of the work involved. > > > > On 5/27/25 6:41 AM, Jesper Skov wrote: > > > >> Would there be interest in reworking the build logic? > >> > > > > Yes, but perhaps more like this: > > > > Building OpenJFX using JDK > > https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/ > > > >> All the procedural Gradle in one large file makes it hard to understand > the build logic. > >> > > > > Indeed. > > > >> It looks very complex. > >> > > > > It is very complex. > > > >> And it may be performing below optimum (this is just a conjecture). > >> > > > > Without a doubt. > > > >> I know that the current build is very obviously working. > >> > > > > Barely. :-) > > > >> And that there may good reasons to keep it in its current form. > >> > > > > No, not really, except for the "very obviously working" part. > > > >> But if there is an interest, I would like to make the build more > idiomatic Gradle. > >> > > > > Personally, I'm done with Gradle for any of my own projects. It's > difficult to pin down precisely the way in which Gradle fails to be a good > build system, but I think Bruce Eckel summarized it best in his article > below: > > > > Jan 2, 2021 - 16 minute read > > The Problem with Gradle > > https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ > > > >> Changing the build would be an explorative and iterative task. > >> > > > > The JavaFX build system is remarkably complicated. It is based on Gradle > but also uses other build tools such as Apache Maven, Apache Ant, GNU Make, > CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual Studio, and even > Windows batch files. It runs on Linux, macOS, and Windows, and supports > eight different hardware architectures (last time I counted). > > > > Testing requires you to con?gure and run hundreds (!) of these complex > builds and unit tests on multiple systems under Linux, macOS, and Windows. > > > > I'm tempted to say that having (almost) reproducible builds in JavaFX > would help in verifying that you're creating the same artifacts before and > after, but there are just so many artifacts to verify. It's not one build > that produces a set of artifacts. Rather, it's multiple builds that produce > multiple sets of artifacts on multiple systems. > > > >> And I would need to know if there are some non-obvious out-of-tree > features that need special handling. > >> > > > > Almost everything in it needs special handling. > > > >> I can understand if you would be wary about this proposal; I may not be > able to complete the transition from the current to a new build. > >> > > > > I think you're looking at a multi-year project. > > > > John > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue Jun 3 16:54:56 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Jun 2025 16:54:56 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strau? wrote: > `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. I think this is a huge improvement, and a net win overall. ------------- Marked as reviewed by jhendrikx (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1819#pullrequestreview-2893341470 From jhendrikx at openjdk.org Tue Jun 3 16:56:57 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Jun 2025 16:56:57 GMT Subject: RFR: 8358454: Wrong
tags in cssref.html In-Reply-To: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> References: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> Message-ID: On Tue, 3 Jun 2025 01:14:04 GMT, Michael Strau? wrote: > Some `
` tags in cssref.html are written as `
` or `
`. It should be `
`, since it is a void element. > > A single reviewer is sufficient. Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1820#pullrequestreview-2893345129 From mstrauss at openjdk.org Tue Jun 3 17:03:05 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 17:03:05 GMT Subject: Integrated: 8358454: Wrong
tags in cssref.html In-Reply-To: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> References: <8zTsG9r5Jae4JNLxqp-gYpVWAUr2lNkmqphaIH4_nGY=.0abf4b47-c45f-49d7-b5b6-eed01f5c0802@github.com> Message-ID: <3jPBCy0qJOKy9IuPK6-HBczv0oLzOB_TBqNjnFCo3vs=.b17cab3b-7f4b-4bc9-ad38-9e5c76da7297@github.com> On Tue, 3 Jun 2025 01:14:04 GMT, Michael Strau? wrote: > Some `
` tags in cssref.html are written as `
` or `
`. It should be `
`, since it is a void element. > > A single reviewer is sufficient. This pull request has now been integrated. Changeset: fdd50d86 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/fdd50d86c3ef14b69df610e6105de95cd95aa7f0 Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod 8358454: Wrong
tags in cssref.html Reviewed-by: angorya, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/1820 From mstrauss at openjdk.org Tue Jun 3 17:03:06 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 17:03:06 GMT Subject: Integrated: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: References: Message-ID: <1LXyTNndsrdAsseFVfHjQzWjF1MuGmRDIVej7jiVOFo=.41de997a-19e1-4442-af4c-392eb97cdeb4@github.com> On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strau? wrote: > `EventHandler` property implementations in `Scene` and `Window` use anonymous classes derived from `ObjectPropertyBase`. We can remove about 650 lines of boilerplate code by using a common property class instead. This pull request has now been integrated. Changeset: 9edc1696 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/9edc1696f9b804473d5600fed40a2809db6ec05a Stats: 793 lines in 2 files changed: 50 ins; 694 del; 49 mod 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window Reviewed-by: angorya, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/1819 From mstrauss at openjdk.org Tue Jun 3 17:03:57 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 17:03:57 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v77] In-Reply-To: References: Message-ID: <75bZ8L8AWdo_VHgvCp26tycvi0vMfgKPK7HY2tmjBEM=.24dcdd64-53f1-4b75-bfe3-9dd35ee9c5a8@github.com> > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits: - Merge branch 'master' into feature/extended-window - add explicit cast in glass_window.cpp - Merge branch 'master' into feature/extended-window - Merge branch 'master' into feature/extended-window - javadoc - Merge branch 'master' into feature/extended-window - reapply overlay CSS - Merge branch 'master' into feature/extended-window - simplify header area picking - Fix top resize border on Windows - ... and 89 more: https://git.openjdk.org/jfx/compare/fdd50d86...b947e33f ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=76 Stats: 6805 lines in 76 files changed: 6114 ins; 517 del; 174 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Tue Jun 3 17:12:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 17:12:47 GMT Subject: RFR: 8345348: CSS media feature queries [v30] In-Reply-To: References: Message-ID: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: - Merge branch 'master' into feature/media-queries - fix wrong
HTML tags - Merge branch 'master' into feature/media-queries - doc - reorder Scene.Preferences.colorScheme - move doc from Scene.Preferences to Platform.Preferences - Merge branch 'master' into feature/media-queries - add -fx vendor prefix to prefers-persistent-scrollbars - cssref documentation changes - added test - ... and 36 more: https://git.openjdk.org/jfx/compare/fdd50d86...286e1fd3 ------------- Changes: https://git.openjdk.org/jfx/pull/1655/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=29 Stats: 5272 lines in 42 files changed: 4110 ins; 1048 del; 114 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From nlisker at openjdk.org Tue Jun 3 17:18:00 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 3 Jun 2025 17:18:00 GMT Subject: RFR: 8358255: Factor out boilerplate code of EventHandler properties in Scene and Window In-Reply-To: <_vhtdAlSFW8FKqLAuUTfBXD0SzuU9VGNBZiqKlFwWsI=.9bc85e3e-2f0e-4ccb-9dc6-14917ec9e91b@github.com> References: <_vhtdAlSFW8FKqLAuUTfBXD0SzuU9VGNBZiqKlFwWsI=.9bc85e3e-2f0e-4ccb-9dc6-14917ec9e91b@github.com> Message-ID: <7HbKs0bfpk-A5rECOWwqnkcIXkEJLtYOpk3anuXNtDk=.511a7c80-8b71-412c-bbe1-772d30b154f4@github.com> On Tue, 3 Jun 2025 16:44:17 GMT, Kevin Rushforth wrote: > > > when the app devs create hundreds of windows and keep them hidden (I've seen those) > > > > > > ? > > Window and Scene are heavy-weight classes that are reasonably limited in quantity, so I'm not at all worried about this. The concern I raised earlier (as I recall) was about properties in nodes. Yes, I'm thinking the same thing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1819#issuecomment-2936372153 From kcr at openjdk.org Tue Jun 3 17:47:36 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Jun 2025 17:47:36 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v77] In-Reply-To: <75bZ8L8AWdo_VHgvCp26tycvi0vMfgKPK7HY2tmjBEM=.24dcdd64-53f1-4b75-bfe3-9dd35ee9c5a8@github.com> References: <75bZ8L8AWdo_VHgvCp26tycvi0vMfgKPK7HY2tmjBEM=.24dcdd64-53f1-4b75-bfe3-9dd35ee9c5a8@github.com> Message-ID: On Tue, 3 Jun 2025 17:03:57 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits: > > - Merge branch 'master' into feature/extended-window > - add explicit cast in glass_window.cpp > - Merge branch 'master' into feature/extended-window > - Merge branch 'master' into feature/extended-window > - javadoc > - Merge branch 'master' into feature/extended-window > - reapply overlay CSS > - Merge branch 'master' into feature/extended-window > - simplify header area picking > - Fix top resize border on Windows > - ... and 89 more: https://git.openjdk.org/jfx/compare/fdd50d86...b947e33f The compilation and headless tests pass on all platforms. The following 5 headful tests fail on macOS (13 and 14). The first 4 also fail on Linux (Ubuntu 22.04 LTS but I doubt that is relevant). ViewPainterLeakTest > testViewPainterLeak() FAILED java.lang.AssertionError: Content of WeakReference was not collected. content: javafx.scene.Scene at 1a72a540 at test.util.memory.JMemoryBuddy.assertCollectable(JMemoryBuddy.java:91) at test.com.sun.javafx.tk.quantum.ViewPainterLeakTest.testViewPainterLeak(ViewPainterLeakTest.java:106) StyleMemoryLeakTest > testRootNodeMemoryLeak() FAILED java.lang.AssertionError: The following references should be collected: [javafx.stage.Stage at 6bc407fd] at test.util.memory.JMemoryBuddy.memoryTest(JMemoryBuddy.java:245) at test.javafx.scene.StyleMemoryLeakTest.testRootNodeMemoryLeak(StyleMemoryLeakTest.java:63) ProgressIndicatorLeakTest > stageLeakWhenTreeNotShowing() FAILED java.lang.AssertionError: The following references should be collected: [javafx.stage.Stage at 6f7923a5] at test.util.memory.JMemoryBuddy.memoryTest(JMemoryBuddy.java:245) at test.javafx.scene.control.ProgressIndicatorLeakTest.stageLeakWhenTreeNotShowing(ProgressIndicatorLeakTest.java:90) FocusedWindowNativeTest > testClosedFocusedStageLeak() FAILED java.lang.AssertionError: Content of WeakReference was not collected. content: javafx.stage.Stage at 3eb77ea8 at test.util.memory.JMemoryBuddy.assertCollectable(JMemoryBuddy.java:91) at test.javafx.stage.FocusedWindowTestBase.testClosedFocusedStageLeakBase(FocusedWindowTestBase.java:75) at test.javafx.stage.FocusedWindowNativeTest.testClosedFocusedStageLeak(FocusedWindowNativeTest.java:42) JSCallbackMemoryTest > testJsCallbackLeak() FAILED org.opentest4j.AssertionFailedError: All Stages are null ==> expected: but was: at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214) at app//test.memoryleak.JSCallbackMemoryTest.testJsCallbackLeak(JSCallbackMemoryTest.java:329 This suggests a memory leak related to the glass changes on macOS and Linux. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2936433906 From angorya at openjdk.org Tue Jun 3 17:58:28 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Jun 2025 17:58:28 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v77] In-Reply-To: References: <75bZ8L8AWdo_VHgvCp26tycvi0vMfgKPK7HY2tmjBEM=.24dcdd64-53f1-4b75-bfe3-9dd35ee9c5a8@github.com> Message-ID: On Tue, 3 Jun 2025 17:34:24 GMT, Kevin Rushforth wrote: > This suggests a memory leak related to the glass changes on macOS and Linux. would this be considered an integration blocker? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2936507784 From andy.goryachev at oracle.com Tue Jun 3 18:18:16 2025 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 3 Jun 2025 18:18:16 +0000 Subject: Build logic renovation? In-Reply-To: References: Message-ID: There was a somewhat related discussion on hacker news - someone measured how fast a naked javac compiles the project vs how fast the build runs in gradle. I think it might have been this discussion, though the original blog post has disappeared or moved https://news.ycombinator.com/item?id=42245003 Basically, > From this study we can see the paradox: the Java compiler is blazing fast, while Java build tools are dreadfully slow. Something that should compile in a fraction of a second using a warm javac takes several seconds (15-16x longer) to compile using Maven or Gradle. From my experience, it is **always** better to do a clean build, at least for java parts. The native parts usually take much more time, so some optimization is inevitable. But the larger issue is this - I don't know whether it is even possible to change the gradle build at this point, since the amount of work required to guarantee the feature parity will be enormous, the probability of introducing regression and associated cascading disruption is too great, while the possible benefits are, in my opinion, incredibly small. -andy From: openjfx-dev on behalf of Nir Lisker Date: Tuesday, June 3, 2025 at 09:52 To: Jesper Skov Cc: Openjfx Dev Subject: Re: Build logic renovation? Sorry for the late reply, I was stuck abroad due to flight cancellations :) This issue has been brought up before, including lengthy off-list discussions. As a result, I created an umbrella issue that collects issues regarding the Gradle file: https://bugs.openjdk.org/browse/JDK-8344728. The linked issues below are a;ready listed under this umbrella issue. I, like you, was in favor of modernizing the Gradle approach. Johan Vos was in favor of using the OpenJDK approach with config/make, which I'm not familiar with (I only built OpenJDK once and many years ago). I believe the informal verdict is to go with Johan's approach, which I'm fine with. Regardless, the Gradle file does more than building; it also contains publishing: https://bugs.openjdk.org/browse/JDK-8333146 (see the PR in the comments). So, there's more than the build logic to clean up. I've done some minimal simplifications to the Gradle file in https://bugs.openjdk.org/browse/JDK-8345063 (I'm not sure a catalog, as you suggest, would be a big improvement) and https://bugs.openjdk.org/browse/JDK-8344906. Splitting the file for each module (subproject) is also mentioned in the umbrella issue: "Splitting of the monolithic build file should be done with convention plugins. These encapsulate shared code that can then be applied to subprojects as needed." I believe that many of these cleanups still hold value since we'll need to "decipher and translate" the Gradle file to the OpenJDK approach, and it will be easier to deal with it after cleanups. If I'm correct about this, then simplifications to the Gradle build file(s) in some areas could still be welcomed. I'd venture a guess that simplifications that make the code more readable are desired, but maybe those that dig further into Gradle-specific approaches (like the new declarative Gradle or the native plugins) are not. Would like to hear thoughts on this. - Nir On Thu, May 29, 2025 at 8:20?AM Jesper Skov > wrote: Ah, good insight! Sounds like a renovation of the Gradle file is not really a move forward then. Cheers! Jesper May 27, 2025, 21:29 by john at status6.com: > Hi, Jesper. My comments below are not meant to discourage you entirely from your plans -- really! :-) -- but rather to help you understand, based on my own experience, the scope of the work involved. > > On 5/27/25 6:41 AM, Jesper Skov wrote: > >> Would there be interest in reworking the build logic? >> > > Yes, but perhaps more like this: > > Building OpenJFX using JDK > https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/ > >> All the procedural Gradle in one large file makes it hard to understand the build logic. >> > > Indeed. > >> It looks very complex. >> > > It is very complex. > >> And it may be performing below optimum (this is just a conjecture). >> > > Without a doubt. > >> I know that the current build is very obviously working. >> > > Barely. :-) > >> And that there may good reasons to keep it in its current form. >> > > No, not really, except for the "very obviously working" part. > >> But if there is an interest, I would like to make the build more idiomatic Gradle. >> > > Personally, I'm done with Gradle for any of my own projects. It's difficult to pin down precisely the way in which Gradle fails to be a good build system, but I think Bruce Eckel summarized it best in his article below: > > Jan 2, 2021 - 16 minute read > The Problem with Gradle > https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ > >> Changing the build would be an explorative and iterative task. >> > > The JavaFX build system is remarkably complicated. It is based on Gradle but also uses other build tools such as Apache Maven, Apache Ant, GNU Make, CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual Studio, and even Windows batch files. It runs on Linux, macOS, and Windows, and supports eight different hardware architectures (last time I counted). > > Testing requires you to con?gure and run hundreds (!) of these complex builds and unit tests on multiple systems under Linux, macOS, and Windows. > > I'm tempted to say that having (almost) reproducible builds in JavaFX would help in verifying that you're creating the same artifacts before and after, but there are just so many artifacts to verify. It's not one build that produces a set of artifacts. Rather, it's multiple builds that produce multiple sets of artifacts on multiple systems. > >> And I would need to know if there are some non-obvious out-of-tree features that need special handling. >> > > Almost everything in it needs special handling. > >> I can understand if you would be wary about this proposal; I may not be able to complete the transition from the current to a new build. >> > > I think you're looking at a multi-year project. > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Tue Jun 3 19:13:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 19:13:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v78] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix memory leak in ViewScene ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/b947e33f..3b8fd536 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=77 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=76-77 Stats: 15 lines in 2 files changed: 3 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Tue Jun 3 19:23:44 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 19:23:44 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v78] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:13:08 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix memory leak in ViewScene `ViewScene` has a reference to `Scene` that it held onto after being disposed. When I clear out the reference in `ViewScene.dispose()`, the memory leaks disappear. Of course, this is only a memory leak because `ViewScene` apparently hangs around after its scene/stage has been closed. But that's probably a question for another day, because it's unrelated to this feature. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2936834119 From zelmidaoui at openjdk.org Tue Jun 3 22:06:26 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 3 Jun 2025 22:06:26 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v6] In-Reply-To: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> References: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> Message-ID: On Tue, 3 Jun 2025 13:23:35 GMT, Ziad El Midaoui wrote: >> When the Root TreeItem is set to null, need to relayout to show the children items > > 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 eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Minor change : new line added > - Adding fix to root item listener > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Headfull Test added > - Fixed issue with TreeTableView not showing the root's children when set to null Thank you for reviews, I will integrate it ------------- PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2937345899 From duke at openjdk.org Tue Jun 3 22:06:26 2025 From: duke at openjdk.org (duke) Date: Tue, 3 Jun 2025 22:06:26 GMT Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView [v6] In-Reply-To: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> References: <3FT1RCC-P-zMmK0LpUG7s2RAk9RmYhQjSDAqpS62-4Q=.b6f76440-9cd7-4856-9282-2816069fe0b2@github.com> Message-ID: On Tue, 3 Jun 2025 13:23:35 GMT, Ziad El Midaoui wrote: >> When the Root TreeItem is set to null, need to relayout to show the children items > > 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 eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Minor change : new line added > - Adding fix to root item listener > - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem > - Merge branch 'openjdk:master' into 8341281.RootTreeItem > - Headfull Test added > - Fixed issue with TreeTableView not showing the root's children when set to null @Ziad-Mid Your change (at version 5c55cc0dd4cbcf7d0469e392ce127d93b22dffd5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2937348939 From zelmidaoui at openjdk.org Tue Jun 3 22:13:26 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 3 Jun 2025 22:13:26 GMT Subject: Integrated: 8341281: Root TreeItem with null value breaks TreeTableView In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 12:41:44 GMT, Ziad El Midaoui wrote: > When the Root TreeItem is set to null, need to relayout to show the children items This pull request has now been integrated. Changeset: 11f31146 Author: Ziad El Midaoui Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/11f31146a6f70881945799dadad63bca56ed8a80 Stats: 165 lines in 2 files changed: 165 ins; 0 del; 0 mod 8341281: Root TreeItem with null value breaks TreeTableView Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1767 From mstrauss at openjdk.org Tue Jun 3 22:43:15 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Jun 2025 22:43:15 GMT Subject: RFR: 8345348: CSS media feature queries [v31] In-Reply-To: References: Message-ID: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: use custom mediaFeature javadoc tag ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1655/files - new: https://git.openjdk.org/jfx/pull/1655/files/286e1fd3..9a32e2f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=30 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=29-30 Stats: 70 lines in 4 files changed: 11 ins; 58 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From kcr at openjdk.org Tue Jun 3 23:45:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Jun 2025 23:45:35 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v78] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:13:08 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix memory leak in ViewScene CI headful test run is successful with the latest patch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2937744474 From kcr at openjdk.org Wed Jun 4 12:42:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 12:42:23 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v78] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:13:08 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix memory leak in ViewScene I finished my review of the API. It looks good. I identified one minor formatting issue in the docs. I also left a minor question about a test method. I'll review the CSR and do a bit of light testing. Others have reviewed the implementation, so I'll limit most of my code review to the native glass changes. modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 63: > 61: * This method is only used for testing purposes. > 62: */ > 63: public static void enableForTesting() { Minor: As an alternative, have you considered adding a utility method in a test utility class that sets both the `javafx.enablePreview` and `javafx.suppressPreviewWarning` system properties? Unless there a reason that wouldn't work, it seems cleaner to me. modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 254: > 252: * use custom header buttons instead (see {@link #setButtonType(Node, HeaderButtonType)}). > 253: *

> 254: * The default value {@code #USE_DEFAULT_SIZE} indicates that the platform should choose the button height. Minor: The `#` is rendered since it using `@code` rather than `@link`. I recommend removing the `#`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2894405127 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2125132948 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2126483269 From mstrauss at openjdk.org Wed Jun 4 14:26:52 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 14:26:52 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v79] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc fix ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/3b8fd536..06ce89a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=78 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=77-78 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Wed Jun 4 14:48:31 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 14:48:31 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v78] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 23:48:33 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fix memory leak in ViewScene > > modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 63: > >> 61: * This method is only used for testing purposes. >> 62: */ >> 63: public static void enableForTesting() { > > Minor: As an alternative, have you considered adding a utility method in a test utility class that sets both the `javafx.enablePreview` and `javafx.suppressPreviewWarning` system properties? Unless there a reason that wouldn't work, it seems cleaner to me. I've modified the build script instead to always specify the system properties for tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2126794640 From mstrauss at openjdk.org Wed Jun 4 14:48:31 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 14:48:31 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: enable preview feature system properties for tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/06ce89a4..56868485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=79 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=78-79 Stats: 17 lines in 3 files changed: 2 ins; 14 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From kcr at openjdk.org Wed Jun 4 17:42:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 17:42:21 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: <8rrIy4kTlaFbc6E_K-Ei0uOY6GUAhkLaZ87uf39ZguM=.588f060d-58dc-4947-afa4-2a005f4ee11c@github.com> On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests Testing looks good. One thing I noticed on Linux when running on an older version of Ubuntu is that the buttons are always on the right, even when the window manager is configured to put them on the left for decorated windows. It might be worth considering a future enhancement to query the window manager for whether the buttons should be on the left or right. I spot checked a few things in the code and at least looked at all of the native code. I didn't spot any concerns. I did leave a couple questions, but nothing that would prevent my approving this. This is a nice piece of work, and I'm happy we will be getting it into JavaFX 25 as a preview feature! build.gradle line 2186: > 2184: systemProperty 'junit.jupiter.execution.timeout.lifecycle.method.default', JUNIT_LIFECYCLE_TIMEOUT > 2185: systemProperty 'javafx.enablePreview', 'true' > 2186: systemProperty 'javafx.suppressPreviewWarning', 'true' This seems a good approach. it might make it a little more difficult if we wanted to test the logic that throws an exception when `javafx.enablePreview` is not `"true"`, but that would still be possible by having that test explicitly set the property to the empty string in an `@Before` method, and then restoring it in an `@After` method. Probably not worth doing anyway. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 1403: > 1401: } > 1402: > 1403: private class UndecoratedMoveResizeHelper { Have you verified that removing this doesn't result in any loss of functionality? modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 43: > 41: > 42: if (isExtendedWindow()) { > 43: prefHeaderButtonHeightProperty().subscribe(this::onPrefHeaderButtonHeightChanged); This subscription is never canceled. Could this result in a leak? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2897115260 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2126830663 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2126871708 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2126869376 From angorya at openjdk.org Wed Jun 4 18:15:13 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 18:15:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests I am going to run a bunch of tests and report the results. The first thing I noticed: - using the State Tester tool in the monkey tester, open the stage like so and click on "Iconify" button. Expected: the stage gets iconified Observed: the stage, along with the Stage Tester window AND the monkey tester main window gets iconified, then a beep heard, then all windows get restored. Happens for any Modality setting other than NONE. Why is that? ![Screenshot 2025-06-04 at 11 00 11](https://github.com/user-attachments/assets/a6a766db-4854-42c8-8dc4-ffdd44fef5bb) With this config, clicking on "Enter/Exit Full Screen" button locks up the app without going into the full screen mode. I was able eventually to get it unstuck, but opening a stage for the second time produced a blank window: ![Screenshot 2025-06-04 at 11 09 58](https://github.com/user-attachments/assets/3f6d6d4b-0a60-4f88-963d-404639b0087e) once that happens, the application breaks - for example, I cannot change any options in the Stage Tester window. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2940920610 PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2940937922 From mstrauss at openjdk.org Wed Jun 4 18:15:14 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 18:15:14 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: <8rrIy4kTlaFbc6E_K-Ei0uOY6GUAhkLaZ87uf39ZguM=.588f060d-58dc-4947-afa4-2a005f4ee11c@github.com> References: <8rrIy4kTlaFbc6E_K-Ei0uOY6GUAhkLaZ87uf39ZguM=.588f060d-58dc-4947-afa4-2a005f4ee11c@github.com> Message-ID: On Wed, 4 Jun 2025 15:00:44 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> enable preview feature system properties for tests > > build.gradle line 2186: > >> 2184: systemProperty 'junit.jupiter.execution.timeout.lifecycle.method.default', JUNIT_LIFECYCLE_TIMEOUT >> 2185: systemProperty 'javafx.enablePreview', 'true' >> 2186: systemProperty 'javafx.suppressPreviewWarning', 'true' > > This seems a good approach. > > it might make it a little more difficult if we wanted to test the logic that throws an exception when `javafx.enablePreview` is not `"true"`, but that would still be possible by having that test explicitly set the property to the empty string in an `@Before` method, and then restoring it in an `@After` method. Probably not worth doing anyway. Yes, this seems like a good solution waiting for a problem. I agree that we can do that when we discover that problem. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 1403: > >> 1401: } >> 1402: >> 1403: private class UndecoratedMoveResizeHelper { > > Have you verified that removing this doesn't result in any loss of functionality? Yes, one of the first things that I discovered in this project was that `UndecoratedMoveResizeHelper` was effectively unused. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 43: > >> 41: >> 42: if (isExtendedWindow()) { >> 43: prefHeaderButtonHeightProperty().subscribe(this::onPrefHeaderButtonHeightChanged); > > This subscription is never canceled. Could this result in a leak? The `prefHeaderButtonHeight` property is a field on the same class. We only subscribe to this property within the context of this class, so it won't prevent `GtkWindow` from being eligible for GC. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127169914 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127166757 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127161222 From angorya at openjdk.org Wed Jun 4 18:19:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 18:19:18 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests Same full screen issue for this configuration: ![Screenshot 2025-06-04 at 11 14 24](https://github.com/user-attachments/assets/ba746545-dff0-42f5-87ad-2156ff559098) no full screen, and once the "My Stage" is closed the app is broken. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2940953498 From kcr at openjdk.org Wed Jun 4 18:25:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 18:25:15 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: <7_EY9fwbQesPEpfuipmG8RMYOoDfe3HrzReLvKMnnjo=.4b98c678-9855-4238-956f-a753c227ebb9@github.com> On Wed, 4 Jun 2025 18:15:54 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> enable preview feature system properties for tests > > Same full screen issue for this configuration: > > ![Screenshot 2025-06-04 at 11 14 24](https://github.com/user-attachments/assets/ba746545-dff0-42f5-87ad-2156ff559098) > > no full screen, and once the "My Stage" is closed the app is broken. @andy-goryachev-oracle Are any of the problems you are discovering caused by this PR? Or are you running into preexisting problems? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2940969996 From angorya at openjdk.org Wed Jun 4 18:25:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 18:25:15 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: <7_EY9fwbQesPEpfuipmG8RMYOoDfe3HrzReLvKMnnjo=.4b98c678-9855-4238-956f-a753c227ebb9@github.com> References: <7_EY9fwbQesPEpfuipmG8RMYOoDfe3HrzReLvKMnnjo=.4b98c678-9855-4238-956f-a753c227ebb9@github.com> Message-ID: <5uzlcvoLg8DykXAh4Hmc19dAlHebrzMXf7F7-YgpGgo=.7187bc29-4c72-4e62-a4e8-8bea34be80da@github.com> On Wed, 4 Jun 2025 18:20:35 GMT, Kevin Rushforth wrote: > are you running into preexisting problems? good question, investigating. I am on macOS 15.5 M1 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2940979690 From angorya at openjdk.org Wed Jun 4 18:31:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 18:31:15 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests Looks like the problems are caused by changes in this PR (maybe recent changes since I did not see these issues before). The test app is difference since we don't have the stage tester tool in the master branch, but one can use the standalone monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest which has a Stage page. Use iconify/full screen checkboxes to replicate the abovementioned scenarios, and it seems to work correctly in the master branch: ![Screenshot 2025-06-04 at 11 25 29](https://github.com/user-attachments/assets/b87ce9c8-a271-4e25-abef-3f7e40952734) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2940999432 From kcr at openjdk.org Wed Jun 4 18:45:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 18:45:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests I can reproduce at least two of the things you reported with master. What I did to ensure an accurate comparison was to take the modified monkey tester that is included with this PR and removed all references to HeaderBar. The resulting app will run on either the master branch or this PR branch. With that, I can reproduce the following behaviors: 1. WINDOW_MODAL, iconify (either by checking the box or pressing the button on the new stage) -- new stage iconifies along with other windows, beep, then restores 2. WINDOW_MODAL, UNDECORATED, full-screen either by checking the box or pressing the button on the new stage) -- window does not go full screen So far I haven't seen any regressions, but it's worth some additional testing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941041523 From mstrauss at openjdk.org Wed Jun 4 18:45:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 18:45:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests I'm testing the following configuration on macOS: Modality: NONE StageStyle: UTILITY FullScreen: yes Both with the current master, as well as this PR, I can confirm your observation that a non-fullscreen window shows up, and when it's closed, it freezes the application. However, I think we're testing unsupported configurations here. These are definitively bugs, because unsupported configurations should not crash or freeze the application. What we should probably do is collect these artifacts in a bug ticket. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941045069 From mstrauss at openjdk.org Wed Jun 4 18:54:09 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 18:54:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests This is another configuration: Modality: WINDOW_MODAL StageStyle: DECORATED I then click the "Iconify" button. I can confirm that both windows get iconified, a beep is heard, and both windows are restored. However, again, this is an unsupported configuration: you can't iconify a modal window. Apparently that stage tester utility has made it really easy to test various combinations of stage configurations, which we haven't been able to do before (at least not as easily). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941065599 PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941074740 From angorya at openjdk.org Wed Jun 4 19:04:21 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 19:04:21 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests I've added popup menu to full screen/ minimize/ maximize to the standalone monkey tester, just in case. I can reproduce the iconify issue with EXTENDED and the following config (by invoking 'iconify' popup menu): ![Screenshot 2025-06-04 at 11 58 16](https://github.com/user-attachments/assets/4dd8d6d3-7db4-4a3a-b4c2-078dd969743c) Looks like fx _thinks_ it's iconified, but it is not. (please pull from the standalone monkey tester repo) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941107048 From mstrauss at openjdk.org Wed Jun 4 19:10:16 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 19:10:16 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests I've created a ticket for this problem: https://bugs.openjdk.org/browse/JDK-8358620 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941133611 From angorya at openjdk.org Wed Jun 4 19:23:13 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 19:23:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: <6zuDeHjpWU6ABWUy4vbEyfhFt1nypS0UVXe4okNhyxo=.a9f15d07-bfda-4216-ad34-e1241341d047@github.com> On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests should we add the full screen issue to the same ticket or is it a separate one? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941172516 From mstrauss at openjdk.org Wed Jun 4 19:30:27 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Jun 2025 19:30:27 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: <6zuDeHjpWU6ABWUy4vbEyfhFt1nypS0UVXe4okNhyxo=.a9f15d07-bfda-4216-ad34-e1241341d047@github.com> References: <6zuDeHjpWU6ABWUy4vbEyfhFt1nypS0UVXe4okNhyxo=.a9f15d07-bfda-4216-ad34-e1241341d047@github.com> Message-ID: On Wed, 4 Jun 2025 19:20:14 GMT, Andy Goryachev wrote: > should we add the full screen issue to the same ticket or is it a separate one? I haven't studied the problem extensively, but my guess is that it's a different problem. I don't see at first glance why a modal window shouldn't also be a full-screen window. This needs more investigation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941189753 From tsayao at openjdk.org Wed Jun 4 20:00:08 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Jun 2025 20:00:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests On #1789 there's a Test utility for Stages called `TestStage` that might be useful. There are also a bunch of automated tests for stages that uses `@ParamatrizedTest` to test different `StageStyle`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941292587 From angorya at openjdk.org Wed Jun 4 20:53:09 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 20:53:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: <98g94vmzmWG46bZcP_Ls46Swvfayw44eH1e3NIMiFgE=.7a2077a0-3a76-45e2-8b93-eeb741c035d6@github.com> On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests created * [JDK-8358625](https://bugs.openjdk.org/browse/JDK-8358625) Full screen of a modal Stage breaks the application ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2941419548 From angorya at openjdk.org Wed Jun 4 20:57:10 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Jun 2025 20:57:10 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: <42R-tz3Drfl8_FATqDKtT03w3UUE3d4EXitegNcN3zk=.37f96e78-6778-4a8f-b10d-49880eef967b@github.com> On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests Recently discovered issues appear unrelated (i.e. present in the master branch). The latest changes look good. Good job, Michael! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2898076430 From mmack at openjdk.org Wed Jun 4 21:21:09 2025 From: mmack at openjdk.org (Markus Mack) Date: Wed, 4 Jun 2025 21:21:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests Changes look good, re-approving. ------------- Marked as reviewed by mmack (Author). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2898136002 From tsayao at openjdk.org Wed Jun 4 23:56:06 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Jun 2025 23:56:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: <20fddTa8a3sh0-kCFZInLeHoHlxBsv4OC-6L7PXsn1I=.c48d6fc1-31fd-45c3-96fb-1e1ea99a2413@github.com> On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/WindowManager.java line 33: > 31: * The window manager of the current desktop environment. > 32: */ > 33: enum WindowManager { I suggest renaming this enum to `DesktopEnvironment` (or something similar), as it more accurately reflects the entities being represented. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127613269 From tsayao at openjdk.org Thu Jun 5 00:15:13 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 5 Jun 2025 00:15:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1418: > 1416: > 1417: gdk_window_show_window_menu(gdk_window, event); > 1418: gdk_event_free(event); The `seat` concept was introduced in gtk 3.20 and `gdk_window_show_window_menu` was in 3.14, and we require 3.8. I would agree that it's time to bump it up. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127680262 From tsayao at openjdk.org Thu Jun 5 00:27:11 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 5 Jun 2025 00:27:11 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 14:48:31 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > enable preview feature system properties for tests modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h line 132: > 130: virtual void set_alpha(double) = 0; > 131: virtual void set_enabled(bool) = 0; > 132: virtual void set_system_minimum_size(int, int) = 0; Maybe `set_headerbar_mininum_size()` ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127721973 From mstrauss at openjdk.org Thu Jun 5 00:50:30 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Jun 2025 00:50:30 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: rename WindowManager to DesktopEnvironment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/56868485..e17fe8bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=80 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=79-80 Stats: 157 lines in 3 files changed: 76 ins; 76 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Thu Jun 5 00:50:31 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Jun 2025 00:50:31 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:12:43 GMT, Thiago Milczarek Sayao wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> enable preview feature system properties for tests > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1418: > >> 1416: >> 1417: gdk_window_show_window_menu(gdk_window, event); >> 1418: gdk_event_free(event); > > The `seat` concept was introduced in gtk 3.20 and `gdk_window_show_window_menu` was in 3.14, and we require 3.8. > I would agree that it's time to bump it up. Is there anything we need to change here? > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h line 132: > >> 130: virtual void set_alpha(double) = 0; >> 131: virtual void set_enabled(bool) = 0; >> 132: virtual void set_system_minimum_size(int, int) = 0; > > Maybe `set_headerbar_mininum_size()` ? Hmm... but it's not the minimum size of the header bar, it's the minimum size of the window. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127737900 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2127739124 From bdunkley-smith at bigpond.com Thu Jun 5 05:42:20 2025 From: bdunkley-smith at bigpond.com (Bryon Dunkley-Smith) Date: Thu, 5 Jun 2025 15:42:20 +1000 Subject: JavaFX MediaView Problem After Win10 to Win11 Update In-Reply-To: <52d450be-fa2b-4b53-baa2-e8a00b79e4ae@oracle.com> References: <001301dbd41f$10e688a0$32b399e0$@bigpond.com> <52d450be-fa2b-4b53-baa2-e8a00b79e4ae@oracle.com> Message-ID: <006d01dbd5dc$9b5f5840$d21e08c0$@bigpond.com> Thank you Kevin. I?ve tried using a recent build of JavaFX 25 ea, build 18 I believe and the symptom of ?flaky? display of videos remains. Hopefully evaluation of https://bugs.openjdk.org/browse/JDK-8305842 will confirm the bug and a solution will eventuate. In the meantime, I?ll use a Win10 machine! Thanks, Bryon From: openjfx-dev On Behalf Of Kevin Rushforth Sent: Tuesday, 3 June 2025 10:25 PM To: openjfx-dev at openjdk.org Subject: Re: JavaFX MediaView Problem After Win10 to Win11 Update Another possibly related bug is https://bugs.openjdk.org/browse/JDK-8329227 which is fixed in JavaFX 25 ea build 14. You might try running with the latest JavaFX 25 build and see if that helps. If not, then it does seem likely that you are hitting https://bugs.openjdk.org/browse/JDK-8305842 which is being evaluated. -- Kevin On 6/2/2025 5:33 PM, Bryon Dunkley-Smith wrote: Hi All, First time poster and so I trust this is an appropriate question to ask here. I have a legacy JavaFX based application which in part displays a sequence of short (.MP4) videos which has functioned flawlessly for several years as demonstrated here https://www.youtube.com/watch?v=CMv6z_SIUXU. But since upgrading the laptop on which it runs from Win10 to Win11 some months ago, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown. I have tried many code changes to fix this unsuccessfully however a common ?fix? across several machines is always just running it on a Win10 machine. I note there is an unresolved bug report Video sometimes does not start when reinitializing in Windows 11 https://bugs.openjdk.org/browse/JDK-8305842 which appears relevant. So I am wondering if others have encountered this problem and whether there is a plan to resolve this bug in an upcoming JavaFX release. Thanks, Bryon -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Thu Jun 5 06:51:41 2025 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 5 Jun 2025 08:51:41 +0200 Subject: Headless Platform, status update Message-ID: Hi, After the previous discussion on this list about the Headless Platform requiring its own module or not [1], I continued working on it without creating a new module for it. I updated the code in my fork of the jfx-sandbox repository [2] and builds of it are available in the Gluon JavaFX downloads [3]. The last build is based on the 25-ea+18-headless tag [4] so you can easily build it yourself if you want to. On Linux, almost all systemtests, including the ROBOT tests, are passing. There are a few exceptions which I believe require separate discussion as there are reasons for each one of them to fail in the context of a headless environment. Moving forward, I can create a PR as there is a JDK issue for this [5]. I don't think a JEP is needed, as there is no public API being touched and there is almost no interaction with other components. The only change that needs to be documented is that one has to use -Dglass.platform=Headless to select the headless platform -- but even that is not a new property key (just a new value). But if needed, I can create a JEP. If not, I'll create a PR soon that will create most of the code that is currently in the sandbox, with some cleanups. - Johan [1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-May/054357.html [2] https://github.com/openjdk/jfx-sandbox/compare/master...johanvos-headless [3] https://gluonhq.com/products/javafx/#headless [4] https://github.com/openjdk/jfx-sandbox/releases/tag/25%2B18-headless [5] https://bugs.openjdk.org/browse/JDK-8324941 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Thu Jun 5 11:46:12 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 5 Jun 2025 11:46:12 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:44:00 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1418: >> >>> 1416: >>> 1417: gdk_window_show_window_menu(gdk_window, event); >>> 1418: gdk_event_free(event); >> >> The `seat` concept was introduced in gtk 3.20 and `gdk_window_show_window_menu` was in 3.14, and we require 3.8. >> I would agree that it's time to bump it up. > > Is there anything we need to change here? We can bump up required Gtk version (with another PR) to 3.20 (it's from 2016, so pretty old), or replace the `gdk_window_show_menu` with X11 calls. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2128644400 From angorya at openjdk.org Thu Jun 5 14:30:48 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 14:30:48 GMT Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights [v2] In-Reply-To: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com> References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com> Message-ID: > Adding missing APIs related to styling the highlights with CSS: > > ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1) > > > > Adds methods to the `RichParagraph.Builder`: > > > /** > * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s). > *

> * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}. > * > * @param start the start offset > * @param length the end offset > * @param css the style name(s) > * @return this {@code Builder} instance > * @since 25 > */ > public Builder addWavyUnderline(int start, int length, String ... css) { > > > > /** > * Adds a highlight with the specified style name(s). > * Use translucent colors to enable multiple highlights in the same region of text. > *

> * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}. > * > * @param start the start offset > * @param length the end offset > * @param css the style name(s) > * @return this {@code Builder} instance > * @since 25 > */ > public Builder addHighlight(int start, int length, String ... css) { > > > > Also adding similar methods to the `SimpleViewOnlyStyledModel` class: > > > /** > * Adds a highlight of the given color to the specified range within the last paragraph, > * with the specified style name(s). > * > * @param start the start offset > * @param length the length of the highlight > * @param css the highlight style name(s) > * @return this model instance > * @since 25 > */ > public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) { > > > /** > * Adds a wavy underline (typically used as a spell checker indicator) > * to the specified range within the last paragraph, with the specified style name(s). > * > * @param start the start offset > * @param length the length of the highlight > * @param css the highlight style name(s) > * @return this model instance > * @since 25 > */ > public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) { 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 three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8355774.css - tab - css ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1802/files - new: https://git.openjdk.org/jfx/pull/1802/files/354cddf9..5f1e084c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00-01 Stats: 2497 lines in 54 files changed: 1098 ins; 1235 del; 164 mod Patch: https://git.openjdk.org/jfx/pull/1802.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1802/head:pull/1802 PR: https://git.openjdk.org/jfx/pull/1802 From angorya at openjdk.org Thu Jun 5 14:39:13 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 14:39:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: <1DZm8j4tN2AVVjYo0TBvm3RwRs3rpvACMJgECNcx9EY=.68bcf133-5f26-4484-9f64-7898d11a4021@github.com> On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2900610003 From mmack at openjdk.org Thu Jun 5 14:39:13 2025 From: mmack at openjdk.org (Markus Mack) Date: Thu, 5 Jun 2025 14:39:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment Marked as reviewed by mmack (Author). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2900618759 From mstrauss at openjdk.org Thu Jun 5 15:12:12 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Jun 2025 15:12:12 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 11:43:25 GMT, Thiago Milczarek Sayao wrote: >> Is there anything we need to change here? > > We can bump up required Gtk version (with another PR) to 3.20 (it's from 2016, so pretty old), or replace the `gdk_window_show_menu` with X11 calls. I'm okay with bumping the required version. It seems like 3.8 was released 12 years ago, and we would be requiring a version that was released 9 years ago. Sounds fair. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2129088423 From kcr at openjdk.org Thu Jun 5 15:35:09 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Jun 2025 15:35:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 15:09:15 GMT, Michael Strau? wrote: >> We can bump up required Gtk version (with another PR) to 3.20 (it's from 2016, so pretty old), or replace the `gdk_window_show_menu` with X11 calls. > > I'm okay with bumping the required version. It seems like 3.8 was released 12 years ago, and we would be requiring a version that was released 9 years ago. Sounds fair. Our production build system is Oracle Linux 8, which has GTK 3.22. The oldest system I now have access to is Ubuntu 16.04 (yeah, I know...it's probably time to retire it), which has GTK 3.18. I build JavaFX using GCC 14.2 (via a devkit) and compile against a GTK 3.22 header files and library. I'm able to run this PR and use the EXTENDED stage style with a HeaderBar, but when I try to use the context menu it crashes: java: symbol lookup error: build/sdk/lib/libglassgtk3.so: undefined symbol: gdk_display_get_default_seat We should make a deliberate decision as to whether or not to bump the minimum. I think bumping the minimum to 3.20 might be reasonable thing to, although I'd want to do it separately from this PR and provide a release note for that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2129136017 From kcr at openjdk.org Thu Jun 5 15:40:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Jun 2025 15:40:14 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 15:32:36 GMT, Kevin Rushforth wrote: >> I'm okay with bumping the required version. It seems like 3.8 was released 12 years ago, and we would be requiring a version that was released 9 years ago. Sounds fair. > > Our production build system is Oracle Linux 8, which has GTK 3.22. > > The oldest system I now have access to is Ubuntu 16.04 (yeah, I know...it's probably time to retire it), which has GTK 3.18. I build JavaFX using GCC 14.2 (via a devkit) and compile against a GTK 3.22 header files and library. I'm able to run this PR and use the EXTENDED stage style with a HeaderBar, but when I try to use the context menu it crashes: > > > java: symbol lookup error: build/sdk/lib/libglassgtk3.so: undefined symbol: gdk_display_get_default_seat > > > We should make a deliberate decision as to whether or not to bump the minimum. I think bumping the minimum to 3.20 might be reasonable thing to, although I'd want to do it separately from this PR and provide a release note for that. Worth noting is that we only recently upgraded our production build env from Oracle Linux 7, which is now out of support. Bumping the minimum GTK version to 3.20 will preclude running on OL 7 / RHEL 7 at all (RHEL 7 has GTK 3.8, which is why that minimum was chosen). I think this is OK, but is another reason I want to see a separate JBS issue to bump the minimum. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2129145160 From mstrauss at openjdk.org Thu Jun 5 16:01:13 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Jun 2025 16:01:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 15:37:17 GMT, Kevin Rushforth wrote: >> Our production build system is Oracle Linux 8, which has GTK 3.22. >> >> The oldest system I now have access to is Ubuntu 16.04 (yeah, I know...it's probably time to retire it), which has GTK 3.18. I build JavaFX using GCC 14.2 (via a devkit) and compile against a GTK 3.22 header files and library. I'm able to run this PR and use the EXTENDED stage style with a HeaderBar, but when I try to use the context menu it crashes: >> >> >> java: symbol lookup error: build/sdk/lib/libglassgtk3.so: undefined symbol: gdk_display_get_default_seat >> >> >> We should make a deliberate decision as to whether or not to bump the minimum. I think bumping the minimum to 3.20 might be reasonable thing to, although I'd want to do it separately from this PR and provide a release note for that. > > Worth noting is that we only recently upgraded our production build env from Oracle Linux 7, which is now out of support. Bumping the minimum GTK version to 3.20 will preclude running on OL 7 / RHEL 7 at all (RHEL 7 has GTK 3.8, which is why that minimum was chosen). I think this is OK, but is another reason I want to see a separate JBS issue to bump the minimum. I think providing a release note that the new extended stage style requires GTK 3.20 sounds reasonable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2129184670 From kcr at openjdk.org Thu Jun 5 16:12:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Jun 2025 16:12:21 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 15:58:01 GMT, Michael Strau? wrote: >> Worth noting is that we only recently upgraded our production build env from Oracle Linux 7, which is now out of support. Bumping the minimum GTK version to 3.20 will preclude running on OL 7 / RHEL 7 at all (RHEL 7 has GTK 3.8, which is why that minimum was chosen). I think this is OK, but is another reason I want to see a separate JBS issue to bump the minimum. > > I think providing a release note that the new extended stage style requires GTK 3.20 sounds reasonable. I mis-remembered the GTK version in OL7. I just tried it on an OL 7 VM I still had lying around, and it also has GTK 3.22 and using this PR, the MonkeyTester with EXTENDED stage style and a HeaderBar runs just fine, including the context menu. > I think providing a release note that the new extended stage style requires GTK 3.20 sounds reasonable. I was more thinking that we would file a new issue to bump the minimum to 3.20 and provide a release note using that bug that JavaFX requires 3.20 as a minimum. If we end up not doing that, then a release note that the extended stage style needs 3.20 would be good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2129205713 From kcr at openjdk.org Thu Jun 5 16:15:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Jun 2025 16:15:16 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2900943366 From kcr at openjdk.org Thu Jun 5 21:18:05 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Jun 2025 21:18:05 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v31] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Tue, 27 May 2025 15:06:43 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: > > - cleanup > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - cleanup > - removed getStrikeThroughShape > - caret geometry > - review comments > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - review comments > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - ... and 51 more: https://git.openjdk.org/jfx/compare/9950d33c...de1016be The API looks good given the removal of the Text/TextFlow getStrikeTrhoughShape methods. I added one question about whether you want to consider adding a getter to CaretInfo to return the list of rectangles in a single call, but I'll leave that up to you. I pointed out what I think are a couple doc typos in TextLine info. I think this is close to being ready. I'll review the implementation and do some testing. @prrace Can you also review the API changes? modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 52: > 50: * @return the number of segments representing the caret > 51: */ > 52: public abstract int getSegmentCount(); Do you think it's worth adding a `ListgetSegments()` method in addition to (or instead of) `getSegmentCount` and `getSegmentAt`? modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 42: > 40: *

  • > 41: * {@code minY} - the ascent of the line (negative). > 42: * The ascent of the line is the max ascent of all fonts in the line. Shouldn't that be "glyphs" not "fonts"? modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 45: > 43: *
  • > 44: * {@code width} - the width of the line. > 45: * The width for the line is sum of all the run widths in the line, it is not minor: "for the line" --> "of the line" modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 51: > 49: * {@code height} - the height of the line. > 50: * The height of the line is sum of the max ascent, max descent, and > 51: * max line gap of all the fonts in the line. Shouldn't that be "glyphs" not "fonts"? ------------- PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2902336289 PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2946299467 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2130374964 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2130362230 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2130367374 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2130365196 From angorya at openjdk.org Thu Jun 5 21:35:02 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 21:35:02 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v31] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Thu, 5 Jun 2025 21:00:49 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: >> >> - cleanup >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - cleanup >> - removed getStrikeThroughShape >> - caret geometry >> - review comments >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - review comments >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - ... and 51 more: https://git.openjdk.org/jfx/compare/9950d33c...de1016be > > modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 42: > >> 40: *
  • >> 41: * {@code minY} - the ascent of the line (negative). >> 42: * The ascent of the line is the max ascent of all fonts in the line. > > Shouldn't that be "glyphs" not "fonts"? This definition is copied from `com.sun.javafx.scene.text.TextLine::getBounds` L58. I'll let Phil confirm that, but since it's a max ascent, it might be a function of the font rather than the particular glyphs. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2130477383 From angorya at openjdk.org Thu Jun 5 21:42:46 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 21:42:46 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v32] In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 25 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > > > ## WARNINGS > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/RichTextFX/pull/1246 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - review comments - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - cleanup - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - cleanup - removed getStrikeThroughShape - caret geometry - review comments - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - ... and 53 more: https://git.openjdk.org/jfx/compare/11f31146...d0f56fee ------------- Changes: https://git.openjdk.org/jfx/pull/1596/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=31 Stats: 1570 lines in 13 files changed: 1474 ins; 52 del; 44 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From angorya at openjdk.org Thu Jun 5 21:42:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 21:42:47 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v31] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Thu, 5 Jun 2025 21:04:43 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: >> >> - cleanup >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - cleanup >> - removed getStrikeThroughShape >> - caret geometry >> - review comments >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - review comments >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - ... and 51 more: https://git.openjdk.org/jfx/compare/9950d33c...de1016be > > modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 52: > >> 50: * @return the number of segments representing the caret >> 51: */ >> 52: public abstract int getSegmentCount(); > > Do you think it's worth adding a `ListgetSegments()` method in addition to (or instead of) `getSegmentCount` and `getSegmentAt`? Probably unnecessary, because the caret has one segment most of the time. When bidi is involved, the caret might have 2 segments. It will never have 3 or more segments. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2130502043 From kcr at openjdk.org Thu Jun 5 21:46:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Jun 2025 21:46:56 GMT Subject: RFR: 8357393: RichTextArea: fails to properly save text attributes [v2] In-Reply-To: References: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com> Message-ID: On Thu, 29 May 2025 18:42:10 GMT, Andy Goryachev wrote: >> Fixing a bug that breaks proper serialization of character attributes. >> >> This, unfortunately, makes a breaking change in the RichTextArea native format [0]. >> >> ## References >> >> [0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea_DataFormat_V2.md > > 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 six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser > - javadoc > - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser > - test > - tests > - fixed attribute serialization The fix looks reasonable to me. I left a suggestion about whether we really need to allow null, but that's preexisting and could be considered in a follow-up. Another thing that needs to be done in a follow-up is that you will need to add versioning to the internal rich text format. While this is still an incubating API we can break backward compatibility, but at some point, we will need a format that can evolve compatibility with newer runtimes able to read older files. @Ziad-Mid Can you be the second reviewer? modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/StyleAttributeMapHelper.java line 57: > 55: * > 56: * @param ss the style attribute map > 57: * @return the instance of StyleAttributeMap, or null Is there a good reason to allow null here? Unless there is a semantic difference between null and the empty map, it might be easier to make this non-nullable. This could be done later, since the fact that it can return null is preexisting. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyleAttributeMap.java line 431: > 429: @Override > 430: public StyleAttributeMap filterAttributes(StyleAttributeMap ss, boolean isParagraph) { > 431: return (ss == null ? null : ss.filterAttributes(isParagraph)); You could skip the null check if you disallowed a null map. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1813#pullrequestreview-2902448757 PR Comment: https://git.openjdk.org/jfx/pull/1813#issuecomment-2946418313 PR Review Comment: https://git.openjdk.org/jfx/pull/1813#discussion_r2130475589 PR Review Comment: https://git.openjdk.org/jfx/pull/1813#discussion_r2130460632 From angorya at openjdk.org Thu Jun 5 21:57:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 21:57:58 GMT Subject: RFR: 8357393: RichTextArea: fails to properly save text attributes [v2] In-Reply-To: References: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com> Message-ID: On Thu, 5 Jun 2025 21:31:26 GMT, Kevin Rushforth wrote: >> 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 six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser >> - javadoc >> - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser >> - test >> - tests >> - fixed attribute serialization > > modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/StyleAttributeMapHelper.java line 57: > >> 55: * >> 56: * @param ss the style attribute map >> 57: * @return the instance of StyleAttributeMap, or null > > Is there a good reason to allow null here? Unless there is a semantic difference between null and the empty map, it might be easier to make this non-nullable. This could be done later, since the fact that it can return null is preexisting. I've recorded this in the feedback document - this might be worth doing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1813#discussion_r2130561873 From angorya at openjdk.org Thu Jun 5 22:00:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Jun 2025 22:00:57 GMT Subject: RFR: 8357393: RichTextArea: fails to properly save text attributes [v2] In-Reply-To: References: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com> Message-ID: On Thu, 5 Jun 2025 21:44:08 GMT, Kevin Rushforth wrote: > While this is still an incubating API we can break backward compatibility, but at some point, we will need a format that can evolve compatibility with newer runtimes able to read older files. You are absolutely right: we must provide a mechanism for versioning as well as properly document the format. The draft spec is https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea_DataFormat_V2.md but it is guaranteed to change to enable versioning (and addition of tab stop attributes in #1800) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1813#issuecomment-2946473022 From tsayao at openjdk.org Thu Jun 5 22:24:08 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 5 Jun 2025 22:24:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v80] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 16:09:39 GMT, Kevin Rushforth wrote: >> I think providing a release note that the new extended stage style requires GTK 3.20 sounds reasonable. > > I mis-remembered the GTK version in OL7. I just tried it on an OL 7 VM I still had lying around, and it also has GTK 3.22 and using this PR, the MonkeyTester with EXTENDED stage style and a HeaderBar runs just fine, including the context menu. > >> I think providing a release note that the new extended stage style requires GTK 3.20 sounds reasonable. > > I was more thinking that we would file a new issue to bump the minimum to 3.20 and provide a release note using that bug that JavaFX requires 3.20 as a minimum. If we end up not doing that, then a release note that the extended stage style needs 3.20 would be good. I can work on the Gtk version bump. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2130664007 From kcr at openjdk.org Fri Jun 6 12:07:42 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:07:42 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM Message-ID: PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. I broke this up into the following commits. The bulk of the work is in the first two: 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ Additional commits address review comments. ------------- Commit messages: - Address review feedback, pending TODOs - Revert "Temporary debug prints (revert this later)" - Merge branch 'master' into kcr-marlin-ffm.dev - Merge branch 'master' into kcr-marlin-ffm - Replace unsafe with off-heap in the names of methods, fields and strings (including system properties) - Temporary debug prints (revert this later) - No need for '--sun-misc-unsafe-memory-access=allow' any more - Set used to 0 in dispose and only copy up to 'used' bytes in resize - Initial FFM implementation - Encapsulate all off-heap access in OffHeapArray Changes: https://git.openjdk.org/jfx/pull/1814/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334137 Stats: 302 lines in 12 files changed: 73 ins; 99 del; 130 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Fri Jun 6 12:07:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:07:43 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:24:32 GMT, Kevin Rushforth wrote: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. @bourgesl @prrace @nlisker @minborg Can you take an initial look at this? It isn't finished (there are a few open questions), but it is working. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 36: > 34: // KCR: BEGIN DEBUG > 35: import java.util.concurrent.atomic.AtomicInteger; > 36: // KCR: END DEBUG I'll revert all of the debugging code. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 46: > 44: // FFM stuff > 45: private static final ValueLayout.OfByte BYTE_LAYOUT = ValueLayout.JAVA_BYTE; > 46: private static final ValueLayout.OfInt INT_LAYOUT = ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN); @minborg Is this the best layout to use? I chose it thinking that, since we don't need to access this memory from native code, it might perform better to use Java's big endian byte order. Is this correct? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 50: > 48: static { > 49: // KCR FIXME: get this from FFM > 50: SIZE_INT = 4; I will address this. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 55: > 53: /* members */ > 54: private MemorySegment segment; > 55: // private long address; I'll remove this (it's a leftover). modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 78: > 76: // note: may throw OOME: > 77: // KCR FIXME: Set a MemoryLayout > 78: this.segment = arena.allocate(len); I'll choose a memory layout and also specify 4-byte alignment. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 145: > 143: if (this.used > 0) { > 144: MemorySegment.copy(segment, 0, newSegment, 0, Math.min(this.used, len)); > 145: } @bourgesl I presume that there is never a need to copy more than `used` bytes? modules/javafx.graphics/src/main/java/com/sun/marlin/Renderer.java line 650: > 648: // KCR: Double-check this > 649: // Clear used bytes in edges array > 650: edges.setUsed(0); @bourgesl I presume that clearing `used` is correct here? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2897972083 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100387719 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100395691 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100385901 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100386573 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100397246 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100399348 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100402618 From lbourges at openjdk.org Fri Jun 6 12:07:43 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 6 Jun 2025 12:07:43 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:24:32 GMT, Kevin Rushforth wrote: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Few mlnor comments. It looks good to me ! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2932357785 From nlisker at openjdk.org Fri Jun 6 12:07:43 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 6 Jun 2025 12:07:43 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 20:22:28 GMT, Laurent Bourg?s wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Few mlnor comments. It looks good to me ! If it helps at this point, we did an initial prototype in the sandbox: https://github.com/openjdk/jfx-sandbox/tree/Marlin_FFM with several commits and reverts, so might need to go through them. What @bourgesl and I weren't sure about was which `Arena` to use. I thought `Confined` was more suitable than `Shared` because there's no multithreaded access. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2937611540 From kcr at openjdk.org Fri Jun 6 12:07:48 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:07:48 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 20:11:20 GMT, Laurent Bourg?s wrote: >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 46: >> >>> 44: // FFM stuff >>> 45: private static final ValueLayout.OfByte BYTE_LAYOUT = ValueLayout.JAVA_BYTE; >>> 46: private static final ValueLayout.OfInt INT_LAYOUT = ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN); >> >> @minborg Is this the best layout to use? I chose it thinking that, since we don't need to access this memory from native code, it might perform better to use Java's big endian byte order. Is this correct? > > It may depend on hardward arch ??? Based on some additional checking I did, there is no good reason to set the byte order explicitly, so I'll just use `ValueLayout.JAVA_INT`. >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 78: >> >>> 76: // note: may throw OOME: >>> 77: // KCR FIXME: Set a MemoryLayout >>> 78: this.segment = arena.allocate(len); >> >> I'll choose a memory layout and also specify 4-byte alignment. > > Yes 4-bytes min or more like 16 if it helps the compiler to use avx instructions for fill / copy ? I'll set it to 16 then. >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 145: >> >>> 143: if (this.used > 0) { >>> 144: MemorySegment.copy(segment, 0, newSegment, 0, Math.min(this.used, len)); >>> 145: } >> >> @bourgesl I presume that there is never a need to copy more than `used` bytes? > > True. Thanks for confirming. >> modules/javafx.graphics/src/main/java/com/sun/marlin/Renderer.java line 650: >> >>> 648: // KCR: Double-check this >>> 649: // Clear used bytes in edges array >>> 650: edges.setUsed(0); >> >> @bourgesl I presume that clearing `used` is correct here? > > Yes. (I skipped that code as edges were left dirty until the next init() call to reset it unconditionally, resize was just a realloc to trim array) Thanks for confirming. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2132049582 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2132050659 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2132051163 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2132051446 From kcr at openjdk.org Fri Jun 6 12:07:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:07:44 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 22:52:27 GMT, Nir Lisker wrote: > If it helps at this point, we did an initial prototype in the sandbox: https://github.com/openjdk/jfx-sandbox/tree/Marlin_FFM with several commits and reverts, so might need to go through them. Thanks. I took a look at it, and one of the things you did could be good for a follow-up: you use a memory layout that allows accessing data in a more structured manner than as a raw array of bytes or ints. For the initial conversion, I wanted to make minimal changes to the callers of OffHeapMemory, keeping the logic identical. This way everything about the implementation of OffHeap memory is encapsulated in the OffHeapMemory class. > What @bourgesl and I weren't sure about was which `Arena` to use. I thought `Confined` was more suitable than `Shared` because there's no multithreaded access. I wondered about that as well. I changed it to `ofConfined()` and don't see any problems so far. I'll run a full set of CI tests and if there are no problems, leave it at that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2949025806 From kcr at openjdk.org Fri Jun 6 12:07:45 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:07:45 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: <0KYNNTziaashmrozFgyS01l5Gtl9MKJO4a0_kjS0uOw=.7abbbf18-2523-4545-a951-d287ddd9f440@github.com> References: <0KYNNTziaashmrozFgyS01l5Gtl9MKJO4a0_kjS0uOw=.7abbbf18-2523-4545-a951-d287ddd9f440@github.com> Message-ID: <3QEeI1QC4bHumDrZh5V-A7hfXV_eZI9cwFXHlpCl6ew=.5c8ee79d-4a97-4bff-8863-9f99dfa75e11@github.com> On Wed, 21 May 2025 15:46:36 GMT, Andy Goryachev wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 110: > >> 108: >> 109: for (int i = 0; i < _ALPHA_MAP.length; i++) { >> 110: ALPHA_MAP_UNSAFE.putByte(i, _ALPHA_MAP[i]); > > I know you are trying to keep the diffs to a minimum, but since there is no more Unsafe, can we replace the "UNSAFE" with something more meaningful? Thanks for the reminder. I actually do want to change this. I had originally put a "FIXME" comment to do that, but removed it during the cleanup prior to the draft PR. My thought was to use something like "OFF_HEAP" rather than a bake the implementation of the off-heap memory into the name. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100676862 From lbourges at openjdk.org Fri Jun 6 12:07:47 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 6 Jun 2025 12:07:47 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Wed, 21 May 2025 14:07:28 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 46: > >> 44: // FFM stuff >> 45: private static final ValueLayout.OfByte BYTE_LAYOUT = ValueLayout.JAVA_BYTE; >> 46: private static final ValueLayout.OfInt INT_LAYOUT = ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN); > > @minborg Is this the best layout to use? I chose it thinking that, since we don't need to access this memory from native code, it might perform better to use Java's big endian byte order. Is this correct? It may depend on hardward arch ??? > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 78: > >> 76: // note: may throw OOME: >> 77: // KCR FIXME: Set a MemoryLayout >> 78: this.segment = arena.allocate(len); > > I'll choose a memory layout and also specify 4-byte alignment. Yes 4-bytes min or more like 16 if it helps the compiler to use avx instructions for fill / copy ? > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 145: > >> 143: if (this.used > 0) { >> 144: MemorySegment.copy(segment, 0, newSegment, 0, Math.min(this.used, len)); >> 145: } > > @bourgesl I presume that there is never a need to copy more than `used` bytes? True. > modules/javafx.graphics/src/main/java/com/sun/marlin/Renderer.java line 650: > >> 648: // KCR: Double-check this >> 649: // Clear used bytes in edges array >> 650: edges.setUsed(0); > > @bourgesl I presume that clearing `used` is correct here? Yes. (I skipped that code as edges were left dirty until the next init() call to reset it unconditionally, resize was just a realloc to trim array) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2122065109 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2122082408 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2105901398 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2122053941 From angorya at openjdk.org Fri Jun 6 12:07:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Jun 2025 12:07:45 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: <0KYNNTziaashmrozFgyS01l5Gtl9MKJO4a0_kjS0uOw=.7abbbf18-2523-4545-a951-d287ddd9f440@github.com> On Wed, 21 May 2025 13:24:32 GMT, Kevin Rushforth wrote: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 110: > 108: > 109: for (int i = 0; i < _ALPHA_MAP.length; i++) { > 110: ALPHA_MAP_UNSAFE.putByte(i, _ALPHA_MAP[i]); I know you are trying to keep the diffs to a minimum, but since there is no more Unsafe, can we replace the "UNSAFE" with something more meaningful? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2100627122 From kcr at openjdk.org Fri Jun 6 12:07:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:07:46 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Wed, 21 May 2025 14:04:55 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 36: > >> 34: // KCR: BEGIN DEBUG >> 35: import java.util.concurrent.atomic.AtomicInteger; >> 36: // KCR: END DEBUG > > I'll revert all of the debugging code. Reverted. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2132049928 From kcr at openjdk.org Fri Jun 6 12:16:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:16:13 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v2] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: ofShared() --> ofConfined() in one more place ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/b47d2edd..0ca24966 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Fri Jun 6 12:16:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 12:16:13 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 12:13:19 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > ofShared() --> ofConfined() in one more place modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 108: > 106: */ > 107: void resize(final long len) { > 108: Arena newArena = Arena.ofShared(); I missed changing this to `ofConfined()`, so will do that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2132081186 From kcr at openjdk.org Fri Jun 6 14:32:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 14:32:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v3] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/0ca24966..846cce08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Fri Jun 6 14:37:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 14:37:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v4] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Request alignment when reallocating segment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/846cce08..973e02f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Fri Jun 6 15:33:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 15:33:08 GMT Subject: RFR: 8358770: incubator.richtext pom missing dependency on incubator.input In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 15:27:33 GMT, Kevin Rushforth wrote: > This PR adds a missing maven dependency for `jfx.incubator.richtext` on the `jfx.incubator.input` module. The dependency is correctly present in the `module-info.java` of `jfx.incubator.richtext` as well as the gradle dependency for the project. It's only the maven dependency that is missing. While fixing this, I noticed that there is an unnecessary maven dependency in the `incubator.richtext` and `incubator.input` projects on the `graphics` project. Both projects already list `controls`, so do not need to list `graphics` or `base` (see the `fxml` and `web` projects for comparison). Reviewers: @andy-goryachev-oracle @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1821#issuecomment-2949612157 From kcr at openjdk.org Fri Jun 6 15:33:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Jun 2025 15:33:08 GMT Subject: RFR: 8358770: incubator.richtext pom missing dependency on incubator.input Message-ID: This PR adds a missing maven dependency for `jfx.incubator.richtext` on the `jfx.incubator.input` module. The dependency is correctly present in the `module-info.java` of `jfx.incubator.richtext` as well as the gradle dependency for the project. It's only the maven dependency that is missing. While fixing this, I noticed that there is an unnecessary maven dependency in the `incubator.richtext` and `incubator.input` projects on the `graphics` project. Both projects already list `controls`, so do not need to list `graphics` or `base` (see the `fxml` and `web` projects for comparison). ------------- Commit messages: - incubator.richtext pom missing dependency on incubator.input Changes: https://git.openjdk.org/jfx/pull/1821/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1821&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358770 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1821.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1821/head:pull/1821 PR: https://git.openjdk.org/jfx/pull/1821 From mstrauss at openjdk.org Fri Jun 6 23:28:41 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Jun 2025 23:28:41 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] Message-ID: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> JavaFX unnecessarily restricts interpolation in the following ways: 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1]. 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:

    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):
    Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function. This PR includes the following changes: 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1]. 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1]. 3. `SplineInterpolator` now accepts control points with Y any coordinate. ------------- Commit messages: - Allow interpolation outside of range [0,1] Changes: https://git.openjdk.org/jfx/pull/1822/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1822&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358820 Stats: 785 lines in 52 files changed: 536 ins; 33 del; 216 mod Patch: https://git.openjdk.org/jfx/pull/1822.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1822/head:pull/1822 PR: https://git.openjdk.org/jfx/pull/1822 From duke at openjdk.org Sat Jun 7 00:38:10 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 00:38:10 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment It appears that the CSS of the Window icons cannot be overridden; see below example which doesn't apply css.css. What is the proper/expected way to style the window icons; and should there be some documentation on this somewhere in HeaderBar? public class MyApp extends Application { @Override public void start(Stage stage) { Button button = new Button("My button"); HeaderBar.setAlignment(button, Pos.CENTER_LEFT); HeaderBar.setMargin(button, new Insets(5)); HeaderBar headerBar = new HeaderBar(); headerBar.setCenter(button); // Doesn't apply to window icons headerBar.getStylesheets().add(Objects.requireNonNull(getClass().getResource("css.css")).toExternalForm()); BorderPane root = new BorderPane(); root.setTop(headerBar); Scene scene = new Scene(root); // Doesn't apply to window icons scene.getStylesheets().add(Objects.requireNonNull(getClass().getResource("css.css")).toExternalForm()); stage.setScene(scene); stage.initStyle(StageStyle.EXTENDED); stage.show(); } } **css.css** (put in same directory as class) .iconify-button:hover, .maximize-button:hover { -fx-background-color: green; } .iconify-button.dark:hover, .maximize-button.dark:hover { -fx-background-color: yellow; } .close-button:hover { -fx-background-color: pink; } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951311555 From mstrauss at openjdk.org Sat Jun 7 01:07:11 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 7 Jun 2025 01:07:11 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sat, 7 Jun 2025 00:35:02 GMT, Cormac Redmond wrote: > It appears that the CSS of the Window icons cannot be overridden; see below example which doesn't apply css.css. > > What is the proper/expected way to style the window icons; and should there be some documentation on this somewhere in HeaderBar? The default buttons can't be styled, because their appearance is an unspecified implementation detail of the platform toolkit. These are the reasons for this decision: 1. Not all platform toolkits use CSS-styled buttons in the first place; macOS uses the system-provided buttons instead. So this would only work on some platforms. 2. Specifying these kinds of internals would increase the specification surface of this feature. All future improvements would be weighed down by compatibility constraints, because we wouldn't be able to change the implementation in a way that breaks existing applications (w.r.t. the internal structure of the buttons, style classes, and so on). If you need to customize the window buttons, the proper way is as follows: 1. Remove the default header buttons by setting their preferred height to 0, using the `HeaderBar.setPrefButtonHeight(Stage, double)` method. 2. Create your own buttons (just regular JavaFX buttons), place them in the header bar, and style them as you like. 3. Use `HeaderBar.setButtonType(Node, HeaderButtonType)` to tell JavaFX the semantic type of your buttons. This is important to enable window manager integrations with the native platform. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951354902 From duke at openjdk.org Sat Jun 7 01:16:11 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 01:16:11 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: <-V_bnL32w4wS0qFelnpyFnEckylo1jlUSGtPKS9D-IQ=.6685e690-47b2-4b7c-8c94-d4b476214436@github.com> On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment Thanks for the details. Take this for example: ![image](https://github.com/user-attachments/assets/96c987e2-6057-4936-9c8f-5136af302ad9) One needs to replace these to make these white instead of black? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951375412 From mstrauss at openjdk.org Sat Jun 7 01:20:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 7 Jun 2025 01:20:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment > Thanks for the details. > > Take this for example: > > One needs to replace these to make these white instead of black? Probably not, try setting `Scene.fill` to a color that resembles your dark background. The window buttons should adopt a matching color scheme with white glyphs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951383911 From duke at openjdk.org Sat Jun 7 01:23:09 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 01:23:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment Yeah, just looking into this which will apply dark or not: private boolean isDarkBackground(Paint paint) { return paint != null && Utils.calculateAverageBrightness(paint) < (double)0.5F; } Thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951391836 From duke at openjdk.org Sat Jun 7 01:29:09 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 01:29:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sat, 7 Jun 2025 01:04:39 GMT, Michael Strau? wrote: > By the way, there's a section in the `HeaderBar` documentation: "Custom header buttons". If you didn't get your answer from this section, it might suggest that we need to improve the documentation. No, the docs on that are good. Although, nothing stood out to make it obvious that the WindowDecoration.css styles cannot be overridden. Regarding the "dark" + scene fill, there are some good docs in HeaderButtonOverlay, but I don't know if the average developer would venture into there. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951407175 From mstrauss at openjdk.org Sat Jun 7 01:33:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 7 Jun 2025 01:33:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sat, 7 Jun 2025 01:26:09 GMT, Cormac Redmond wrote: > No, the docs on that are good. Although, nothing stood out to make it obvious that the WindowDecoration.css styles cannot be overridden. > > Regarding the "dark" + scene fill, there are some good docs in HeaderButtonOverlay, but I don't know if the average developer would venture into there. The documentation for that is in `StageStyle.EXTENDED`. Maybe that's the problem, that the documentation of this feature is spread across two different APIs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951410929 From duke at openjdk.org Sat Jun 7 01:50:08 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 01:50:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment Just something to consider regarding this "dark" mode reliance on a Scene's fill property. As far as I know, a Scene's fill property cannot be set via CSS. I have a light and dark theme (two css files), and the user can pick "light" or "dark", for example. A few well-known apps have quite a few themes to choose from, like AtlantaFX-based apps. Other apps allow users to supply custom CSS files, such as JabRef. In order for the window icons to appear correctly, one must programmatically call Scene.setFill(), setting it to something appropriate anytime a user changes theme, at runtime -- it seems to defeat the purpose of stylesheets a little to need to "know" how to set a scene's fill. Would it be more flexible to check the background colour of the HeaderBar instead, and base the isDarkBackground() check off that? Runtime stylesheet changes would also be picked up by HeaderButtonOverlay which would automatically adjust the window icons, and the developer doesn't need to call any code. Let the developer decide the bg colour of the HeaderBar. Would also cover the case where users might want a dark menu/header bar, but a otherwise "white" scene, or vica-versa. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951444277 From duke at openjdk.org Sat Jun 7 02:07:06 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 02:07:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sat, 7 Jun 2025 01:29:58 GMT, Michael Strau? wrote: > > No, the docs on that are good. Although, nothing stood out to make it obvious that the WindowDecoration.css styles cannot be overridden. > > Regarding the "dark" + scene fill, there are some good docs in HeaderButtonOverlay, but I don't know if the average developer would venture into there. > > The documentation for that is in `StageStyle.EXTENDED`. Maybe that's the problem, that the documentation of this feature is spread across two different APIs. > > I've created a ticket to track this: [JDK-8358823](https://bugs.openjdk.org/browse/JDK-8358823) Well, don't assume a "documentation problem" based on my comments alone. I hadn't read the docs properly in quite a long time. Thanks for all your work on this, it's looking very nice. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951461383 From mstrauss at openjdk.org Sat Jun 7 02:58:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 7 Jun 2025 02:58:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sat, 7 Jun 2025 01:47:15 GMT, Cormac Redmond wrote: > Just something to consider regarding this "dark" mode reliance on a Scene's fill property. > > As far as I know, a Scene's fill property cannot be set via CSS. > > I have a light and dark theme (two css files), and the user can pick "light" or "dark", for example. A few well-known apps have quite a few themes to choose from, like AtlantaFX-based apps. Other apps allow users to supply custom CSS files, such as JabRef. > > In order for the window icons to appear correctly, one must programmatically call Scene.setFill(), setting it to something appropriate anytime a user changes theme, at runtime -- it seems to defeat the purpose of stylesheets a little to need to "know" how to set a scene's fill. In the future, separate stylesheets for light and dark modes might not be required. PR #1655 proposes media feature queries that includes a scene-specific property `Scene.Preferences.colorScheme`, which can be queried in stylesheets. So when we get that feature, we could have the default header buttons adapt to the scene's color scheme instead of its fill color. And instead of swapping out stylesheets to toggle dark mode, you would only toggle the scene's color scheme property. > Would it be more flexible to check the background colour of the HeaderBar instead, and base the isDarkBackground() check off that? Runtime stylesheet changes would also be picked up by HeaderButtonOverlay which would automatically adjust the window icons, and the developer doesn't need to call any code. Let the developer decide the background colour of the HeaderBar (which can be via CSS). > > Would also cover the case where users might want a dark menu/header bar, but a otherwise "white" scene, or vica-versa. This would be the most flexible option, but it's also more difficult to implement. Consider the case where you have two header bars side by side (this is a supported configuration). Do we take the average background color of both header bars? Do we pick one of them? (And if so, how? Do we inspect the scene graph under the header buttons?) Can this behavior be overridden if it doesn't produce a good result in a specific use case? There are many questions to solve... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2951538997 From nlisker at openjdk.org Sat Jun 7 18:47:55 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 7 Jun 2025 18:47:55 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] In-Reply-To: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> Message-ID: On Fri, 6 Jun 2025 23:23:05 GMT, Michael Strau? wrote: > JavaFX unnecessarily restricts interpolation in the following ways: > 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1]. > 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:
    >
    > The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):
    > > > Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function. > > This PR includes the following changes: > 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1]. > 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1]. > 3. `SplineInterpolator` now accepts control points with any Y coordinate. Noting that this proposed change supersedes the previous changes that were done for for https://bugs.openjdk.org/browse/JDK-8226911. The proposed behavioral change makes sense. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1822#issuecomment-2952868294 From nlisker at openjdk.org Sat Jun 7 21:08:09 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 7 Jun 2025 21:08:09 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Wed, 12 Mar 2025 14:40:01 GMT, John Hendrikx wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| >> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Change StackOverflowException to warning log > - Support keeping last message in Logging helper The test code is somewhat complex. I've reviewed some of it. Except for minor formatting remarks about missing lines and spaces, it would help to add more documentation (I gave some examples) since that will help the reader a lot; there are several helper classes that require diving into in order to understand what they do what they are for. If you could give the test code a pass with these changes, it will also make reviewing easier. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 67: > 65: > 66: public class ObservableValueTest { > 67: private static final int[] PATTERN = new int[] {1, 2, 0, 50, 3, 7}; Minor: empty line after class here and other places. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 70: > 68: > 69: /* > 70: * ObservableValue cases to test: I would add that 2 values are provided to transition between for each properties test. For bindings, a setter and a modifier are provided too. I suggest that `Case`'s docs will outline what they are for. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 90: > 88: Case.of(new SimpleDoubleProperty(), 0.5, 1.0, p -> p.add(2), (p, v) -> p.setValue(v.doubleValue() - 2)), > 89: Case.of(new SimpleStringProperty(), "A!", "B!", p -> p.concat("!"), (p, v) -> p.setValue(v.substring(0, 1))), > 90: Case.of(new SimpleObjectProperty<>(), "A!", "B!", p -> Bindings.createObjectBinding(() -> (p.get() + "!").intern(), p), (p, v) -> p.setValue(v.substring(0, 1).intern())), // intern() used to make sure ObjectBinding equality check works for this test Break long line here and other places. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 118: > 116: @ParameterizedTest > 117: @MethodSource("inputs") > 118: void shouldIgnoreRemovingNonExistingListener(Action action) { Am I missing what is asserted in this test? Where is the "ignoring non-existing listeners" check being done? modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 126: > 124: > 125: action.removeListener(obs -> {}); > 126: action.removeListener((obs, old, current) -> {}); These can use the unnamed variables pattern `_`. Also in other places. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 152: > 150: if (changeListenerCount == 0) { > 151: valueSetter.accept(value1); > 152: action.assertEvents(); // when there are no change listeners, setting a different value (while invalid) should not trigger any events You can put this comment above the line if you prefer. Personally, I tend to put longer explanations above and more trivial notes on the same line, like `makeChanges(0); // no-op`. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 156: > 154: > 155: valueSetter.accept(value2); > 156: action.assertEvents(); Would add a comment such as "no event when setting the same value". modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 159: > 157: > 158: assertEquals(value2, action.getValue()); > 159: action.assertEvents(); Why do you need to `assertEvents` again? I don't see how `action.getValue()` could have relevant side effects. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 162: > 160: > 161: valueSetter.accept(value2); > 162: action.assertEvents(); Why is this needed again? modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 484: > 482: > 483: private static void assertCalls(Consumer step, AtomicInteger calls, int... expectedCalls) { > 484: for(int i = 0; i < expectedCalls.length; i++) { Space after `for`s and `if`s, in other places too. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 490: > 488: } > 489: > 490: static class Action implements ObservableValue { Can be `private`. Same for `Case` and some others. Not that there's a big risk of using these classes from other places in the package, but the confinement helps the reader understand that its used specifically in this class. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 525: > 523: } > 524: > 525: void setListenerCounts(int invalidationListenerCount, int changeListenerCount) { I would add some docs/comments saying that this methods trims/pads to the given number of listeners. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 545: > 543: InvalidationListener invalidationListener = obs -> { > 544: records.add("Invalidation of " + j); > 545: }; Can be a a simple expression. Also in other places. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 642: > 640: } > 641: > 642: static class Case

    , T> { I suggest adding some Javadoc or plain comments to this class and/or its parameters that explain how it's used. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 669: > 667: * Takes a list of values and creates an iterator of pairs of those values. The iterator > 668: * does not only return all possible pair combinations, but also different transitions between > 669: * two pairs. Effectively, given x values it returns x^3 combinations. Very worth noting that the pairs are used for the numbers for invalidation and change listeners. Also, there are duplicate pairs with the same pairs before and after, so it seems to be repeating the same state. For example, the sequence [1, 2] [1, 0] [1, 50] repeats several times. Not sure if this is on purpose, but looks redundant. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 723: > 721: } > 722: > 723: sealed interface Record { Maybe a doc/comment like "Records listener additions, removals, and value changes so that they can then be checked to be correct."? Can also be `private`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-2679851206 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1992282573 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1992627970 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1992432871 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134145247 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134118437 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134148752 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134147713 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134151713 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134151771 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1992578749 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134116370 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134101554 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134118842 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134086519 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1992613836 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134122360 From nlisker at openjdk.org Sat Jun 7 21:13:04 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 7 Jun 2025 21:13:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 14:51:18 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: >> >> - Clean-up and add tests >> - Pass in listener data directly for fireValueChanged calls >> - Fix documentation in a few places >> - Remove unused interface >> - Update copyrights and add missing > > I'll put this back on my review queue. It would be good to get this in. @kevinrushforth Since you wanted to review this PR, I suggest an early start if this is to go into the upcoming release (and I think it should). There's quite a lot to go over and it'd be beneficial to integrate this before RDP 1. mstr and I already finished our reviews (I have more test code to go over, but it's not an integration blocker), so 1 more reviewer needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2953040563 From duke at openjdk.org Sat Jun 7 23:07:09 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sat, 7 Jun 2025 23:07:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment I am noticing some strange artifacts, whereby the window icons are partially or completely disappearing, or (more often) their styling is not changing on hover. I don't have a screenshot of all three disappearing, but it has happened. I am not doing anything unusual, so this is odd. I know such a "bug" report without a reproducible example, is a pain. But this is just an FYI, that *something* is happening. No other styling is affected, just these windows icons. I will post more when I know more. Here, my mouse was hovering over X (not in screenshot), note it isn't red: ![bug3](https://github.com/user-attachments/assets/d3bca8a1-0700-4376-b720-5199f9449d52) Here, one icon has disappeared: ![bug2](https://github.com/user-attachments/assets/a9486ecf-0bf4-49a4-be98-43c056c6cb77) Here, two have: ![bug1](https://github.com/user-attachments/assets/9d9f6575-123f-484d-bcc4-0753f354ed9c) What I appear to be able to reproduce the easiest, is where the three icons are still visible, but styling does not change on hover. All I need to do is click around my app a little bit, loading a few different (unrelated) views, and this "bug" occurs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2953191791 From tsayao at openjdk.org Sat Jun 7 23:26:37 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 7 Jun 2025 23:26:37 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v27] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... 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 31 commits: - Merge branch 'master' into 8354943 - Fix typo - Improve StageOwnershipTest - Always report new size (for Kwin) - Merge branch 'master' into 8354943 - Merge remote-tracking branch 'origin/8354943' into 8354943 - Merge branch 'master' into 8354943 - Fix debug value - Merge branch 'master' into 8354943 - - Fixes on TestStage - ... and 21 more: https://git.openjdk.org/jfx/compare/11f31146...ee44b0e6 ------------- Changes: https://git.openjdk.org/jfx/pull/1789/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=26 Stats: 3912 lines in 28 files changed: 2658 ins; 745 del; 509 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 nlisker at openjdk.org Sun Jun 8 00:46:03 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 8 Jun 2025 00:46:03 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Wed, 12 Mar 2025 14:40:01 GMT, John Hendrikx wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| >> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe... > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Change StackOverflowException to warning log > - Support keeping last message in Logging helper modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 671: > 669: * two pairs. Effectively, given x values it returns x^3 combinations. > 670: */ > 671: private static class Combinations implements Iterable { Can be a `record Combinations(int[] values)`. modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 708: > 706: } > 707: > 708: int[] next = new int[] {values[x], values[(y + s) % m]}; Since the iteration is always over a pair of values, wouldn't it be more appropriate to use something like a `record ListenerNumbers(int invalidations, int changes)`? It would also make `Combinations` clearer. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134236677 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134237017 From jhendrikx at openjdk.org Sun Jun 8 08:16:07 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 08:16:07 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <2ztXr9UG2dPhUjjrGoLGowVntuQEEeuDEYUFgbk6FZc=.819b23e8-4be5-465f-a36a-9854fd2603e2@github.com> On Thu, 13 Mar 2025 03:31:13 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 70: > >> 68: >> 69: /* >> 70: * ObservableValue cases to test: > > I would add that 2 values are provided to transition between for each properties test. For bindings, a setter and a modifier are provided too. I suggest that `Case`'s docs will outline what they are for. I've been re-reading my own test code (as it is I think 2 years old already), and I added more docs where it was unclear :) I added more docs here especially. > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 669: > >> 667: * Takes a list of values and creates an iterator of pairs of those values. The iterator >> 668: * does not only return all possible pair combinations, but also different transitions between >> 669: * two pairs. Effectively, given x values it returns x^3 combinations. > > Very worth noting that the pairs are used for the numbers for invalidation and change listeners. > > Also, there are duplicate pairs with the same pairs before and after, so it seems to be repeating the same state. For example, the sequence > [1, 2] > [1, 0] > [1, 50] > repeats several times. Not sure if this is on purpose, but looks redundant. It was intended; the add/removal code is complex (as it may switch implementations to conserve memory) and we need to be absolutely sure that a simple action like adding or removing a listener (even of a different type) doesn't affect the system. In `ExpressionListener` there were bugs were adding or removing a listener could affect the next change being detected or not, and we'd want to make sure that can't happen. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134524537 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134524011 From jhendrikx at openjdk.org Sun Jun 8 09:11:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:11:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 7 Jun 2025 20:05:51 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 490: > >> 488: } >> 489: >> 490: static class Action implements ObservableValue { > > Can be `private`. Same for `Case` and some others. Not that there's a big risk of using these classes from other places in the package, but the confinement helps the reader understand that its used specifically in this class. I tend to leave out unnecessary modifiers in test cases to keep things more concise. Being a test case, and an inner class, I think that should be sufficient to alert the reader that it is specific for this class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134556112 From jhendrikx at openjdk.org Sun Jun 8 09:15:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:15:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 7 Jun 2025 20:12:10 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 126: > >> 124: >> 125: action.removeListener(obs -> {}); >> 126: action.removeListener((obs, old, current) -> {}); > > These can use the unnamed variables pattern `_`. Also in other places. I think that just hurts readability. This makes it clear that one is a dummy invalidation listener and the other is a dummy change listener. I think that even goes for almost all uses of `_` except maybe for deconstruction patterns (as the record name is still mentioned then). The extra variable name(s) help(s) to see which kind of lambda it is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134558373 From jhendrikx at openjdk.org Sun Jun 8 09:20:01 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:20:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 7 Jun 2025 20:44:04 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 118: > >> 116: @ParameterizedTest >> 117: @MethodSource("inputs") >> 118: void shouldIgnoreRemovingNonExistingListener(Action action) { > > Am I missing what is asserted in this test? Where is the "ignoring non-existing listeners" check being done? I added a comment here, but as the code should "ignore" the action, I expect nothing to happen (ie. no exception). Since tests fail if an exception **is** thrown the test does what it should do. I've added `assertDoesNotThrow` to make it even more explicit. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134562103 From jhendrikx at openjdk.org Sun Jun 8 09:27:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:27:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 7 Jun 2025 20:55:47 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 152: > >> 150: if (changeListenerCount == 0) { >> 151: valueSetter.accept(value1); >> 152: action.assertEvents(); // when there are no change listeners, setting a different value (while invalid) should not trigger any events > > You can put this comment above the line if you prefer. Personally, I tend to put longer explanations above and more trivial notes on the same line, like `makeChanges(0); // no-op`. I usually don't count explanatory comments like this against the line length limit (when a line exceeds some arbitrary limit, I don't mind if the part exceeding is purely explanatory or boiler-plate that would just introduce more noise if split over several lines -- this example, but also things like `throws` clauses). I've shortened the comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134564367 From jhendrikx at openjdk.org Sun Jun 8 09:31:06 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:31:06 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 7 Jun 2025 20:59:29 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 159: > >> 157: >> 158: assertEquals(value2, action.getValue()); >> 159: action.assertEvents(); > > Why do you need to `assertEvents` again? I don't see how `action.getValue()` could have relevant side effects. That's exactly the point. It should have no side effects, so there should be no events to assert (no templates are passed). I've added docs to `assertEvents` to make that a bit more clear. Edit: I made it even more clear now by having another helper function called `assertNoEvents`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134565667 From jhendrikx at openjdk.org Sun Jun 8 09:39:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:39:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v16] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 7 Jun 2025 23:56:38 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change StackOverflowException to warning log >> - Support keeping last message in Logging helper > > modules/javafx.base/src/test/java/test/javafx/beans/ObservableValueTest.java line 708: > >> 706: } >> 707: >> 708: int[] next = new int[] {values[x], values[(y + s) % m]}; > > Since the iteration is always over a pair of values, wouldn't it be more appropriate to use something like a `record ListenerNumbers(int invalidations, int changes)`? It would also make `Combinations` clearer. I've changed it; I must have been feeling particularly frugal when I wrote this :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r2134574625 From jhendrikx at openjdk.org Sun Jun 8 09:51:53 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:51:53 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v17] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add documentation to tests and improved readability ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/48364cc7..0b508425 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=15-16 Stats: 262 lines in 1 file changed: 133 ins; 21 del; 108 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Sun Jun 8 09:57:54 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 09:57:54 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v18] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener... John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'master' into feature/nested-emission-with-correct-old-values - Add documentation to tests and improved readability - Change StackOverflowException to warning log - Support keeping last message in Logging helper - Formatting - Suppress warnings on some unchecked casts - Add final to public methods of ArrayManager - Remove duplicate code - Doc fixes - Break up long lines of code - ... and 47 more: https://git.openjdk.org/jfx/compare/11f31146...829edb10 ------------- Changes: https://git.openjdk.org/jfx/pull/1081/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=17 Stats: 5103 lines in 42 files changed: 4879 ins; 29 del; 195 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Sun Jun 8 11:18:51 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 8 Jun 2025 11:18:51 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v19] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix broken test case (after bad asserts were fixed) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/829edb10..ac37e87b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From mariushanl at web.de Sun Jun 8 12:32:24 2025 From: mariushanl at web.de (Marius Hanl) Date: Sun, 8 Jun 2025 12:32:24 +0000 Subject: CFV: New OpenJFX Committer: Alexander Zuev In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Sun Jun 8 12:43:58 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 8 Jun 2025 12:43:58 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v4] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 14:37:40 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Request alignment when reallocating segment Code looks good to me, just some minor nitpicks. Note that I'm not an expert when it comes to FFM, but everything looks very reasonable to me. Will do some more tests with some applications. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 53: > 51: arena = Arena.ofConfined(); > 52: > 53: // note: may throw OOME: This note is probably outdated? You removed it at least below, so probably can do here as well? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 69: > 67: /** > 68: * Gets the length of this array. > 69: * Minor: The javadoc below has no empty line between the description and the return, so maybe remove here as well? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 94: > 92: /** > 93: * Increments the number of bytes currently being used. > 94: * Curr used + incr used must be <= length Typo? Can be named to: `Current used + increment must be <= length` maybe. ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2908451282 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2134678482 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2134678600 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2134678845 From duke at openjdk.org Sun Jun 8 14:43:09 2025 From: duke at openjdk.org (Cormac Redmond) Date: Sun, 8 Jun 2025 14:43:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 00:50:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename WindowManager to DesktopEnvironment > I am noticing some strange artifacts, whereby the window icons are partially or completely disappearing, or (more often) their styling is not changing on hover. > > I don't have a screenshot of all three disappearing, but it has happened. > > I am not doing anything unusual, so this is odd. I know such a "bug" report without a reproducible example, is a pain. But this is just an FYI, that _something_ is happening. No other styling is affected, just these windows icons. I will post more when I know more. > > Here, my mouse was hovering over X (not in screenshot), note it isn't red: ![bug3](https://private-user-images.githubusercontent.com/1417880/452657243-d3bca8a1-0700-4376-b720-5199f9449d52.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDkzOTA4MzQsIm5iZiI6MTc0OTM5MDUzNCwicGF0aCI6Ii8xNDE3ODgwLzQ1MjY1NzI0My1kM2JjYThhMS0wNzAwLTQzNzYtYjcyMC01MTk5Zjk0NDlkNTIucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDYwOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA2MDhUMTM0ODU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZGE4N2IzMTEyMTFiMzIwZmRjYWYzMjAyYWE4MzYxMTA4YzQxYmM4ZmI3MmUwYjg5Mjg3NThlNDJjMDFlYTBjZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.Sn3IcmQCWYmpg3c_gAf70tsKCqxpwQAdlL7o7_jiWJI) > > Here, one icon has disappeared: ![bug2](https://private-user-images.githubusercontent.com/1417880/452657257-a9486ecf-0bf4-49a4-be98-43c056c6cb77.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDkzOTA4MzQsIm5iZiI6MTc0OTM5MDUzNCwicGF0aCI6Ii8xNDE3ODgwLzQ1MjY1NzI1Ny1hOTQ4NmVjZi0wYmY0LTQ5YTQtYmU5OC00M2MwNTZjNmNiNzcucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDYwOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA2MDhUMTM0ODU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MmYzMGVlNjE0M2M2ZmNkYWNkNDZhOTVjMDg3NDRiNjQ0YmQxODJhYThkNDkwZjgzODg4M2RjMGY5NzU3YWI0NCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.-71_GSUuiG6KMvGgfw34lxBgJZJpK8fS9brUr-GCUsE) > > Here, two have: ![bug1](https://private-user-images.githubusercontent.com/1417880/452657262-9d9f6575-123f-484d-bcc4-0753f354ed9c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDkzOTA4MzQsIm5iZiI6MTc0OTM5MDUzNCwicGF0aCI6Ii8xNDE3ODgwLzQ1MjY1NzI2Mi05ZDlmNjU3NS0xMjNmLTQ4NGQtYmNjNC0wNzUzZjM1NGVkOWMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDYwOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA2MDhUMTM0ODU0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZGZjZjQxNDEzYWJkNGEwMjk1NWY5YTczZmI5ZTgzMjk3ZmJmNWNlNmUzMzU1MzJjZDY2YzJlOWM3NzQxZjliZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.r_0fKFUewCey6G6UVGLS9Lk25KUDh15ojs7u5fVnAeo) > > What I appear to be able to reproduce the easiest, is where the three icons are still visible, but styling does not change on hover. All I need to do is click around my app a little bit, loading a few different (unrelated) views, and this "bug" occurs. > > UPDATE: I think this issue is closely related to [#1605 (comment)](https://github.com/openjdk/jfx/pull/1605#issuecomment-2849128835) This is a frustrating "issue" in the sense that it's very much timing-related and even window-size specific, as to whether or not it occurs (i.e., the icons disappear). Ultimately, I found that the application in the screenshot was slightly mis-using this method in a ControlsFx's class: https://github.com/controlsfx/controlsfx/blob/4f1da99e4ebc15d8fc8cb44bf5476d39068b2eea/controlsfx/src/main/java/impl/org/controlsfx/ImplUtils.java#L51 ... long story short is that it was trying to, in some rare circumstances, erroneously wrap a DecorationPane in a DecorationPane (which was pointless, there's no reason to do that). A DecorationPane is something ControlsFx wraps root nodes in (usually without the developer knowing) in order to provide some of its functionality. This double wrapping bug, which was seemingly harmless until now, for whatever reason, was causing the display issues on the window icons (and oddly only when the window was a certain size...). When fixed, I can no longer reproduce the disappearing window icons issue. So I don't know if there's a bug worth investigating here or not, these comments are mainly intended as a source of information to others. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2954114081 From kcr at openjdk.org Mon Jun 9 15:08:29 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 15:08:29 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v4] In-Reply-To: References: Message-ID: <43-sU9wVuHIrGTLOr0y2itL-j_CjqcJ807M2FfkMug8=.0f183809-0f10-4398-a131-b35c6fd62a60@github.com> On Sun, 8 Jun 2025 12:37:01 GMT, Marius Hanl wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Request alignment when reallocating segment > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 53: > >> 51: arena = Arena.ofConfined(); >> 52: >> 53: // note: may throw OOME: > > This note is probably outdated? > You removed it at least below, so probably can do here as well? It's still relevant, so I added back the comment I inadvertently removed. > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 69: > >> 67: /** >> 68: * Gets the length of this array. >> 69: * > > Minor: The javadoc below has no empty line between the description and the return, so maybe remove here as well? done > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 94: > >> 92: /** >> 93: * Increments the number of bytes currently being used. >> 94: * Curr used + incr used must be <= length > > Typo? Can be named to: `Current used + increment must be <= length` maybe. Fixed. I also changed the name of the argument to be `increment` for clarity. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135878253 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135878478 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135879497 From nlisker at openjdk.org Mon Jun 9 15:07:50 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 9 Jun 2025 15:07:50 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v4] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 14:37:40 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Request alignment when reallocating segment Do you think it's worth asking someone on the Panama team to take a look? It's the first FFM introduction into JavaFX, they might have worthwhile comments. Memory leaks can hide in native memory in a way that's hard to find, such as from improper closure of resources. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956058505 From angorya at openjdk.org Mon Jun 9 15:11:28 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 15:11:28 GMT Subject: RFR: 8358770: incubator.richtext pom missing dependency on incubator.input In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 15:27:33 GMT, Kevin Rushforth wrote: > This PR adds a missing maven dependency for `jfx.incubator.richtext` on the `jfx.incubator.input` module. The dependency is correctly present in the `module-info.java` of `jfx.incubator.richtext` as well as the gradle dependency for the project. It's only the maven dependency that is missing. While fixing this, I noticed that there is an unnecessary maven dependency in the `incubator.richtext` and `incubator.input` projects on the `graphics` project. Both projects already list `controls`, so do not need to list `graphics` or `base` (see the `fxml` and `web` projects for comparison). I can't build maven artifacts, but the changes look right. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1821#pullrequestreview-2910380217 From angorya at openjdk.org Mon Jun 9 15:11:56 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 15:11:56 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sat, 7 Jun 2025 02:04:06 GMT, Cormac Redmond wrote: > Although, nothing stood out to make it obvious that the WindowDecoration.css styles cannot be overridden. I fell into that trap a number of times ;-) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2956085900 From kcr at openjdk.org Mon Jun 9 15:13:49 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 15:13:49 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/973e02f0..e755188e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=03-04 Stats: 7 lines in 1 file changed: 2 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From lbourges at openjdk.org Mon Jun 9 15:18:31 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 9 Jun 2025 15:18:31 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:13:49 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks good to me, as it mimics the former Unsafe usage. ------------- Marked as reviewed by lbourges (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2910403583 From kcr at openjdk.org Mon Jun 9 15:32:57 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 15:32:57 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v4] In-Reply-To: References: Message-ID: <11-pXylblvqMzNE1-Tv-ZP8DJKs-WU6QI8WJI_D4PuA=.845f416a-55d2-4e1c-b199-178b62660566@github.com> On Mon, 9 Jun 2025 15:00:27 GMT, Nir Lisker wrote: > Do you think it's worth asking someone on the Panama team to take a look? It's the first FFM introduction into JavaFX, they might have worthwhile comments. Memory leaks can hide in native memory in a way that's hard to find, such as from improper closure of resources. That would probably be helpful. I had tagged @minborg earlier and will reach out directly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956127187 From angorya at openjdk.org Mon Jun 9 15:33:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 15:33:00 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:13:49 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 47: > 45: /* members */ > 46: private MemorySegment segment; > 47: private long length; just curious: why `long`? are we expecting the length to exceed 2 billion? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 79: > 77: * @return number of used bytes > 78: */ > 79: int getUsed() { wait, length is `long`, but used is `int`? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 97: > 95: */ > 96: void incrementUsed(int increment) { > 97: this.used += increment; if used > 2B, it will overflow, right? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 157: > 155: return segment.get(INT_LAYOUT, offset); > 156: } > 157: extra newline? modules/javafx.graphics/src/main/java/com/sun/marlin/Renderer.java line 399: > 397: > 398: final long SIZE_INT = 4L; > 399: long addr = edgePtr; minor: extra spaces? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135938366 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135942265 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135943404 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135946319 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135947245 From angorya at openjdk.org Mon Jun 9 15:37:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 15:37:01 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:13:49 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.graphics/src/main/java/com/sun/marlin/RendererNoAA.java line 379: > 377: // note: throw IOOB if neededSize > 2Gb: > 378: final long edgeNewSize = ArrayCacheConst.getNewLargeSize( > 379: _edges.getLength(), L377 is unclear - is this a TODO to throw IOOBE or a description of what would happen? (this is a separate issue from FFM changes, really) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135953520 From angorya at openjdk.org Mon Jun 9 15:40:03 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 15:40:03 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:13:49 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I am getting this printed to stderr when launching the monkey tester: WARNING: A restricted method in java.lang.System has been called WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:/Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/bin/) WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module WARNING: Restricted methods will be blocked in a future release unless native access is enabled why? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956160643 From pminborg at openjdk.org Mon Jun 9 15:47:00 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 9 Jun 2025 15:47:00 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:13:49 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 47: > 45: /* members */ > 46: private MemorySegment segment; > 47: private long length; Maybe we can remove the `length` field and instead use `segment.byteSize()`? modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 106: > 104: */ > 105: void resize(final long len) { > 106: Arena newArena = Arena.ofConfined(); The comment "updating address is MANDATORY" can be removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135969859 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135967463 From angorya at openjdk.org Mon Jun 9 15:53:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 15:53:06 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:13:49 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 129: > 127: > 128: void free() { > 129: arena.close(); since we don't assign arena to `null`, I assume that the code expects: 1. `free()` will be only called once 2. no access to this OffHeapArray happens after `free()` is called right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135979621 From mstrauss at openjdk.org Mon Jun 9 16:35:14 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 9 Jun 2025 16:35:14 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 14:39:55 GMT, Cormac Redmond wrote: > So I don't know if there's a bug worth investigating here or not, these comments are mainly intended as a source of information to others. This seems like a bug. If developers use an API wrongly, a clearly defined error should result; in this case, window buttons disappear or stop working. This can't be right. Is the software you're talking about open source, or can you reproduce the issue with ControlFx in a standalone app? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2956304958 From kcr at openjdk.org Mon Jun 9 17:40:02 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 17:40:02 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: <1pJAJj-v2eergSm0snRIphFAPMGbT6tkqD2Mbp8DX0c=.0ecbe49a-0192-41ee-a2dd-ba48195f3747@github.com> On Mon, 9 Jun 2025 15:37:27 GMT, Andy Goryachev wrote: > ``` > ... > WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module > WARNING: Restricted methods will be blocked in a future release unless native access is enabled > ``` > > why? Because you forgot to pass `--enable-native-access=javafx.graphics` See: https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-24.md#javafx-applications-must-use---enable-native-access ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956473288 From angorya at openjdk.org Mon Jun 9 17:45:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 17:45:57 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 11:49:56 GMT, Kevin Rushforth wrote: >> True. > > Thanks for confirming. Question: can the number of bytes to be copied depend on memory layout (BE vs LE)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136180694 From kcr at openjdk.org Mon Jun 9 17:55:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 17:55:21 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded "length" field, using segment,byteSize() instead Fix description of resize method. Minor whitespace changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/e755188e..b22ed6d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=04-05 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From angorya at openjdk.org Mon Jun 9 17:55:21 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 17:55:21 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: <1pJAJj-v2eergSm0snRIphFAPMGbT6tkqD2Mbp8DX0c=.0ecbe49a-0192-41ee-a2dd-ba48195f3747@github.com> References: <1pJAJj-v2eergSm0snRIphFAPMGbT6tkqD2Mbp8DX0c=.0ecbe49a-0192-41ee-a2dd-ba48195f3747@github.com> Message-ID: On Mon, 9 Jun 2025 17:36:55 GMT, Kevin Rushforth wrote: > --enable-native-access=javafx.graphics I did indeed forget. The `sun.misc.Unsafe` warning is no longer printed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956505509 From kcr at openjdk.org Mon Jun 9 17:55:22 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 17:55:22 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:25:22 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 47: > >> 45: /* members */ >> 46: private MemorySegment segment; >> 47: private long length; > > just curious: why `long`? are we expecting the length to exceed 2 billion? This is preexisting. The goal was to keep the same interface that the users of OffHeapMemory currently use, so I do not want to change or revisit this. Other than encapsulation, I made no changes to the OffHeap interface. > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 79: > >> 77: * @return number of used bytes >> 78: */ >> 79: int getUsed() { > > wait, length is `long`, but used is `int`? I noticed this too. This is preexisting, so I don't want to change it as part of this PR (to minimize changes). It might or might not be worth a follow-up. > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 97: > >> 95: */ >> 96: void incrementUsed(int increment) { >> 97: this.used += increment; > > if used > 2B, it will overflow, right? Yes. It seems worth checking and throw an exception. Other invariants could also be enforced such as used <= length. I'll file a follow-up issue for this, since this behavior is preexisting. > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 129: > >> 127: >> 128: void free() { >> 129: arena.close(); > > since we don't assign arena to `null`, I assume that the code expects: > > 1. `free()` will be only called once > 2. no access to this OffHeapArray happens after `free()` is called > > right? Correct. Note that `free` is only called by the cleaner once the user of the offheap array is no longer using it (i.e., when its cleaner object is unreachable). An exception would occur if `free` were called more than once or if there was an attempt to access the memory segment after the call to `free`. > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 157: > >> 155: return segment.get(INT_LAYOUT, offset); >> 156: } >> 157: > > extra newline? removed > modules/javafx.graphics/src/main/java/com/sun/marlin/Renderer.java line 399: > >> 397: >> 398: final long SIZE_INT = 4L; >> 399: long addr = edgePtr; > > minor: extra spaces? Preexisting. I don't want to reformat it. > modules/javafx.graphics/src/main/java/com/sun/marlin/RendererNoAA.java line 379: > >> 377: // note: throw IOOB if neededSize > 2Gb: >> 378: final long edgeNewSize = ArrayCacheConst.getNewLargeSize( >> 379: _edges.getLength(), > > L377 is unclear - is this a TODO to throw IOOBE or a description of what would happen? > (this is a separate issue from FFM changes, really) Yes, this is preexisting and not something to look at as part of this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135952740 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135953668 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135959177 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136152003 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136135909 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135959845 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2135970787 From kcr at openjdk.org Mon Jun 9 17:55:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 17:55:23 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:44:08 GMT, Per Minborg wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 47: > >> 45: /* members */ >> 46: private MemorySegment segment; >> 47: private long length; > > Maybe we can remove the `length` field and instead use `segment.byteSize()`? Thanks. I've done this. > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 106: > >> 104: */ >> 105: void resize(final long len) { >> 106: Arena newArena = Arena.ofConfined(); > > The comment "updating address is MANDATORY" can be removed. Good catch. I've remove this and added a better description. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136154724 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136155932 From kcr at openjdk.org Mon Jun 9 17:55:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 17:55:23 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 17:43:21 GMT, Andy Goryachev wrote: >> Thanks for confirming. > > Question: can the number of bytes to be copied depend on memory layout (BE vs LE)? No ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136195319 From angorya at openjdk.org Mon Jun 9 17:59:02 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 17:59:02 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: <9yg179m-mA-937Zo7PzHhZA-hMybYCwScUxQnttMSWI=.0ef51c06-6738-4b84-a80a-a05df415d90b@github.com> On Mon, 9 Jun 2025 17:55:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded "length" field, using segment,byteSize() instead > Fix description of resize method. > Minor whitespace changes Thank you for clarifications, Kevin. LGTM, apart from the possible int/long overflow, which is also in the original code (pre-existing, as you said). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2910870133 From prr at openjdk.org Mon Jun 9 19:18:41 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 19:18:41 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 17:55:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded "length" field, using segment,byteSize() instead > Fix description of resize method. > Minor whitespace changes modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 110: > 108: > 109: for (int i = 0; i < _ALPHA_MAP.length; i++) { > 110: ALPHA_MAP_OFF_HEAP.putByte(i, _ALPHA_MAP[i]); I guess this is only done once, but following multiple layers of calculation I think this array defaults to 64K long, in which case a bulk copy would be better, but it is perhaps out-of-scope for a 1:1 replacement https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemorySegment.html#copy(java.lang.Object,int,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,int) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136330006 From thiago.sayao at gmail.com Mon Jun 9 19:21:19 2025 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 9 Jun 2025 16:21:19 -0300 Subject: IA generated code policy Message-ID: Hi, I?ve been testing IntelliJ IDEA?s AI assistant (Junie) at my company, and I?m really impressed with it. It works surprisingly well and has been quite helpful (for example, to write tests). That got me thinking... Does OpenJFX have any specific guidelines or rules regarding the use of AI tools like this? -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbourges at openjdk.org Mon Jun 9 19:23:39 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 9 Jun 2025 19:23:39 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 17:55:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded "length" field, using segment,byteSize() instead > Fix description of resize method. > Minor whitespace changes Marked as reviewed by lbourges (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2911082105 From kcr at openjdk.org Mon Jun 9 19:45:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 19:45:35 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: <-8umei1ga8f0yrJdT19owvA4GkkqvRZm6ffhdDRj9_U=.e6d8cce6-1abd-40bd-8927-507c0e4eba81@github.com> On Mon, 9 Jun 2025 17:55:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded "length" field, using segment,byteSize() instead > Fix description of resize method. > Minor whitespace changes Thanks for the reviews. I'll leave this until tomorrow in case there are other comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956807534 From kcr at openjdk.org Mon Jun 9 19:45:36 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 19:45:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 19:15:35 GMT, Phil Race wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unneeded "length" field, using segment,byteSize() instead >> Fix description of resize method. >> Minor whitespace changes > > modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 110: > >> 108: >> 109: for (int i = 0; i < _ALPHA_MAP.length; i++) { >> 110: ALPHA_MAP_OFF_HEAP.putByte(i, _ALPHA_MAP[i]); > > I guess this is only done once, but following multiple layers of calculation I think this array defaults to 64K long, in which case a bulk copy would be better, but it is perhaps out-of-scope for a 1:1 replacement > > https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemorySegment.html#copy(java.lang.Object,int,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,int) Thanks. This seems like a good follow-up RFE. I'll file it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2136371921 From prr at openjdk.org Mon Jun 9 20:08:43 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 20:08:43 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 11:57:09 GMT, Kevin Rushforth wrote: > > If it helps at this point, we did an initial prototype in the sandbox: https://github.com/openjdk/jfx-sandbox/tree/Marlin_FFM with several commits and reverts, so might need to go through them. > > Thanks. I took a look at it, and one of the things you did could be good for a follow-up: you use a memory layout that allows accessing data in a more structured manner than as a raw array of bytes or ints. For the initial conversion, I wanted to make minimal changes to the callers of OffHeapMemory, keeping the logic identical. This way everything about the implementation of OffHeap memory is encapsulated in the OffHeapMemory class. > > > What @bourgesl and I weren't sure about was which `Arena` to use. I thought `Confined` was more suitable than `Shared` because there's no multithreaded access. > > I wondered about that as well. I changed it to `ofConfined()` and don't see any problems so far. I'll run a full set of CI tests and if there are no problems, leave it at that. Multi-threaded access in the sense of the not being used concurrently by different threads ? What FFM means is that the thread that creates the Arena is the only thread ever allowed to use the Arena or any memory allocated by it. I don't quite see how you guarantee a static field of a class is never accessed by another thread. And all it takes is for some other thread to have initialize the class and boom And how in fact is Marlin ensuring only one thread is ever used to run Marlin ? I didn't think it did anything of the kind. Is this just a case of the FX thread always runs it ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2956888833 From duke at openjdk.org Mon Jun 9 20:59:51 2025 From: duke at openjdk.org (Cormac Redmond) Date: Mon, 9 Jun 2025 20:59:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v81] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 16:32:45 GMT, Michael Strau? wrote: > > So I don't know if there's a bug worth investigating here or not, these comments are mainly intended as a source of information to others. > > This seems like a bug. If developers use an API wrongly, a clearly defined error should result; in this case, window buttons disappear or stop working. This can't be right. > > Is the software you're talking about open source, or can you reproduce the issue with ControlFx in a standalone app? I've narrowed it down to this, which is much simplified version of what my code + ControlsFX was doing; it consistently reproduces the issue. No third party libs needed. public class DisappearingWindowIcons extends Application { @Override public void start(Stage stage) { BorderPane root = new BorderPane(); root.setTop(new HeaderBar()); Button button = new Button("Click me for "bug" (hover of window icons after)!"); button.setOnAction(_ -> bug(root)); root.setCenter(button); stage.setScene(new Scene(root, 300, 200)); stage.initStyle(StageStyle.EXTENDED); stage.show(); } public void bug(Pane parentPane) { StackPane stackPane = new StackPane(); Parent originalParent = parentPane.getScene().getRoot(); parentPane.getScene().setRoot(stackPane); stackPane.getChildren().addFirst(originalParent); } } Note that I see some CSS errors, that weren't being logged before for me (at least not consistently, though I did see them): > WARNING: Caught 'java.lang.ClassCastException: class java.lang.String cannot be cast to class javafx.scene.paint.Paint (java.lang.String is in module java.base of loader 'bootstrap'; javafx.scene.paint.Paint is in module javafx.graphics at 25-internal of loader 'app')' while converting value for '-fx-background-color' from rule '*.button' in stylesheet jar:file:///C:/Users/credm/.m2/repository/org/openjfx/javafx-controls/25-internal+0-2025-06-06-234837/javafx-controls-25-internal+0-2025-06-06-234837-win.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2957015764 From kcr at openjdk.org Mon Jun 9 21:17:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 21:17:35 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 20:06:22 GMT, Phil Race wrote: > Multi-threaded access in the sense of the not being used concurrently by different threads ? What FFM means is that the thread that creates the Arena is the only thread ever allowed to use the Arena or any memory allocated by it. I don't quite see how you guarantee a static field of a class is never accessed by another thread. And all it takes is for some other thread to have initialize the class and boom > > And how in fact is Marlin ensuring only one thread is ever used to run Marlin ? I didn't think it did anything of the kind. Is this just a case of the FX thread always runs it ? The QuantumRenderer thread uses Marlin during rendering and the JavaFX application thread uses it during picking. @bourgesl can provide a more complete answer, but from what I see, all accesses to OffHeapArray are done via an instance of the RendererContext class. Marlin ensures that a RendererContext instance is created and accessed on the same thread by using thread local state and using the rendering context for the thread in question (or creating it if it is the first time). See [DMarlinRenderingEngine::getRendererContext](https://github.com/openjdk/jfx/blob/b22ed6d202f7bb3765fa402a748d455f6316f7c9/modules/javafx.graphics/src/main/java/com/sun/marlin/DMarlinRenderingEngine.java#L254). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957054365 From prr at openjdk.org Mon Jun 9 21:27:35 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 21:27:35 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> On Mon, 9 Jun 2025 21:15:08 GMT, Kevin Rushforth wrote: > > Multi-threaded access in the sense of the not being used concurrently by different threads ? What FFM means is that the thread that creates the Arena is the only thread ever allowed to use the Arena or any memory allocated by it. I don't quite see how you guarantee a static field of a class is never accessed by another thread. And all it takes is for some other thread to have initialize the class and boom > > And how in fact is Marlin ensuring only one thread is ever used to run Marlin ? I didn't think it did anything of the kind. Is this just a case of the FX thread always runs it ? > > The QuantumRenderer thread uses Marlin during rendering and the JavaFX application thread uses it during picking. > > @bourgesl can provide a more complete answer, but from what I see, all accesses to OffHeapArray are done via an instance of the RendererContext class. Marlin ensures that a RendererContext instance is created and accessed on the same thread by using thread local state and using the rendering context for the thread in question (or creating it if it is the first time). See [DMarlinRenderingEngine::getRendererContext](https://github.com/openjdk/jfx/blob/b22ed6d202f7bb3765fa402a748d455f6316f7c9/modules/javafx.graphics/src/main/java/com/sun/marlin/DMarlinRenderingEngine.java#L254). I'd looked at that but it was not obvious. And it definitely is not obvious that it will be the same thread that initialises the MaskMarlinAlphaConsumer.java class ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957070973 From angorya at openjdk.org Mon Jun 9 21:27:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 21:27:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> Message-ID: On Mon, 9 Jun 2025 21:23:47 GMT, Phil Race wrote: > I don't quite see how you guarantee a static field of a class is never accessed by another thread. Wouldn't a WrongThreadException be thrown if that happens? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957073638 From kcr at openjdk.org Mon Jun 9 21:40:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 21:40:41 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> Message-ID: <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> On Mon, 9 Jun 2025 21:23:47 GMT, Phil Race wrote: > > > Multi-threaded access in the sense of the not being used concurrently by different threads ? What FFM means is that the thread that creates the Arena is the only thread ever allowed to use the Arena or any memory allocated by it. I don't quite see how you guarantee a static field of a class is never accessed by another thread. And all it takes is for some other thread to have initialize the class and boom > > > And how in fact is Marlin ensuring only one thread is ever used to run Marlin ? I didn't think it did anything of the kind. Is this just a case of the FX thread always runs it ? > > > > > > The QuantumRenderer thread uses Marlin during rendering and the JavaFX application thread uses it during picking. > > @bourgesl can provide a more complete answer, but from what I see, all accesses to OffHeapArray are done via an instance of the RendererContext class. Marlin ensures that a RendererContext instance is created and accessed on the same thread by using thread local state and using the rendering context for the thread in question (or creating it if it is the first time). See [DMarlinRenderingEngine::getRendererContext](https://github.com/openjdk/jfx/blob/b22ed6d202f7bb3765fa402a748d455f6316f7c9/modules/javafx.graphics/src/main/java/com/sun/marlin/DMarlinRenderingEngine.java#L254). > > I'd looked at that but it was not obvious. And it definitely is not obvious that it will be the same thread that initialises the MaskMarlinAlphaConsumer.java class Yes, I see what you are saying. The `ALPHA_MASK_XXX` arrays are static fields of `MaskMarlinAlphaConsumer`, and the renderer context class has an instance field of `MaskMarlinAlphaConsumer`. So it does seem possible that `MaskMarlinAlphaConsumer` could be initialized by a thread other than the prism renderer thread. Hmmm. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957097495 From kcr at openjdk.org Mon Jun 9 21:43:36 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 21:43:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> Message-ID: On Mon, 9 Jun 2025 21:25:18 GMT, Andy Goryachev wrote: > > I don't quite see how you guarantee a static field of a class is never accessed by another thread. > > Wouldn't a WrongThreadException be thrown if that happens? Yes. If we had 100% complete test coverage for all possible use cases, the fact that we don't see such an exception would give us confidence, but we don't. So we either need to prove that it can't happen, or we will need to go back to using a shared arena -- at least for the two static off-heap arrays. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957101637 From kcr at openjdk.org Mon Jun 9 22:12:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 22:12:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> Message-ID: On Mon, 9 Jun 2025 21:38:22 GMT, Kevin Rushforth wrote: > > I'd looked at that but it was not obvious. And it definitely is not obvious that it will be the same thread that initialises the MaskMarlinAlphaConsumer.java class > > Yes, I see what you are saying. The `ALPHA_MASK_XXX` arrays are static fields of `MaskMarlinAlphaConsumer`, and the renderer context class has an instance field of `MaskMarlinAlphaConsumer`. So it does seem possible that `MaskMarlinAlphaConsumer` could be initialized by a thread other than the prism renderer thread. Hmmm. Fortunately, the presence of following field in RendererConext does not cause the MaskMarlinAlphaConsumer class to be initialized: public MaskMarlinAlphaConsumer consumer = null; I instrumented the code, adding something that _did_ force initialization and was able to provoke a WrongThreadException. Without my modification, MaskMarlinAlphaConsumer doesn't get initialized until rendering. This seems _very_ fragile, though. At best, presuming we can prove that initialization and access to MaskMarlinAlphaConsumer always happens on the Prism rendering thread, this is an accident waiting to happen. @bourgesl Do you have any thoughts on this? Using the shared arena is definitely safer, but there might be a performance penalty. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957147725 From angorya at openjdk.org Mon Jun 9 22:26:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 22:26:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: <9TIRgVDPOqf9CJbYrwGGu_Wu3wkODDHb3BxKxyMhhN4=.aa653013-16d0-4d16-a485-797b68892ba9@github.com> On Mon, 9 Jun 2025 17:55:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded "length" field, using segment,byteSize() instead > Fix description of resize method. > Minor whitespace changes the `MaskMarlinAlphaConsumer` field in `RendererContext` is created/resized in DMarlinRasterizer:102 perhaps we could refactor this code to hide the public field and ensure the single threaded access? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957172587 From kcr at openjdk.org Mon Jun 9 22:59:36 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Jun 2025 22:59:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: <9TIRgVDPOqf9CJbYrwGGu_Wu3wkODDHb3BxKxyMhhN4=.aa653013-16d0-4d16-a485-797b68892ba9@github.com> References: <9TIRgVDPOqf9CJbYrwGGu_Wu3wkODDHb3BxKxyMhhN4=.aa653013-16d0-4d16-a485-797b68892ba9@github.com> Message-ID: On Mon, 9 Jun 2025 22:24:08 GMT, Andy Goryachev wrote: > the `MaskMarlinAlphaConsumer` field in `RendererContext` is created/resized in DMarlinRasterizer:102 > > perhaps we could refactor this code to hide the public field and ensure the single threaded access? That would get into the sort of changes I'd prefer not to make, at least not as part of the initial Unsafe --> FFM conversion, although Laurent could comment on that. Other possibilities include: using thread-local storage for the ALPHA_MAP_XXX off heap arrays (in practice, they are only used from the Quantum renderer thread, so there would only ever be one copy) or dispensing with off-heap arrays entirely for the ALPHA_MAP, and using plain Java arrays. Given how these static arrays are used, I'm not sure using off-heap memory is really buying much in terms of performance (as opposed to the dynamic edges array, which is the primary use of off-heap memory). Really, though, the simplest thing to do for now is to use shared (rather than confined) access for these two arrays and file a follow-up to optimize it if needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957225458 From angorya at openjdk.org Mon Jun 9 23:38:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Jun 2025 23:38:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: <9TIRgVDPOqf9CJbYrwGGu_Wu3wkODDHb3BxKxyMhhN4=.aa653013-16d0-4d16-a485-797b68892ba9@github.com> Message-ID: On Mon, 9 Jun 2025 22:57:20 GMT, Kevin Rushforth wrote: > Really, though, the simplest thing to do for now is to use shared I agree. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2957289771 From tsayao at openjdk.org Mon Jun 9 23:54:03 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 9 Jun 2025 23:54:03 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v28] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Adjust includes - Remove work-around to allow unresizable Stages to be resized - Other minor adjustments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/ee44b0e6..c94f1dff Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=27 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=26-27 Stats: 136 lines in 7 files changed: 47 ins; 73 del; 16 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 duke at openjdk.org Tue Jun 10 00:38:33 2025 From: duke at openjdk.org (Jeff Alder) Date: Tue, 10 Jun 2025 00:38:33 GMT Subject: RFR: 8358770: incubator.richtext pom missing dependency on incubator.input In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 15:27:33 GMT, Kevin Rushforth wrote: > This PR adds a missing maven dependency for `jfx.incubator.richtext` on the `jfx.incubator.input` module. The dependency is correctly present in the `module-info.java` of `jfx.incubator.richtext` as well as the gradle dependency for the project. It's only the maven dependency that is missing. While fixing this, I noticed that there is an unnecessary maven dependency in the `incubator.richtext` and `incubator.input` projects on the `graphics` project. Both projects already list `controls`, so do not need to list `graphics` or `base` (see the `fxml` and `web` projects for comparison). Awesome! I submitted the JBS; thanks for hopping on this so fast. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1821#issuecomment-2951473461 From tsayao at openjdk.org Tue Jun 10 01:02:11 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 10 Jun 2025 01:02:11 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v29] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Remove testWindowShowOrder because it fails due to the Window Manager ignoring too often focus requests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/c94f1dff..b68dab95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=28 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=27-28 Stats: 45 lines in 3 files changed: 0 ins; 39 del; 6 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 mstrauss at openjdk.org Tue Jun 10 02:47:20 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Jun 2025 02:47:20 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v82] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - Rename default window button style classes - Set the scene root as the parent of the overlay node ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/e17fe8bf..96a0d796 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=81 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=80-81 Stats: 208 lines in 9 files changed: 29 ins; 0 del; 179 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Tue Jun 10 02:51:34 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Jun 2025 02:51:34 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: only dispose ViewSceneOverlay when non-null ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/96a0d796..cdb24bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=82 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=81-82 Stats: 8 lines in 1 file changed: 6 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Tue Jun 10 03:24:48 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Jun 2025 03:24:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null As it turns out, the CSS engine _really_ wants all styleable nodes to be traceable to a single root node. If that's not the case (as in this PR with the overlay buttons), all kinds of things go wrong. I've fixed this issue by having the scene's root node be the parent of the scene overlay. Note that only the overlay knows that the scene root is its parent, the scene root has no knowledge of that (i.e. the overlay is not a child of the scene root that you can see with `Parent.getChildrenUnmodifiable()`) With this change, the CSS engine works correctly. As a side effect, it now also picks up stylesheets of the root node. This makes it possible to interfere with the internal stylesheets of the button overlay. In order to reduce the chance of that happening, I've renamed all style classes to have the `-FX-INTERNAL-` prefix. This should hopefully make it clear enough that this is not public API. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2957567079 From duke at openjdk.org Tue Jun 10 06:15:39 2025 From: duke at openjdk.org (duke) Date: Tue, 10 Jun 2025 06:15:39 GMT Subject: Withdrawn: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Sat, 4 May 2024 22:55:13 GMT, Martin Fox wrote: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1449 From lkostyra at openjdk.org Tue Jun 10 08:30:35 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 10 Jun 2025 08:30:35 GMT Subject: RFR: 8351867: No UI changes while iconified In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:23:38 GMT, Martin Fox wrote: >The test fails on all platforms without this PR. With this PR the test succeeds on Linux and Windows for regular windows and fails when de-iconifying to a maximized state. It also fails on Windows for TRANSPARENT stages since we never get a WM_PAINT message and so glass never calls notifyRepaint. I'm trying to figure out how to exactly proceed with this. It would be nice to add this change and to also have the test in the repository, but it does fail for some cases like you mentioned (and I also verified that on my Windows machine). Would those cases be fixable? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2958155465 From duke at openjdk.org Tue Jun 10 11:12:49 2025 From: duke at openjdk.org (Cormac Redmond) Date: Tue, 10 Jun 2025 11:12:49 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 03:21:53 GMT, Michael Strau? wrote: > As it turns out, the CSS engine _really_ wants all styleable nodes to be traceable to a single root node. If that's not the case (as in this PR with the overlay buttons), all kinds of things go wrong. > > I've fixed this issue by having the scene's root node be the parent of the scene overlay. Note that only the overlay knows that the scene root is its parent, the scene root has no knowledge of that (i.e. the overlay is not a child of the scene root that you can see with `Parent.getChildrenUnmodifiable()`) > > With this change, the CSS engine works correctly. As a side effect, it now also picks up stylesheets of the root node. This makes it possible to interfere with the internal stylesheets of the button overlay. In order to reduce the chance of that happening, I've renamed all style classes to have the `-FX-INTERNAL-` prefix. This should hopefully make it clear enough that this is not public API. Confirmed that this change has fixed the issue... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2958743960 From kcr at openjdk.org Tue Jun 10 13:21:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 13:21:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 17:55:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded "length" field, using segment,byteSize() instead > Fix description of resize method. > Minor whitespace changes It turns out there is an even simpler solution: defer the initialization of the static OffHeapArray objects to the constructor of `MaskMarlinAlphaConsumer`. Only the QuantumRenderer thread will construct an instance of `MaskMarlinAlphaConsumer`. I verified that even in the case where I force the class to be initialized on the wrong thread, it works correctly. I'll do some additional testing and then push a fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2959236774 From andy.goryachev at oracle.com Tue Jun 10 14:29:26 2025 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 10 Jun 2025 14:29:26 +0000 Subject: CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange) In-Reply-To: References: <8d32334e-cb6e-4d62-9138-a917a8549ecc@gmail.com> Message-ID: Dear Pavel: Since the CodeArea is designed to support large models, adding the kind of values you ask to every update might be prohibitively expensive and/or impossible, given the dependency on the line endings format. A solution is possible however - one can extend CodeTextModel to implement obtaining the character offset from a TextPos. Such a model may limit its content to in-memory and may also provide a property to encode the line ending policy, or even encode the line endings in the content. We could, in theory, provide such a model as a part of CodeArea package, something that I am still considering. -andy From: openjfx-dev on behalf of PavelTurk Date: Wednesday, May 28, 2025 at 03:10 To: openjfx-dev at openjdk.org Subject: Re: CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange) Andy, thank you for your reply. When making changes, I think we have THREE key parameters: 1. startByte ? this is the offset in the file where the change begins. If the document is very large, this value might require a long, although that would be one case in a billion. 2. removedLength ? the length of the removed chunk of text starting from startByte. I think this will always fit in an int, but it could be a long as well. At the same time String#length() -> int. 3. insertedLength ? the length of the inserted text starting at startByte. Again, I believe int should suffice, but long is also an option. Now, in JDK-8357405, only (2) and (3) are mentioned. So, the calculation of startByte is left for the future or for the user to handle. The reason for this is that the user can compute startByte themselves, but they cannot efficiently determine removedLength and insertedLength (at least I don?t know how). At the same time, I believe that during the change processing, the library itself can quite easily calculate these values and include them in the ContentChange. For example, when a portion of text is selected and replaced with something else, the library knows: a) the length of the selected text, and b) the length of the inserted text. If I?m wrong and the user can efficiently calculate removedLength and insertedLength using a custom model, could you explain how to do that? Because without this data, my work with JFX CodeArea is completely blocked. At the same time, wouldn?t it be better to support these values out of the box? Many code analysis libraries rely on them, and CodeArea is intended to be integrated with exactly those kinds of libraries. Best regards, Pavel On 5/27/25 20:51, Andy Goryachev wrote: Dear Pavel: This is not a trivial request. Currently, there is not easy way to control (override) the behavior of the CodeModel with respect to line endings. Line endings are not stored in the model, but they are emitted when saving/copying. Perhaps we ought to add a dedicated property to the model (line endings: CR/LF/CRLF/PLATFORM?) which would allow the application to specify the behavior and allow the model to perform the offset calculations. The other issue is that the CodeArea supports large models (CodeTextModel with a custom BasicTextModel.Content). Computing offsets in a large model not only may take a long time, but also produce result that does not fit into 31 bits. Which means, for all intents and purposes, this functionality should be implemented by a custom model. What do you think? Cheers, -andy From: openjfx-dev on behalf of PavelTurk Date: Thursday, May 22, 2025 at 05:29 To: openjfx-dev at openjdk.org Subject: CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange) I'd like to kindly ask for consideration in raising the priority of JDK-8357405 about adding text length metrics to ContentChange for removed/inserted text for CodeArea. The reason for this request is that accurate and reliable information about text changes is essential when integrating CodeArea with code processing libraries. Currently, CodeArea does not provide such information. As a result, CodeArea can only be reliably used in read-only mode at the moment ? which severely limits its applicability in real-world applications. Best regards, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jun 10 15:31:22 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 15:31:22 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/b22ed6d2..2dd7a35d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=05-06 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Tue Jun 10 15:31:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 15:31:23 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 20:22:28 GMT, Laurent Bourg?s wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Few mlnor comments. It looks good to me ! @bourgesl @andy-goryachev-oracle I pushed the fix. Please re-review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2959716194 From mmack at openjdk.org Tue Jun 10 15:52:52 2025 From: mmack at openjdk.org (Markus Mack) Date: Tue, 10 Jun 2025 15:52:52 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: <5TqZpZtMA3OvZgFxaBdaUAwKK_LjFILZqQ8HvUMrJDQ=.95910fba-459b-4c26-a34d-990c7f1132d4@github.com> On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null I tested and can also confirm that the issue occurs without the latest patch, and is resolved now. Additionally I checked my own title bar test app. When checking the controlsfx sampler app I do see CSS-related `ClassCastException`s in the "ComponentValidation" section, but they seem to be present with the current jfx master branch already. The code changes look reasonable. ------------- Marked as reviewed by mmack (Author). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2914182217 From kcr at openjdk.org Tue Jun 10 15:52:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 15:52:52 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null The changes look reasonable. I'll fire off a new headful test run just to be sure. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2959788858 From lbourges at openjdk.org Tue Jun 10 16:06:43 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 10 Jun 2025 16:06:43 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 15:31:22 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) Marked as reviewed by lbourges (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2914235227 From angorya at openjdk.org Tue Jun 10 16:09:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Jun 2025 16:09:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 15:31:22 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2914249613 From lbourges at openjdk.org Tue Jun 10 16:15:38 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 10 Jun 2025 16:15:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> Message-ID: On Mon, 9 Jun 2025 22:09:44 GMT, Kevin Rushforth wrote: > > > I'd looked at that but it was not obvious. And it definitely is not obvious that it will be the same thread that initialises the MaskMarlinAlphaConsumer.java class > > > > Yes, I see what you are saying. The `ALPHA_MASK_XXX` arrays are static fields of `MaskMarlinAlphaConsumer`, and the renderer context class has an instance field of `MaskMarlinAlphaConsumer`. So it does seem possible that `MaskMarlinAlphaConsumer` could be initialized by a thread other than the prism renderer thread. Hmmm. > > Fortunately, the presence of following field in RendererConext does not cause the MaskMarlinAlphaConsumer class to be initialized: > > ``` > public MaskMarlinAlphaConsumer consumer = null; > ``` > > I instrumented the code, adding something that _did_ force initialization and was able to provoke a WrongThreadException. Without my modification, MaskMarlinAlphaConsumer doesn't get initialized until rendering. > > This seems _very_ fragile, though. At best, presuming we can prove that initialization and access to MaskMarlinAlphaConsumer always happens on the Prism rendering thread, this is an accident waiting to happen. > > @bourgesl Do you have any thoughts on this? Using the shared arena is definitely safer, but there might be a performance penalty. These alpha masks are constant (static), so reused in marlin java2d where multiple threads & rendering contexts can work in parallel. With FFM, the global arena could be used, but the current patch is good enough as javafx uses only 1 thread to perform rendering. I hope using the shared arena does not hurt performance in this case (1 thread). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2959886137 From angorya at openjdk.org Tue Jun 10 16:54:48 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Jun 2025 16:54:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: <4xhv_bJtdcHzgkWopqaurj5SiedHjexIhld74H8dk9o=.37f30e06-8de6-4de1-982c-26e7b8670daf@github.com> On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null Looks good. Spent some time trying to set the new -FX-INTERNAL- CSS properties via scene stylesheet, failed as expected (win11). BTW, did not see any CSS errors in stderr. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2914364355 From kcr at openjdk.org Tue Jun 10 17:15:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 17:15:41 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v31] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Thu, 5 Jun 2025 21:31:59 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 42: >> >>> 40: *

  • >>> 41: * {@code minY} - the ascent of the line (negative). >>> 42: * The ascent of the line is the max ascent of all fonts in the line. >> >> Shouldn't that be "glyphs" not "fonts"? > > This definition is copied from `com.sun.javafx.scene.text.TextLine::getBounds` L58. > I'll let Phil confirm that, but since it's a max ascent, it might be a function of the font rather than the particular glyphs. I asked Phil offline and he confirmed that this should be "font" not "glyph", which makes sense, since what you want to know is how tall the line should be to accommodate any glyph that you might display with that font. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2138395298 From kcr at openjdk.org Tue Jun 10 17:15:42 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 17:15:42 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v31] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: <7qwGf1SGGwfsk0c38FTT4F_FCttyt04IXoD-bMH71Dk=.f0df18ea-8c2e-4850-8ff9-2dec08d8b1d4@github.com> On Thu, 5 Jun 2025 21:01:52 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: >> >> - cleanup >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - cleanup >> - removed getStrikeThroughShape >> - caret geometry >> - review comments >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - review comments >> - Merge remote-tracking branch 'origin/master' into ag.text.layout.api >> - ... and 51 more: https://git.openjdk.org/jfx/compare/9950d33c...de1016be > > modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 51: > >> 49: * {@code height} - the height of the line. >> 50: * The height of the line is sum of the max ascent, max descent, and >> 51: * max line gap of all the fonts in the line. > > Shouldn't that be "glyphs" not "fonts"? Nope. It's correct as is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2138396329 From mstrauss at openjdk.org Tue Jun 10 17:20:50 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Jun 2025 17:20:50 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: <4xhv_bJtdcHzgkWopqaurj5SiedHjexIhld74H8dk9o=.37f30e06-8de6-4de1-982c-26e7b8670daf@github.com> References: <4xhv_bJtdcHzgkWopqaurj5SiedHjexIhld74H8dk9o=.37f30e06-8de6-4de1-982c-26e7b8670daf@github.com> Message-ID: On Tue, 10 Jun 2025 16:51:35 GMT, Andy Goryachev wrote: > Looks good. > > Spent some time trying to set the new -FX-INTERNAL- CSS properties via scene stylesheet, failed as expected (win11). BTW, did not see any CSS errors in stderr. This "works" for me: scene.getStylesheets().add("data:base64," + Base64.getUrlEncoder().encodeToString(""" .-FX-INTERNAL-header-button-container { -fx-background-color: #ff000055; }""".getBytes(StandardCharsets.UTF_8))); It's still not API, and still not a proper use of this feature. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2960045694 From angorya at openjdk.org Tue Jun 10 17:33:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Jun 2025 17:33:50 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null > ```java > .-FX-INTERNAL-header-button-container > ``` yikes! I think I tried to modify this particular selector... So let me ask this question again. Since the application can change these styles, I feel they should be documented. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2960083179 From mstrauss at openjdk.org Tue Jun 10 17:40:49 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Jun 2025 17:40:49 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 17:30:44 GMT, Andy Goryachev wrote: > > ```java > > .-FX-INTERNAL-header-button-container > > ``` > > yikes! I think I tried to modify this particular selector... > > So let me ask this question again. Since the application can change these styles, I feel they should be documented. What do you think? What possible use could this have? It's an exposed implementation detail. We already have a proper way to customize header buttons, which works well if you need to do anything that the default header buttons don't give you (and this works on all platforms, as you'd expect). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2960104209 From kcr at openjdk.org Tue Jun 10 17:53:39 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 17:53:39 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> Message-ID: On Tue, 10 Jun 2025 16:13:10 GMT, Laurent Bourg?s wrote: > These alpha masks are constant (static), so reused in marlin java2d where multiple threads & rendering contexts can work in parallel. With FFM, the global arena could be used, but the current patch is good enough as javafx uses only 1 thread to perform rendering. I hope using the shared arena does not hurt performance in this case (1 thread). By deferring the creation to the first time a MaskMarlinAlphaConsumer object is constructed, I was able to continue using the confined arena, so there is no use of a shared arena in Marlin for JavaFX. I had also thought about the global arena, since the alpha objects are global (static) objects that are never released. That might be a better choice, and is probably what you will need to do anyway for Java2D. If there is no performance penalty for accessing data from a memory segment created using the global arena, then we could switch to that for JavaFX as well. @minborg Do you have any advice regarding this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2960144994 From kcr at openjdk.org Tue Jun 10 18:13:48 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 18:13:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null Headful tests passed. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2914629768 From kcr at openjdk.org Tue Jun 10 18:13:49 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 18:13:49 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 17:38:16 GMT, Michael Strau? wrote: > > > ```java > > > .-FX-INTERNAL-header-button-container > > > ``` > > > > > > yikes! I think I tried to modify this particular selector... > > So let me ask this question again. Since the application can change these styles, I feel they should be documented. What do you think? > > What possible use could this have? It's an exposed implementation detail. We already have a proper way to customize header buttons, which works well if you need to do anything that the default header buttons don't give you (and this works on all platforms, as you'd expect). I agree. This is intended to be internal and should not be documented. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2960192736 From kcr at openjdk.org Tue Jun 10 18:20:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 18:20:43 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v32] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: <-SxiwDk6Y9JwlA2S_Q70I5ooI8lrFnQ-mZYXi6ytzlM=.cf8b07ea-02e4-48d2-b4b9-09385fb3e12d@github.com> On Thu, 5 Jun 2025 21:42:46 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: > > - review comments > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - cleanup > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - cleanup > - removed getStrikeThroughShape > - caret geometry > - review comments > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - ... and 53 more: https://git.openjdk.org/jfx/compare/11f31146...d0f56fee I ran the tests included with this fix on my macOS 14 system and see 3 failures: $ gradle --continue --info -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests TextFlow_TextLayout_Test --tests Text_TextLayout_Test Text_TextLayout_Test > testSelection() FAILED org.opentest4j.AssertionFailedError: expected: <0.0> but was: <-23.203125> at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:86) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:81) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1014) at app//test.robot.javafx.scene.Text_TextLayout_Test.testSelection(Text_TextLayout_Test.java:205) Text_TextLayout_Test > testTextLines() FAILED org.opentest4j.AssertionFailedError: expected: <0.0> but was: <-23.203125> at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:86) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:81) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1014) at app//test.robot.javafx.scene.Text_TextLayout_Test.testTextLines(Text_TextLayout_Test.java:155) Text_TextLayout_Test > testCaretInfo() FAILED org.opentest4j.AssertionFailedError: expected: but was: at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:183) at app//test.robot.javafx.scene.Text_TextLayout_Test.testCaretInfo(Text_TextLayout_Test.java:87) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2960211988 From angorya at openjdk.org Tue Jun 10 18:40:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Jun 2025 18:40:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null I suppose -FX-INTERNAL- is clear enough for anyone who sees it in the ScenicView. Ship it! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2960255504 From angorya at openjdk.org Tue Jun 10 18:49:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Jun 2025 18:49:20 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v33] In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 25 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > > > ## WARNINGS > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/RichTextFX/pull/1246 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: text origin ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1596/files - new: https://git.openjdk.org/jfx/pull/1596/files/d0f56fee..39683560 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=32 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=31-32 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From angorya at openjdk.org Tue Jun 10 19:06:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Jun 2025 19:06:45 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v33] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: <7ePShmKONnZmwihwUzKiBbuiKLVLHxXsPDfLUnCPUeQ=.73e1e6f6-9967-48ad-b890-17782c6f0024@github.com> On Tue, 10 Jun 2025 18:49:20 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > text origin good catch! the failures not specific to macOS 14. modified the headful tests to use top text origin (all the other choices are handled by headless tests). launched an internal headful run: job 378 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2960316353 From pminborg at openjdk.org Wed Jun 11 05:42:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jun 2025 05:42:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> Message-ID: On Tue, 10 Jun 2025 17:51:02 GMT, Kevin Rushforth wrote: > If there is no performance penalty for accessing data from a memory segment created using the global arena, then we could switch to that for JavaFX as well. Using memory from the Global arena can actually be _faster_ as we do not have to perform any liveness checks for such segments. So, I think this is a good move. Also, the memory does not have to be acquired/released if the address is conveyed to native code (as the segment's scope never closes). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2961322752 From kcr at openjdk.org Wed Jun 11 13:22:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 13:22:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 15:31:22 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) I was going to file a follow-on issue for switching to the global arena for the alpha maps, but I now think it is better to do that now. The changes are simple. My initial testing shows that it works quite well. I'll make the change in this PR shortly, after some further testing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2962688219 From nlisker at openjdk.org Wed Jun 11 13:41:36 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 11 Jun 2025 13:41:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> Message-ID: On Wed, 11 Jun 2025 05:40:22 GMT, Per Minborg wrote: > > If there is no performance penalty for accessing data from a memory segment created using the global arena, then we could switch to that for JavaFX as well. > > Using memory from the Global arena can actually be _faster_ as we do not have to perform any liveness checks for such segments. So, I think this is a good move. Also, the memory does not have to be acquired/released if the address is conveyed to native code (as the segment's scope never closes). In this case, you'll need to change [`free()`](https://github.com/kevinrushforth/jfx/blob/2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55/modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java#L126) to remove the closure of the arena, but I think that then you'll have to manually clear the memory segments it allocates. This requires non-trivial modifications with `MarlinUtils`'s cleaner. When @bourgesl and I discussed these changes, we were unsure what the correct arena for this situation is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2962763793 From kcr at openjdk.org Wed Jun 11 14:18:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 14:18:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> Message-ID: <2nJjXPsIpHsAA92GzeXjyowU-98QWOv4phuAEIk41Zk=.624c888d-7e99-48be-bbbf-0081e35b92bd@github.com> On Wed, 11 Jun 2025 13:38:36 GMT, Nir Lisker wrote: > > > If there is no performance penalty for accessing data from a memory segment created using the global arena, then we could switch to that for JavaFX as well. > > > > > > Using memory from the Global arena can actually be _faster_ as we do not have to perform any liveness checks for such segments. So, I think this is a good move. Also, the memory does not have to be acquired/released if the address is conveyed to native code (as the segment's scope never closes). > > In this case, you'll need to change [`free()`](https://github.com/kevinrushforth/jfx/blob/2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55/modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java#L126) to remove the closure of the arena, but I think that then you'll have to manually clear the memory segments it allocates. This requires non-trivial modifications with `MarlinUtils`'s cleaner. When @bourgesl and I discussed these changes, we were unsure what the correct arena for this situation is. The alpha map objects are never freed. They are static arrays that are created and filled once, in the static initializer of the `MaskMarlinAlphaConsumer` class. The change I am thinking to propose is [here](https://github.com/kevinrushforth/jfx/commit/6c38c6040d1abd9b84f3648f892215573a8b1275) if you want to take a look before I push it to this PR branch. I could still integrate this PR "as is" and file a follow-on for using the global arena for the alpha map arrays depending on what @nlisker and @bourgesl think. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2963018875 From angorya at openjdk.org Wed Jun 11 14:27:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 14:27:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 15:31:22 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 111: > 109: byte[] _ALPHA_MAP = buildAlphaMap(MarlinConst.MAX_AA_ALPHA); > 110: ALPHA_MAP = _ALPHA_MAP; // Keep alive the OffHeapArray > 111: ALPHA_MAP_OFF_HEAP = new OffHeapArray(ALPHA_MAP, ALPHA_MAP.length); // 1K L110: is `ALPHA_MAP` needed to keep the `parent` reference? if so, why not use a single `Object` instead of an array? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140345005 From nlisker at openjdk.org Wed Jun 11 14:36:39 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 11 Jun 2025 14:36:39 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: <2nJjXPsIpHsAA92GzeXjyowU-98QWOv4phuAEIk41Zk=.624c888d-7e99-48be-bbbf-0081e35b92bd@github.com> References: <3T_DgTmQSu2gJAU2IkxHZ7yaBRuaJXt3ybHhinON8n8=.6632e80c-a059-4d3b-95f0-50c24788167e@github.com> <53Zx7uetNETjhnIPMvim8ulG49_TFCny4z44AYcjoSY=.3e381946-9c8d-4d16-8bb6-9faf5e3ac186@github.com> <2nJjXPsIpHsAA92GzeXjyowU-98QWOv4phuAEIk41Zk=.624c888d-7e99-48be-bbbf-0081e35b92bd@github.com> Message-ID: On Wed, 11 Jun 2025 14:16:19 GMT, Kevin Rushforth wrote: > > > > If there is no performance penalty for accessing data from a memory segment created using the global arena, then we could switch to that for JavaFX as well. > > > > > > > > > Using memory from the Global arena can actually be _faster_ as we do not have to perform any liveness checks for such segments. So, I think this is a good move. Also, the memory does not have to be acquired/released if the address is conveyed to native code (as the segment's scope never closes). > > > > > > In this case, you'll need to change [`free()`](https://github.com/kevinrushforth/jfx/blob/2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55/modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java#L126) to remove the closure of the arena, but I think that then you'll have to manually clear the memory segments it allocates. This requires non-trivial modifications with `MarlinUtils`'s cleaner. When @bourgesl and I discussed these changes, we were unsure what the correct arena for this situation is. > > The alpha map objects are never freed. They are static arrays that are created and filled once, in the static initializer of the `MaskMarlinAlphaConsumer` class. The change I am thinking to propose is [here](https://github.com/kevinrushforth/jfx/commit/6c38c6040d1abd9b84f3648f892215573a8b1275) if you want to take a look before I push it to this PR branch. > > I could still integrate this PR "as is" and file a follow-on for using the global arena for the alpha map arrays depending on what @nlisker and @bourgesl think. Ah, you're using **2** arenas for the different allocations. That's something I didn't think of and seems like a decent solution. I'm fine with any solution that keeps the rendering correct (obviously) and addresses the concerns of memory deallocation, which as I said, can be tricky to do. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2963086118 From kcr at openjdk.org Wed Jun 11 15:20:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 15:20:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 14:24:50 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) > > modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 111: > >> 109: byte[] _ALPHA_MAP = buildAlphaMap(MarlinConst.MAX_AA_ALPHA); >> 110: ALPHA_MAP = _ALPHA_MAP; // Keep alive the OffHeapArray >> 111: ALPHA_MAP_OFF_HEAP = new OffHeapArray(ALPHA_MAP, ALPHA_MAP.length); // 1K > > L110: is `ALPHA_MAP` needed to keep the `parent` reference in `OffHeapArray`? if so, why not use a single `Object` instead of an array? It's actually unused (in practice), but I didn't want to change the logic any more than I had to. It doesn't matter enough to care about, so I didn't want to think about whether the reference could be eliminated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140469377 From kcr at openjdk.org Wed Jun 11 16:54:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 16:54:21 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: - Use the global arena for the ALPHA_MASK arrays. - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/2dd7a35d..6c38c604 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=06-07 Stats: 57 lines in 2 files changed: 43 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Wed Jun 11 16:54:22 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 16:54:22 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 15:31:22 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer) I think I'll proceed with this solution, using a global arena for the static alpha maps (never freed), and the confined arena for everything else. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2963526674 From lbourges at openjdk.org Wed Jun 11 17:04:48 2025 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 11 Jun 2025 17:04:48 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. Marked as reviewed by lbourges (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2918029936 From nlisker at openjdk.org Wed Jun 11 17:26:38 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 11 Jun 2025 17:26:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 165: > 163: > 164: void free() { > 165: if (global) { Trying to close the global arena results in an UnsupportedOperationException according to the docs. Not sure doing this manually adds anything. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140717599 From prr at openjdk.org Wed Jun 11 17:35:37 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Jun 2025 17:35:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2918130732 From prr at openjdk.org Wed Jun 11 17:35:38 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Jun 2025 17:35:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:23:56 GMT, Nir Lisker wrote: >> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the global arena for the ALPHA_MASK arrays. >> - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" >> >> This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 165: > >> 163: >> 164: void free() { >> 165: if (global) { > > Trying to close the global arena results in an UnsupportedOperationException according to the docs. Not sure doing this manually adds anything. true ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140731769 From angorya at openjdk.org Wed Jun 11 17:39:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 17:39:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. Marked as reviewed by angorya (Reviewer). modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 59: > 57: */ > 58: OffHeapArray(final Object parent, final long len) { > 59: this(parent, len, false); I would suggest to remove this constructor. ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2918125459 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140728593 From kcr at openjdk.org Wed Jun 11 17:39:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 17:39:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:32:51 GMT, Phil Race wrote: >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 165: >> >>> 163: >>> 164: void free() { >>> 165: if (global) { >> >> Trying to close the global arena results in an UnsupportedOperationException according to the docs. Not sure doing this manually adds anything. > > true Right. I could remove it if you like, although it isn't hurting anything leaving it there. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140738538 From kcr at openjdk.org Wed Jun 11 17:47:42 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 17:47:42 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:30:48 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the global arena for the ALPHA_MASK arrays. >> - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" >> >> This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 59: > >> 57: */ >> 58: OffHeapArray(final Object parent, final long len) { >> 59: this(parent, len, false); > > I would suggest to remove this constructor. Since global is the special case, it seemed easier to keep the existing constructor and only pass "global=true" in the one place that's needed -- the static initializer of `MaskMarlinAlphaConsumer`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140748003 From kcr at openjdk.org Wed Jun 11 17:47:42 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 17:47:42 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:43:10 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 59: >> >>> 57: */ >>> 58: OffHeapArray(final Object parent, final long len) { >>> 59: this(parent, len, false); >> >> I would suggest to remove this constructor. > > Since global is the special case, it seemed easier to keep the existing constructor and only pass "global=true" in the one place that's needed -- the static initializer of `MaskMarlinAlphaConsumer`. Although... there is only one use now of the default constructor, so it would be trivial to change it and dispense with the first constructor. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140750760 From angorya at openjdk.org Wed Jun 11 17:54:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 17:54:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:44:54 GMT, Kevin Rushforth wrote: >> Since global is the special case, it seemed easier to keep the existing constructor and only pass "global=true" in the one place that's needed -- the static initializer of `MaskMarlinAlphaConsumer`. > > Although... there is only one use now of the default constructor, so it would be trivial to change it and dispense with the first constructor. it's a minor thing; we could do it later if you plan a follow-up - I more dislike the idea of having an unused array... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140762139 From angorya at openjdk.org Wed Jun 11 18:20:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 18:20:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. My (limited) testing on macOS 15.5 M1 shows no ill effects. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2963760961 From kcr at openjdk.org Wed Jun 11 18:39:47 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 18:39:47 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v33] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Tue, 10 Jun 2025 18:49:20 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > text origin The fix looks good. The tests look good, although I noted a few "assertEquals" in the test with expected and actual parameters reserved (meaning the error message would be confusing if they ever failed). tests/system/src/test/java/test/robot/javafx/scene/TextFlow_TextLayout_Test.java line 81: > 79: > 80: // caret is one line > 81: assertEquals(ci.getSegmentCount(), 1); Expected and actual are reversed, here and a few others below (most are OK). tests/system/src/test/java/test/robot/javafx/scene/TextFlow_TextLayout_Test.java line 136: > 134: assertEquals(la.getTextLineCount(), 3); > 135: List ls = la.getTextLines(false); > 136: assertNotNull(ls); Minor: maybe check the following, too? assertEquals(3, ls.size()); tests/system/src/test/java/test/robot/javafx/scene/Text_TextLayout_Test.java line 83: > 81: > 82: // caret is one line > 83: assertEquals(ci.getSegmentCount(), 1); Expected and actual are reversed, here and a few others below (most are OK). ------------- PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2918282270 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2140820285 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2140823296 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2140830505 From kcr at openjdk.org Wed Jun 11 18:42:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 18:42:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. I ran a full CI test build after the latest changes to use the global arena for the alpha maps. No unexpected failures. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2963815450 From kcr at openjdk.org Wed Jun 11 18:42:39 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 18:42:39 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:52:18 GMT, Andy Goryachev wrote: >> Although... there is only one use now of the default constructor, so it would be trivial to change it and dispense with the first constructor. > > it's a minor thing; we could do it later if you plan a follow-up - I more dislike the idea of having an unused array... I'll file a few cleanup bugs before I integrate and note them in comments. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140840593 From nlisker at openjdk.org Wed Jun 11 18:42:39 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 11 Jun 2025 18:42:39 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:54:21 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: > > - Use the global arena for the ALPHA_MASK arrays. > - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" > > This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 83: > 81: } else { > 82: arena = Arena.ofConfined(); > 83: } If you prefer, this can be a ternary `arena = global ? ...`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140750854 From nlisker at openjdk.org Wed Jun 11 18:42:40 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 11 Jun 2025 18:42:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:37:04 GMT, Kevin Rushforth wrote: >> true > > Right. I could remove it if you like, although it isn't hurting anything leaving it there. It doesn't really matter, but personally I try to use the built in functionality. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140832007 From angorya at openjdk.org Wed Jun 11 19:17:24 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 19:17:24 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v34] In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 25 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > > > ## WARNINGS > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/RichTextFX/pull/1246 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1596/files - new: https://git.openjdk.org/jfx/pull/1596/files/39683560..7e32bdbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=33 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=32-33 Stats: 16 lines in 2 files changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From angorya at openjdk.org Wed Jun 11 19:17:26 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 19:17:26 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v33] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Wed, 11 Jun 2025 18:26:56 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> text origin > > tests/system/src/test/java/test/robot/javafx/scene/TextFlow_TextLayout_Test.java line 81: > >> 79: >> 80: // caret is one line >> 81: assertEquals(ci.getSegmentCount(), 1); > > Expected and actual are reversed, here and a few others below (most are OK). in the other test as well... good catch! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2140895379 From kcr at openjdk.org Wed Jun 11 19:47:55 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 19:47:55 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v9] In-Reply-To: References: Message-ID: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Cleanup for review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1814/files - new: https://git.openjdk.org/jfx/pull/1814/files/6c38c604..dfde5518 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1814&range=07-08 Stats: 24 lines in 2 files changed: 1 ins; 19 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1814.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1814/head:pull/1814 PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Wed Jun 11 19:47:55 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 19:47:55 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: <19UFAmCggCUFPOuKkXbIeItZCN-ah_sKBYiTpCEnpyU=.88edb7fb-1bb7-4c72-965d-a47ae874cc40@github.com> On Wed, 11 Jun 2025 18:39:25 GMT, Kevin Rushforth wrote: >> it's a minor thing; we could do it later if you plan a follow-up - I more dislike the idea of having an unused array... > > I'll file a few cleanup bugs before I integrate and note them in comments. I decided to fix the constructor now (simple cleanup without any behavior change). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140935874 From angorya at openjdk.org Wed Jun 11 19:47:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 19:47:55 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v9] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:45:19 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup for review comments Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2918470620 From kcr at openjdk.org Wed Jun 11 19:47:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 19:47:56 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:40:09 GMT, Kevin Rushforth wrote: >> It doesn't really matter, but personally I try to use the built in functionality. > > ~~I decided to fix the constructor now (simple cleanup without any behavior change).~~ I removed the explicit check. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140935641 From kcr at openjdk.org Wed Jun 11 19:47:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 19:47:56 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:44:58 GMT, Nir Lisker wrote: >> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the global arena for the ALPHA_MASK arrays. >> - Revert "Initialize alpha maps in constructor to ensure they are created on the right thread (QuantumRenderer)" >> >> This reverts commit 2dd7a35d2eec16b04de1f4cb7aeba31be5d98a55. > > modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 83: > >> 81: } else { >> 82: arena = Arena.ofConfined(); >> 83: } > > If you prefer, this can be a ternary `arena = global ? ...`. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140932641 From kcr at openjdk.org Wed Jun 11 19:47:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 19:47:56 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 18:33:57 GMT, Nir Lisker wrote: >> Right. I could remove it if you like, although it isn't hurting anything leaving it there. > > It doesn't really matter, but personally I try to use the built in functionality. ~~I decided to fix the constructor now (simple cleanup without any behavior change).~~ ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140932240 From kcr at openjdk.org Wed Jun 11 20:14:39 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 20:14:39 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v7] In-Reply-To: References: Message-ID: <8S6qkL3YIAfjQWRrmJs5BEsxFpGPB4rQypAVcPMQuyM=.147169f2-95e8-4834-ac5c-4cd129d26f65@github.com> On Wed, 11 Jun 2025 15:17:59 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 111: >> >>> 109: byte[] _ALPHA_MAP = buildAlphaMap(MarlinConst.MAX_AA_ALPHA); >>> 110: ALPHA_MAP = _ALPHA_MAP; // Keep alive the OffHeapArray >>> 111: ALPHA_MAP_OFF_HEAP = new OffHeapArray(ALPHA_MAP, ALPHA_MAP.length); // 1K >> >> L110: is `ALPHA_MAP` needed to keep the `parent` reference in `OffHeapArray`? if so, why not use a single `Object` instead of an array? > > It's actually unused (in practice), but I didn't want to change the logic any more than I had to. It doesn't matter enough to care about, so I didn't want to think about whether the reference could be eliminated. [JDK-8359260](https://bugs.openjdk.org/browse/JDK-8359260) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140976467 From kcr at openjdk.org Wed Jun 11 20:14:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 20:14:40 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v5] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 15:34:31 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 79: >> >>> 77: * @return number of used bytes >>> 78: */ >>> 79: int getUsed() { >> >> wait, length is `long`, but used is `int`? > > I noticed this too. This is preexisting, so I don't want to change it as part of this PR (to minimize changes). It might or might not be worth a follow-up. [JDK-8359259](https://bugs.openjdk.org/browse/JDK-8359259) >> modules/javafx.graphics/src/main/java/com/sun/marlin/OffHeapArray.java line 97: >> >>> 95: */ >>> 96: void incrementUsed(int increment) { >>> 97: this.used += increment; >> >> if used > 2B, it will overflow, right? > > Yes. It seems worth checking and throw an exception. Other invariants could also be enforced such as used <= length. > > I'll file a follow-up issue for this, since this behavior is preexisting. [JDK-8359259](https://bugs.openjdk.org/browse/JDK-8359259) >> modules/javafx.graphics/src/main/java/com/sun/marlin/RendererNoAA.java line 379: >> >>> 377: // note: throw IOOB if neededSize > 2Gb: >>> 378: final long edgeNewSize = ArrayCacheConst.getNewLargeSize( >>> 379: _edges.getLength(), >> >> L377 is unclear - is this a TODO to throw IOOBE or a description of what would happen? >> (this is a separate issue from FFM changes, really) > > Yes, this is preexisting and not something to look at as part of this PR. [JDK-8359259](https://bugs.openjdk.org/browse/JDK-8359259) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140969093 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140969190 PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140968533 From kcr at openjdk.org Wed Jun 11 20:14:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 20:14:38 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v6] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 19:42:07 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/marlin/MaskMarlinAlphaConsumer.java line 110: >> >>> 108: >>> 109: for (int i = 0; i < _ALPHA_MAP.length; i++) { >>> 110: ALPHA_MAP_OFF_HEAP.putByte(i, _ALPHA_MAP[i]); >> >> I guess this is only done once, but following multiple layers of calculation I think this array defaults to 64K long, in which case a bulk copy would be better, but it is perhaps out-of-scope for a 1:1 replacement >> >> https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemorySegment.html#copy(java.lang.Object,int,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,int) > > Thanks. This seems like a good follow-up RFE. I'll file it. [JDK-8359260](https://bugs.openjdk.org/browse/JDK-8359260) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1814#discussion_r2140973406 From prr at openjdk.org Wed Jun 11 20:20:36 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Jun 2025 20:20:36 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v9] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:47:55 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup for review comments Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1814#pullrequestreview-2918548552 From kcr at openjdk.org Wed Jun 11 20:20:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 20:20:37 GMT Subject: RFR: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM [v9] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:47:55 GMT, Kevin Rushforth wrote: >> PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. >> >> I broke this up into the following commits. The bulk of the work is in the first two: >> >> 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. >> 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it >> 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. >> 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. >> 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ >> >> Additional commits address review comments. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup for review comments I filed the following two cleanup issues: [JDK-8359259](https://bugs.openjdk.org/browse/JDK-8359259): Missing range checks in Marlin for JavaFX [JDK-8359260](https://bugs.openjdk.org/browse/JDK-8359260): Optimizations for Marlin FFM in JavaFX Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2964032791 PR Comment: https://git.openjdk.org/jfx/pull/1814#issuecomment-2964035998 From kcr at openjdk.org Wed Jun 11 20:20:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 20:20:37 GMT Subject: Integrated: 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM In-Reply-To: References: Message-ID: <7xVjto0aeXVEHQ32j6CLyWiq26V5DkEOsZQvj36Di-w=.bae619b1-1ad9-46b6-b916-a9b5bb02e21e@github.com> On Wed, 21 May 2025 13:24:32 GMT, Kevin Rushforth wrote: > PR to replace the use of sun.misc.Unsafe memory access methods in the Marlin rasterizer with FFM. > > I broke this up into the following commits. The bulk of the work is in the first two: > > 1. Encapsulate all off-heap access in OffHeapArray -- All of the memory allocation and management was already done in the OffHeapArray class, but the users of OffHeapArray, primarily Renderer and RendererNoAA, called Unsafe methods directly. I encapsulated all of the calls to Unsafe in OffHeapArray. The main impact on calling code is that the base address is no longer accessible or needed. Instead, the `(put|get)(Byte|Int)` methods take only an offset. This commit was straight refactoring with no behavioral changes. > 2. Initial FFM implementation -- I changed the memory management and access methods to use FFM. Each OffHeap array uses a shared Arena to manage the single memory segment allocated at construction time. The resize method creates a new Arena and memory segment, copying the data from the old and then closing it > 3. Set `used` to 0 in `dispose()` -- While testing and instrumenting the code, I discovered that the Renderer dispose methods resize the edges array back to the default size without clearing the "used" field. The used field will be cleared before the next time it is accessed, but clearing it in dispose allows optimizing resize to not copy any data. > 4. Remove '--sun-misc-unsafe-memory-access=allow' from test and app execution, since it is no longer needed. This also enables `-Werror` for the `javafx.graphics` module. > 5. ~~Temporary debug prints that will be removed before making this "rfr"~~ > > Additional commits address review comments. This pull request has now been integrated. Changeset: 72c1c21a Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/72c1c21a76ba752439c877aba599b0b5f8bf9332 Stats: 332 lines in 13 files changed: 95 ins; 100 del; 137 mod 8334137: Marlin: replace sun.misc.Unsafe memory access methods with FFM Reviewed-by: angorya, prr, lbourges ------------- PR: https://git.openjdk.org/jfx/pull/1814 From kcr at openjdk.org Wed Jun 11 20:26:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 20:26:41 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v34] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Wed, 11 Jun 2025 19:17:24 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2918569516 From mstrauss at openjdk.org Wed Jun 11 20:40:39 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Jun 2025 20:40:39 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v34] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Wed, 11 Jun 2025 19:17:24 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by mstrauss (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2918602880 From kizune at openjdk.org Wed Jun 11 21:18:13 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 11 Jun 2025 21:18:13 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component Message-ID: Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. ------------- Commit messages: - 8359257: Create accessibility protocol for TabGroup component Changes: https://git.openjdk.org/jfx/pull/1823/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1823&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359257 Stats: 113 lines in 3 files changed: 111 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1823.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1823/head:pull/1823 PR: https://git.openjdk.org/jfx/pull/1823 From kizune at openjdk.org Wed Jun 11 21:18:13 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 11 Jun 2025 21:18:13 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 21:13:12 GMT, Alexander Zuev wrote: > Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. In order to validate the fix one can use Ensemble8 demo app and go trough the Pagination and TabPane controls, then check that with VoiceOver on the currently selected page or tab is correctly announced. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2964311220 From kcr at openjdk.org Wed Jun 11 21:51:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Jun 2025 21:51:31 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 21:13:12 GMT, Alexander Zuev wrote: > Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. Reviewers: @arapte @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2964380880 From angorya at openjdk.org Wed Jun 11 21:54:34 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Jun 2025 21:54:34 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 21:13:12 GMT, Alexander Zuev wrote: > Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXTabGroupAccessibility.m line 57: > 55: if (env == NULL) return NULL; > 56: jresult = (jobject)(*env)->CallLongMethod(env, [self getJAccessible], > 57: jAccessibilityAttributeValue, (jlong)@"AXTabs"); minor: the indentation is off ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1823#discussion_r2141173169 From arapte at openjdk.org Thu Jun 12 09:48:10 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 12 Jun 2025 09:48:10 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline Message-ID: ### Description This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS. We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated. Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing `-Dprism.order=mtl`) The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use. ### Details about the changes **Shader changes** - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl) - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl **Build changes** - There are new tasks added to build.gradle for - Generation/ Compilation/ linking of Metal shaders - Compilation of Prism Java and Objective C files **Prism** - Prism is the rendering engine of JavaFX. - Added Metal specific Java classes and respective native implementation which use Metal APIs - Java side changes: - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. - Native side changes: - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl **Glass** - Glass is the windowing toolkit of JavaFX - Existing Glass classes are refactored to support both OpenGL and Metal pipelines - Added Metal specific Glass implementation. ### Testing - Testing performed on different hardware and macOS versions. - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4) - macOS versions - macOS 13, macOS 14 and macOS 15 - Functional Testing: - All headful tests pass with Metal pipeline. - Verified samples applications: Ensemble and toys - Performance Testing: - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed) ### Note to reviewers : - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline - It would be a good idea to test both OpenGL and Metal pipelines - Known issues and tasks can be found here: https://bugs.openjdk.org/issues/?filter=46763 ------------- Commit messages: - implement metal rendering pipeline Changes: https://git.openjdk.org/jfx/pull/1824/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271024 Stats: 12075 lines in 100 files changed: 11373 ins; 504 del; 198 mod Patch: https://git.openjdk.org/jfx/pull/1824.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824 PR: https://git.openjdk.org/jfx/pull/1824 From duke at openjdk.org Thu Jun 12 11:01:52 2025 From: duke at openjdk.org (Sergei) Date: Thu, 12 Jun 2025 11:01:52 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: <4gOs15pXZfRsenY_9x91MyKmQJwl0CtFljZFx2rDm-Y=.c1649564-11e3-4acc-8704-3bfa40f79244@github.com> On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null On Windows, when switching to fullscreen mode, the application crashes with an endless repetition of the error. Example: @Override public void start(Stage stage) { var headerBar = new HeaderBar(); var root = new BorderPane(); root.setTop(headerBar); Button btnFullScreen = new Button("FullScreen"); btnFullScreen.setOnAction((_) -> stage.setFullScreen(!stage.isFullScreen())); root.setCenter(btnFullScreen); stage.setScene(new Scene(root, 640, 480)); stage.initStyle(StageStyle.EXTENDED); stage.show(); } When you press a button in the console, the error repeats endlessly: Exception in thread "JavaFX Application Thread" java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.base/java.util.Objects.checkIndex(Objects.java:365) at java.base/java.util.ArrayList.get(ArrayList.java:428) at javafx.base at 25-internal/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88) at javafx.base at 25-internal/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326) at javafx.graphics at 25-internal/javafx.scene.Parent.updateCachedBounds(Parent.java:1772) at javafx.graphics at 25-internal/javafx.scene.Parent.recomputeBounds(Parent.java:1716) at javafx.graphics at 25-internal/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1569) at javafx.graphics at 25-internal/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116) at javafx.graphics at 25-internal/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84) at javafx.graphics at 25-internal/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78) at javafx.graphics at 25-internal/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62) at javafx.graphics at 25-internal/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3347) at javafx.graphics at 25-internal/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166) at javafx.graphics at 25-internal/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89) at javafx.graphics at 25-internal/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:103) at javafx.graphics at 25-internal/javafx.scene.Node.updateGeomBounds(Node.java:3923) at javafx.graphics at 25-internal/javafx.scene.Node.getGeomBounds(Node.java:3885) at javafx.graphics at 25-internal/javafx.scene.Node.getLocalBounds(Node.java:3833) at javafx.graphics at 25-internal/javafx.scene.Node.updateTxBounds(Node.java:3987) at javafx.graphics at 25-internal/javafx.scene.Node.getTransformedBounds(Node.java:3779) at javafx.graphics at 25-internal/javafx.scene.Node.updateBounds(Node.java:843) at javafx.graphics at 25-internal/javafx.scene.Parent.updateBounds(Parent.java:1903) at javafx.graphics at 25-internal/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2688) at javafx.graphics at 25-internal/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380) at javafx.graphics at 25-internal/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401) at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$0(QuantumToolkit.java:346) at javafx.graphics at 25-internal/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at javafx.graphics at 25-internal/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics at 25-internal/com.sun.glass.ui.win.WinApplication.lambda$runLoop$0(WinApplication.java:168) at java.base/java.lang.Thread.run(Thread.java:1447) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2966145323 From mfox at openjdk.org Thu Jun 12 13:12:36 2025 From: mfox at openjdk.org (Martin Fox) Date: Thu, 12 Jun 2025 13:12:36 GMT Subject: RFR: 8351867: No UI changes while iconified In-Reply-To: References: Message-ID: <2af021U_BifHUGvn3OGfbqhv8hBxkiTVVfg8yJyEFJE=.5598c2f1-a7ac-4735-a2da-65eb55383b1e@github.com> On Tue, 10 Jun 2025 08:27:53 GMT, Lukasz Kostyra wrote: > I'm trying to figure out how to exactly proceed with this. It would be nice to add this change and to also have the test in the repository, but it does fail for some cases like you mentioned (and I also verified that on my Windows machine). Would those cases be fixable? Sorry, my earlier comment was a bit terse. This is all fixable. When the stage is de-iconified we need to call `updateSceneState` to fix up the state and then `entireSceneNeedsRepaint` to repaint on the next pulse. Currently for the second step we're relying on Glass to call `notifyPaint` but that never happens on Mac and also doesn't happen for TRANSPARENT stages on Windows (I haven't tested Linux). Rather than expecting every Glass implementation to get this right for every stage style we should call `entireSceneNeedsRepaint` in the core code. That should fix all cases including TRANSPARENT stages on Windows. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2966654527 From kevin.rushforth at oracle.com Thu Jun 12 13:34:17 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Jun 2025 06:34:17 -0700 Subject: Result: New OpenJFX Committer: Alexander Zuev Message-ID: Voting for Alexander Zuev [1] to OpenJFX Committer [2] is now closed. Yes: 12 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.org/census#kizune [2] https://mail.openjdk.org/pipermail/openjfx-dev/2025-May/054530.html From angorya at openjdk.org Thu Jun 12 16:08:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 16:08:55 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: <4gOs15pXZfRsenY_9x91MyKmQJwl0CtFljZFx2rDm-Y=.c1649564-11e3-4acc-8704-3bfa40f79244@github.com> References: <4gOs15pXZfRsenY_9x91MyKmQJwl0CtFljZFx2rDm-Y=.c1649564-11e3-4acc-8704-3bfa40f79244@github.com> Message-ID: On Thu, 12 Jun 2025 10:57:54 GMT, Sergei wrote: > On Windows, when switching to fullscreen mode, the application crashes with an endless repetition of the error. Same issue on macOS 15.5 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967427450 From angorya at openjdk.org Thu Jun 12 16:20:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 16:20:54 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null Somewhat related question: when the Stage is not resizable, why is it being resized when going full screen? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967461070 From kcr at openjdk.org Thu Jun 12 16:37:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 16:37:52 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 16:17:56 GMT, Andy Goryachev wrote: > Somewhat related question: when the Stage is not resizable, why is it being resized when going full screen? Not really related. Short answer: fullScreen overrides resizable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967512984 From mstrauss at openjdk.org Thu Jun 12 16:50:49 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Jun 2025 16:50:49 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:51:34 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > only dispose ViewSceneOverlay when non-null Not resizable really means "has no resize border", and not "has a fixed size". A non-resizable window can also be programmatically resized with `setWidth` / `setHeight`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967548987 From angorya at openjdk.org Thu Jun 12 16:50:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 16:50:49 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 16:35:03 GMT, Kevin Rushforth wrote: > fullScreen overrides resizable I can't find where it is documented. Perhaps it should be added to both `resizableProperty` and `fullScreenProperty` ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967552123 From tsayao at openjdk.org Thu Jun 12 17:31:51 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 12 Jun 2025 17:31:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 16:35:03 GMT, Kevin Rushforth wrote: > > Somewhat related question: when the Stage is not resizable, why is it being resized when going full screen? > > Not really related. Short answer: fullScreen overrides resizable. On mac the fullscreen button is removed when it's not resizable. https://github.com/user-attachments/assets/d6650055-740a-4aa6-9d6c-0bf95152eb39 On Linux/Gnome (Ubuntu 24.04) it removes the maximized button when it's no resizable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967663601 From kizune at openjdk.org Thu Jun 12 18:36:31 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 18:36:31 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v2] In-Reply-To: References: Message-ID: > Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixing indentation. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1823/files - new: https://git.openjdk.org/jfx/pull/1823/files/2730768f..1d0bda30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1823&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1823&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1823.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1823/head:pull/1823 PR: https://git.openjdk.org/jfx/pull/1823 From kizune at openjdk.org Thu Jun 12 18:36:32 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 18:36:32 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 21:51:46 GMT, Andy Goryachev wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing indentation. > > modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXTabGroupAccessibility.m line 57: > >> 55: if (env == NULL) return NULL; >> 56: jresult = (jobject)(*env)->CallLongMethod(env, [self getJAccessible], >> 57: jAccessibilityAttributeValue, (jlong)@"AXTabs"); > > minor: the indentation is off Fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1823#discussion_r2143386406 From angorya at openjdk.org Thu Jun 12 19:22:33 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 19:22:33 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v2] In-Reply-To: References: Message-ID: <8mhs0vwP9k8zqHXZo342az7V4Q0kW0DXvYuKgW7UlQc=.17c195b8-3452-4fb7-a887-9c9298f34715@github.com> On Thu, 12 Jun 2025 18:36:31 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixing indentation. I see little difference between master and this PR: Pagination: - adds the word "group" when clicking on the radio button (e.g.: "You are currently on a selected radio button, **group**, 6 of 10) TabPane: - no difference in announcements What am I doing wrong? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2967901083 From angorya at openjdk.org Thu Jun 12 19:26:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 19:26:38 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 18:36:31 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixing indentation. Also noticed to pre-existing issues (in master): - resizing the control does not update the accessibility focus rectangle - flipping through tabs in TabPane using left/right arrow keys sometimes places the accessibility focus rectangle in a wrong location. Since I cannot take a screenshot with the accessibility focus rectangle, here is the artistic depiction: ![Screenshot 2025-06-12 at 12 05 05](https://github.com/user-attachments/assets/e3e70916-b9cd-472a-b387-aeb5ca3e65c2) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2967907959 From mstrauss at openjdk.org Thu Jun 12 19:39:30 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Jun 2025 19:39:30 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: References: Message-ID: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits: - Fix full-screen bug - Merge branch 'master' into feature/extended-window - only dispose ViewSceneOverlay when non-null - Rename default window button style classes - Set the scene root as the parent of the overlay node - rename WindowManager to DesktopEnvironment - enable preview feature system properties for tests - javadoc fix - fix memory leak in ViewScene - Merge branch 'master' into feature/extended-window - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=83 Stats: 6844 lines in 78 files changed: 6154 ins; 524 del; 166 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Thu Jun 12 19:44:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Jun 2025 19:44:47 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: <4gOs15pXZfRsenY_9x91MyKmQJwl0CtFljZFx2rDm-Y=.c1649564-11e3-4acc-8704-3bfa40f79244@github.com> Message-ID: <3PHxl2ZAB_Z304RP4f7iu-E4Cy5SKMJ-aJT00WyNKlY=.18c957eb-a515-4816-a96a-50129a4b826f@github.com> On Thu, 12 Jun 2025 16:05:56 GMT, Andy Goryachev wrote: > > On Windows, when switching to fullscreen mode, the application crashes with an endless repetition of the error. > > Same issue on macOS 15.5 > > Can be reproduced with the Stage Tester + simple HeaderBar. Perhaps it was introduced by a recent change? Yes, it was introduced by the previous patch. In order for CSS to work as expected, all nodes must be traceable to a single root node. This means that the parent of the overlay node is the scene root. However, in some cases during bounds calculation, the method `Parent.childBoundsChanged(Node)` is invoked on the root node by the overlay node. `Parent` assumes that if a child calls this method and passes itself as an argument, that the supposed child must also be contained in its own children list. In the case of the overlay node, this it not the case. The fix for this bug is to check whether the supposed child is actually contained in the root's children list, before continuing with the code path which assumes that it is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2967977276 From angorya at openjdk.org Thu Jun 12 20:09:52 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 20:09:52 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> References: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> Message-ID: On Thu, 12 Jun 2025 19:39:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits: > > - Fix full-screen bug > - Merge branch 'master' into feature/extended-window > - only dispose ViewSceneOverlay when non-null > - Rename default window button style classes > - Set the scene root as the parent of the overlay node > - rename WindowManager to DesktopEnvironment > - enable preview feature system properties for tests > - javadoc fix > - fix memory leak in ViewScene > - Merge branch 'master' into feature/extended-window > - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f On macOS 15.5 M1: modality=NONE, EXTENDED, header=split/custom buttos, resizable=off Clicking on Maximize button does not maximize the Stage but places it at the lower left corner. Same for DECORATED. edit: pre-existing, same as master. Not sure if this behavior is correct though. Why full screen resizes but maximized not? And if not resizing, why move? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2968026190 From angorya at openjdk.org Thu Jun 12 20:29:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 20:29:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> References: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> Message-ID: On Thu, 12 Jun 2025 19:39:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits: > > - Fix full-screen bug > - Merge branch 'master' into feature/extended-window > - only dispose ViewSceneOverlay when non-null > - Rename default window button style classes > - Set the scene root as the parent of the overlay node > - rename WindowManager to DesktopEnvironment > - enable preview feature system properties for tests > - javadoc fix > - fix memory leak in ViewScene > - Merge branch 'master' into feature/extended-window > - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2922557634 From kcr at openjdk.org Thu Jun 12 20:29:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 20:29:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> References: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> Message-ID: On Thu, 12 Jun 2025 19:39:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits: > > - Fix full-screen bug > - Merge branch 'master' into feature/extended-window > - only dispose ViewSceneOverlay when non-null > - Rename default window button style classes > - Set the scene root as the parent of the overlay node > - rename WindowManager to DesktopEnvironment > - enable preview feature system properties for tests > - javadoc fix > - fix memory leak in ViewScene > - Merge branch 'master' into feature/extended-window > - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f Since this is preexisting, let's file a follow-on bug for this and anything else you find that isn't caused by this PR (if we think is a bug). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2968062566 From kcr at openjdk.org Thu Jun 12 20:29:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 20:29:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: <3PHxl2ZAB_Z304RP4f7iu-E4Cy5SKMJ-aJT00WyNKlY=.18c957eb-a515-4816-a96a-50129a4b826f@github.com> References: <4gOs15pXZfRsenY_9x91MyKmQJwl0CtFljZFx2rDm-Y=.c1649564-11e3-4acc-8704-3bfa40f79244@github.com> <3PHxl2ZAB_Z304RP4f7iu-E4Cy5SKMJ-aJT00WyNKlY=.18c957eb-a515-4816-a96a-50129a4b826f@github.com> Message-ID: On Thu, 12 Jun 2025 19:41:47 GMT, Michael Strau? wrote: > it was introduced by the previous patch. In order for CSS to work as expected, all nodes must be traceable to a single root node. This means that the parent of the overlay node is the scene root. However, in some cases during bounds calculation, the method `Parent.childBoundsChanged(Node)` is invoked on the root node by the overlay node. > > `Parent` assumes that if a child calls this method and passes itself as an argument, that the supposed child must also be contained in its own children list. In the case of the overlay node, this it not the case. The fix for this bug is to check whether the supposed child is actually contained in the root's children list, before continuing with the code path which assumes that it is. This explanation, and the fix you did, seem reasonable. I hope there aren't other places that make this same assumption. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2968065990 From angorya at openjdk.org Thu Jun 12 20:29:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 20:29:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v83] In-Reply-To: References: <4gOs15pXZfRsenY_9x91MyKmQJwl0CtFljZFx2rDm-Y=.c1649564-11e3-4acc-8704-3bfa40f79244@github.com> <3PHxl2ZAB_Z304RP4f7iu-E4Cy5SKMJ-aJT00WyNKlY=.18c957eb-a515-4816-a96a-50129a4b826f@github.com> Message-ID: <9TOTasoFfYMoR1ezVB66XQXnb0WmwSMz7YsBWzU268U=.f54c415b-8a6c-4434-a083-52a616410631@github.com> On Thu, 12 Jun 2025 20:25:05 GMT, Kevin Rushforth wrote: > I hope there aren't other places that make this same assumption. I had the same thought. So far nothing I did resulted in an exception. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2968070641 From kizune at openjdk.org Thu Jun 12 20:46:49 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 20:46:49 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: References: Message-ID: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> > Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Add accessible role description to the base component ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1823/files - new: https://git.openjdk.org/jfx/pull/1823/files/1d0bda30..977047d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1823&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1823&range=01-02 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1823.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1823/head:pull/1823 PR: https://git.openjdk.org/jfx/pull/1823 From kizune at openjdk.org Thu Jun 12 20:46:49 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 20:46:49 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 18:36:31 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Fixing indentation. > I see little difference between master and this PR: > > Pagination: > > * adds the word "group" when clicking on the radio button (e.g.: "You are currently on a selected radio button, **group**, 6 of 10) > > What am I doing wrong? It should not say Radio Button, it should say Page. But the group should be with both versions. I have fixed the announcement of the component to tell "page". ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2968106680 From kizune at openjdk.org Thu Jun 12 20:51:36 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 20:51:36 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 19:23:57 GMT, Andy Goryachev wrote: > Also noticed to pre-existing issues (in master): > > * resizing the control does not update the accessibility focus rectangle > * flipping through tabs in TabPane using left/right arrow keys sometimes places the accessibility focus rectangle in a wrong location. I guess it warrants the new bug that we will have to fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2968117596 From mmack at openjdk.org Thu Jun 12 21:21:50 2025 From: mmack at openjdk.org (Markus Mack) Date: Thu, 12 Jun 2025 21:21:50 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> References: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> Message-ID: On Thu, 12 Jun 2025 19:39:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits: > > - Fix full-screen bug > - Merge branch 'master' into feature/extended-window > - only dispose ViewSceneOverlay when non-null > - Rename default window button style classes > - Set the scene root as the parent of the overlay node > - rename WindowManager to DesktopEnvironment > - enable preview feature system properties for tests > - javadoc fix > - fix memory leak in ViewScene > - Merge branch 'master' into feature/extended-window > - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f I left some comments, will re-approve if you decide to change anything. Testing looks good. modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 1932: > 1930: // When we have a scene overlay (like the full-screen notification message or default window buttons > 1931: // of an extended stage), the scene root is the parent of the overlay node. However, the overlay node > 1932: // is not contained in the scene root's children list, because it is not a publicly accessibly part of minor: accessibly -> accessible modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 1935: > 1933: // the scene graph. When this method is called on the root node, we need to check whether the supposed > 1934: // child is actually contained in the children list. > 1935: if (!childSet.contains(node)) { My tests confirm that the issue occurs when `setChildDirty` is called on the overlay node. This method may also be called from `childIncluded`and `childExcluded` which seems to be triggered when a node's visibility changes. If this doesn't happen the fix looks fine. Alternative may be to move the check inside `setChildDirty`. ------------- Marked as reviewed by mmack (Author). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2922633419 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2143644730 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2143657673 From kcr at openjdk.org Thu Jun 12 21:25:48 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 21:25:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> References: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> Message-ID: On Thu, 12 Jun 2025 19:39:30 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits: > > - Fix full-screen bug > - Merge branch 'master' into feature/extended-window > - only dispose ViewSceneOverlay when non-null > - Rename default window button style classes > - Set the scene root as the parent of the overlay node > - rename WindowManager to DesktopEnvironment > - enable preview feature system properties for tests > - javadoc fix > - fix memory leak in ViewScene > - Merge branch 'master' into feature/extended-window > - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2922697926 From tsayao at openjdk.org Thu Jun 12 21:27:24 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 12 Jun 2025 21:27:24 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v30] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Do not allow child stages to be fullscreen + tests - Minor adjustments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/b68dab95..9e49fbb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=29 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=28-29 Stats: 716 lines in 4 files changed: 394 ins; 304 del; 18 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 mstrauss at openjdk.org Thu Jun 12 21:46:06 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Jun 2025 21:46:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v85] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/3fdc465f..0bb24e18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=84 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=83-84 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Thu Jun 12 21:53:33 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Jun 2025 21:53:33 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add the same fix in childVisibilityChanged ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/0bb24e18..4a7e57f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=85 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=84-85 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Thu Jun 12 21:53:35 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Jun 2025 21:53:35 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v84] In-Reply-To: References: <-C4mnExPjGzJ6f1BofI6AmbJt6ge2fM90jGKm2n5_v0=.363a300f-2cc9-4d68-a98e-14fb79d5c761@github.com> Message-ID: On Thu, 12 Jun 2025 21:05:38 GMT, Markus Mack 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 108 commits: >> >> - Fix full-screen bug >> - Merge branch 'master' into feature/extended-window >> - only dispose ViewSceneOverlay when non-null >> - Rename default window button style classes >> - Set the scene root as the parent of the overlay node >> - rename WindowManager to DesktopEnvironment >> - enable preview feature system properties for tests >> - javadoc fix >> - fix memory leak in ViewScene >> - Merge branch 'master' into feature/extended-window >> - ... and 98 more: https://git.openjdk.org/jfx/compare/72c1c21a...3fdc465f > > modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 1935: > >> 1933: // the scene graph. When this method is called on the root node, we need to check whether the supposed >> 1934: // child is actually contained in the children list. >> 1935: if (!childSet.contains(node)) { > > My tests confirm that the issue occurs when `setChildDirty` is called on the overlay node. This method may also be called from `childIncluded`and `childExcluded` which seems to be triggered when a node's visibility changes. If this doesn't happen the fix looks fine. Alternative may be to move the check inside `setChildDirty`. I added the same check in `Parent.childVisibilityChanged(Node)`. These two methods seem to be the only methods that are called by children on their parents in this particular way, passing themselves as an argument. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2143718769 From mmack at openjdk.org Thu Jun 12 22:02:51 2025 From: mmack at openjdk.org (Markus Mack) Date: Thu, 12 Jun 2025 22:02:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 21:53:33 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > add the same fix in childVisibilityChanged Looks good, I also ran a quick manual test and don't see anything broken due to the latest change. ------------- Marked as reviewed by mmack (Author). PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2922769250 From angorya at openjdk.org Thu Jun 12 22:50:35 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 22:50:35 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: On Thu, 12 Jun 2025 20:46:49 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add accessible role description to the base component Pagination: now announces "page". Noticed that when the buttons show pages 11-20, the focus is on button 13, it announces "you are currently on selected page, group, 3 of 10" Should it announce the actual page number instead of the button index? ![Screenshot 2025-06-12 at 15 46 19](https://github.com/user-attachments/assets/436380c2-15df-4c97-9661-d69396f71ecf) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2968359201 From kcr at openjdk.org Thu Jun 12 22:50:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 22:50:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 21:53:33 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > add the same fix in childVisibilityChanged Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2922834543 From tsayao at openjdk.org Thu Jun 12 22:54:02 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 12 Jun 2025 22:54:02 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v31] In-Reply-To: References: Message-ID: <4JeTd15d9Vdjz-_Q8LWLuqV5Ft_5aU0EZVBU-irUHrM=.0d11874d-7990-4b74-bbf6-fa26b433fa9d@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. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Fix for when extents are received while fullscreen or maximized ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/9e49fbb4..708a4dbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=30 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=29-30 Stats: 33 lines in 3 files changed: 18 ins; 10 del; 5 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 angorya at openjdk.org Thu Jun 12 22:56:35 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 22:56:35 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: On Thu, 12 Jun 2025 20:46:49 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add accessible role description to the base component TabPane: can't find any differences between this PR and the master. What should it say differently? Also, unlike Pagination, VoiceOver in the TabPane correctly announces the tab number (like "You are currently on a selected tab, group, 106 of 200") ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2968369349 From angorya at openjdk.org Thu Jun 12 22:56:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Jun 2025 22:56:54 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 21:53:33 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > add the same fix in childVisibilityChanged Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2922841427 From tsayao at openjdk.org Thu Jun 12 23:19:06 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 12 Jun 2025 23:19:06 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v32] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... 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 36 commits: - Merge branch 'master' into 8354943 - - Fix for when extents are received while fullscreen or maximized - - Do not allow child stages to be fullscreen + tests - Minor adjustments - - Remove testWindowShowOrder because it fails due to the Window Manager ignoring too often focus requests - - Adjust includes - Remove work-around to allow unresizable Stages to be resized - Other minor adjustments - Merge branch 'master' into 8354943 - Fix typo - Improve StageOwnershipTest - Always report new size (for Kwin) - Merge branch 'master' into 8354943 - ... and 26 more: https://git.openjdk.org/jfx/compare/72c1c21a...129e4dbf ------------- Changes: https://git.openjdk.org/jfx/pull/1789/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=31 Stats: 3949 lines in 29 files changed: 2676 ins; 730 del; 543 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 Jun 12 23:29:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 23:29:31 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 05:41:23 GMT, Ambarish Rapte wrote: > ### Description > This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS. > We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated. > Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing `-Dprism.order=mtl`) > The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use. > > ### Details about the changes > > **Shader changes** > - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl) > - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl > > **Build changes** - There are new tasks added to build.gradle for > - Generation/ Compilation/ linking of Metal shaders > - Compilation of Prism Java and Objective C files > > **Prism** - Prism is the rendering engine of JavaFX. > - Added Metal specific Java classes and respective native implementation which use Metal APIs > - Java side changes: > - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl > - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. > - Native side changes: > - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl > > **Glass** - Glass is the windowing toolkit of JavaFX > - Existing Glass classes are refactored to support both OpenGL and Metal pipelines > - Added Metal specific Glass implementation. > > ### Testing > - Testing performed on different hardware and macOS versions. > - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4) > - macOS versions - macOS 13, macOS 14 and macOS 15 > - Functional Testing: > - All headful tests pass with Metal pipeline. > - Verified samples applications: Ensemble and toys > - Performance Testing: > - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed) > > ### Note to reviewers : > - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline > - It would be a good idea to test both OpenGL and Metal pipelines > - Known issues and tasks ... As this is a large PR I don't expect any one reviewer to review the whole thing, but I do want to make sure that each piece is reviewed by someone. So we'd like as many eyes on this as possible. The parts we are most concerned with getting reviewed are changes in existing classes that could impact other pipelines, particularly the default ES2 pipeline on macOS For example, there are some minor changes in the Prism base classes, which necessitated changes in the pipeline-specific classes. The largest change in shared code is the glass refactoring to move the rendering-pipeline-specific code (OpenGL or Metal) into pipeline-specific classes. For some classes, the existing code is split between the base class and the CGL subclass (with the MTL class being new implementation for Metal). Here are the main classes to look at: * GlassCGLFrameBufferObject -- renamed from GlassFrameBufferObject with minor changes * GlassMTLFrameBufferObject -- sibling class * GlassOffscreen -- pipeline-specific pieces moved to subclasses * GlassCGLOffscreen * GlassMTLOffscreen * GlassLayer3D -- pipeline-specific pieces moved to sub-layers (not using inheritance) * GlassLayerCGL3D * GlassLayerMTL3D * GlassView -- minor changes to remove OpenGL-isms and fix a few other interface issues * GlassView3D -- pipeline-specific pieces moved to subclasses * GlassViewCGL3D * GlassViewMTL3D @jayathirthrao can give more details on the above glass refacatoring changes if you are interested @beldenfox If you are willing to look at it, we would be quite appreciative of your comments or suggestions on the glass refactoring. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-2968429780 From kcr at openjdk.org Thu Jun 12 23:32:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 23:32:31 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline In-Reply-To: References: Message-ID: <0hfPZORC7trBy8iv9Oa8e8Ks_yIunsvCcQzMnnpGs70=.daab54a6-6ad9-4034-b9bc-985659b77526@github.com> On Thu, 12 Jun 2025 05:41:23 GMT, Ambarish Rapte wrote: > ### Description > This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS. > We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated. > Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing `-Dprism.order=mtl`) > The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use. > > ### Details about the changes > > **Shader changes** > - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl) > - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl > > **Build changes** - There are new tasks added to build.gradle for > - Generation/ Compilation/ linking of Metal shaders > - Compilation of Prism Java and Objective C files > > **Prism** - Prism is the rendering engine of JavaFX. > - Added Metal specific Java classes and respective native implementation which use Metal APIs > - Java side changes: > - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl > - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. > - Native side changes: > - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl > > **Glass** - Glass is the windowing toolkit of JavaFX > - Existing Glass classes are refactored to support both OpenGL and Metal pipelines > - Added Metal specific Glass implementation. > > ### Testing > - Testing performed on different hardware and macOS versions. > - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4) > - macOS versions - macOS 13, macOS 14 and macOS 15 > - Functional Testing: > - All headful tests pass with Metal pipeline. > - Verified samples applications: Ensemble and toys > - Performance Testing: > - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed) > > ### Note to reviewers : > - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline > - It would be a good idea to test both OpenGL and Metal pipelines > - Known issues and tasks ... @tiainen Would you be able to look at the build changes and also do a test build? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-2968435463 From duke at openjdk.org Fri Jun 13 00:08:47 2025 From: duke at openjdk.org (Cormac Redmond) Date: Fri, 13 Jun 2025 00:08:47 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 21:53:33 GMT, Michael Strau? wrote: >> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > add the same fix in childVisibilityChanged Have DialogPanes and Alerts been considered for use with HeaderBar & StageStyle.EXTENDED? I.e., re: Alerts, cater for **hiding** minimise / maximise icons by default, but still showing the close (X) icon. Seems to me that StageStyle.EXTENDED implies all three icons must be shown, and if any other configuration is required, it involes hiding everything (by setting height to 0) and creating your own button(s). Which, if all you want is the close button, there's no simple way to create _that_. Or is there? Shouldn't this be made much simpler for the dev? Even if they need to manage their own buttons for these standard utility-style popups (which isn't a great experience given it's currently handled for us by default), can't we provide a way to instantiate the window icons as nodes? Maybe I am missing something. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2968499508 From kizune at openjdk.org Fri Jun 13 01:02:06 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 13 Jun 2025 01:02:06 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: <2_xw7fRBs8D5nZP4fAAiVg6yNIHUc0L1XmAloZv5cO0=.d6b47f05-59a5-4177-a696-baa4dd9234aa@github.com> On Thu, 12 Jun 2025 22:53:11 GMT, Andy Goryachev wrote: > TabPane: can't find any differences between this PR and the master. What should it say differently? Nothing. TabPane should behave exactly the same. I need to check what's going on with pagination, but i do not think it is changed from master - i haven't touched the logic that generates the indexes, i'm using the same information as before. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2968669780 From mstrauss at openjdk.org Fri Jun 13 01:00:55 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 13 Jun 2025 01:00:55 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 00:05:00 GMT, Cormac Redmond wrote: > Have DialogPanes and Alerts been considered for use with HeaderBar & StageStyle.EXTENDED? I haven't spent much time thinking about this yet. > I.e., re: Alerts, cater for **hiding** minimise / maximise icons by default, but still showing the close (X) icon. > > Seems to me that StageStyle.EXTENDED implies all three icons must be shown, and if any other configuration is required, it involes hiding everything (by setting height to 0) and creating your own button(s). Which, if all you want is the close button, there's no simple way to create _that_. Or is there? Not yet. In an earlier iteration of this feature, there was an `EXTENDED_UTILITY` stage style, which gave you a utility-style extended window with a close button only (which I think is exactly what you're asking). This didn't make it into the final feature, because it would essentially be a combination of two existing styles (`EXTENDED` and `UTILITY`). I think before adding other styles, we should first discuss whether this is the right direction in the first place. Rather than adding those combinatorial styles, I would rather remove/deprecate `UTILITY` and `TRANSPARENT`, so that you can essentially choose between three fundamental stage styles: `DECORATED`, `UNDECORATED`, and `EXTENDED`. Then you could add utility-ness and transparent-ness as independent attributes with a new `Stage.initUtility(boolean)` and `Stage.initTransparent(boolean)` API. > Shouldn't this be made much simpler for the dev? Even if they need to manage their own buttons for these standard utility-style popups (which isn't a great experience given it's currently handled for us by default), can't we provide a way to instantiate the window icons as nodes? > > Maybe I am missing something. > > Also, in general, maybe some documentation on how to use HeaderBar for DialogPanes. E.g., I assume you'd need to dialogPane.setHeader(headerBar) on each and every dialog. Yes, I agree that this should be much simpler. This would be a good enhancement for the future. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2968668477 From tsayao at openjdk.org Fri Jun 13 01:06:17 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 13 Jun 2025 01:06:17 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk Message-ID: Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 Major Linux distributions already provide GTK 3.20 or newer: - Ubuntu LTS 18.04+ (ships GTK 3.22+) - Debian 9+ (ships GTK 3.22+) - Fedora 24+ (ships GTK 3.20+) - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) ------------- Commit messages: - Remove return - Require Gtk 3.20 Changes: https://git.openjdk.org/jfx/pull/1825/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1825&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359396 Stats: 61 lines in 3 files changed: 36 ins; 23 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1825.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1825/head:pull/1825 PR: https://git.openjdk.org/jfx/pull/1825 From mstrauss at openjdk.org Fri Jun 13 04:39:52 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 13 Jun 2025 04:39:52 GMT Subject: Integrated: 8313424: JavaFX controls in the title bar (Preview) In-Reply-To: References: Message-ID: On Sun, 20 Oct 2024 00:47:51 GMT, Michael Strau? wrote: > Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). This pull request has now been integrated. Changeset: fd30c948 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/fd30c94893156644c0d803b3e7fd8c9731d65fe6 Stats: 6849 lines in 78 files changed: 6159 ins; 524 del; 166 mod 8313424: JavaFX controls in the title bar (Preview) Reviewed-by: angorya, mmack, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1605 From kcr at openjdk.org Fri Jun 13 13:18:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Jun 2025 13:18:35 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 01:00:31 GMT, Thiago Milczarek Sayao wrote: > Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. > > JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. > > GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. > > Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 > > Major Linux distributions already provide GTK 3.20 or newer: > - Ubuntu LTS 18.04+ (ships GTK 3.22+) > - Debian 9+ (ships GTK 3.22+) > - Fedora 24+ (ships GTK 3.20+) > - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) This seems like a very reasonable step. All currently supported Linux distros ship with a new enough version of GTK3 that they will be unaffected (and some out of support systems will continue to run). I note that this will preclude running on Ubuntu 16.04 LTS, but given that even Ubuntu 18.04 LTS is out of support, I have no concern with this (other than a personal challenge: I have a dusty old desktop that is still running 16.04 ... time to upgrade or retire that system). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1825#issuecomment-2970366831 From credmond at certak.com Fri Jun 13 13:49:20 2025 From: credmond at certak.com (Cormac Redmond) Date: Fri, 13 Jun 2025 14:49:20 +0100 Subject: StageStyle.EXTENDED & dialogs Message-ID: Hi, To keep the conversation going on window icons / HeaderBar, here are some observations/problems when using StageStyle.EXTENDED for a DialogPane (on Windows): - You need a HeaderBar (at least to take up some space), and you'd need to set it via setHeader(), and if you already have actual header content, you'd need to wrap that content in (probably) a BorderPane (and put the HeaderBar in as top). E.g., it's quite a lot of work to do, everywhere required. - There's no way to control (hide or or disable) the window icons, all three are present - Usually with StageStyle.DECORATED, the dialog's minimise icon is disabled, preventing you from minimizing it: this is not the case with EXTENDED, it's enabled - If you minimise a modal/blocking dialog using the EXTENDED minimise icon, the dialog shrinks to just the size of the title bar, and (mostly) minimises to bottom left of the screen with just the window icons visible: and the whole application is then blocked; the minimized dialog's window icons, while visible, do nothing; so you cannot close or restore the dialog. Also, curiously, their colour changes in my example (presumably because a scene's fill has disappeared or something, changing from dark to light). - For Alerts, they'd typically get a StageStyle.UTILITY, I assume (i.e., just an X window icon); so there are similar problems there when wishing to use EXTENDED, with an inability to control the window icons (even just to hide the minimise/restore buttons). So overall, it seems impossible to leverage the new window icons to mimic existing default behaviour with regards to dialogs/alerts. You'd need to refrain from using EXTENDED for dialogs -- which is quite noticeable and ugly, particularly if there are major colour changes between your main window's title bar, and a dialog's (e.g., dark vs light). I imagine developers using the EXTENDED window icons / HeaderBar will be slow to adopt EXTENDED if their application has a non-uniform look-and-feel for dialogs/popups, etc. Kind Regards, Cormac Redmond -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jun 13 14:30:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Jun 2025 14:30:50 GMT Subject: RFR: 8359445: GHA: Update gradle wrapper-validation action to v4 Message-ID: As noted in JBS, our GitHub Actions workflow uses `gradle/actions/wrapper-validation at v3`. We should update to the latest version, which is v4. In addition to it being a good idea to use the latest, we've seen a lot of intermittent failures in gradle validation, and I hope this might help. ------------- Commit messages: - GHA: Update gradle wrapper-validation to v4 Changes: https://git.openjdk.org/jfx/pull/1826/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359445 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1826.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1826/head:pull/1826 PR: https://git.openjdk.org/jfx/pull/1826 From angorya at openjdk.org Fri Jun 13 14:32:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Jun 2025 14:32:54 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: <9GgWcnFjCovC2lkng3bXUKWcFSRve9Xgt74NaqvzqG4=.fc6f2a56-008c-485d-997a-a838375f5817@github.com> On Fri, 13 Jun 2025 00:58:03 GMT, Michael Strau? wrote: >> Have DialogPanes and Alerts been considered for use with HeaderBar & StageStyle.EXTENDED? >> >> I.e., re: Alerts, cater for **hiding** minimise / maximise icons by default, but still showing the close (X) icon. >> >> Seems to me that StageStyle.EXTENDED implies all three icons must be shown, and if any other configuration is required, it involes hiding everything (by setting height to 0) and creating your own button(s). Which, if all you want is the close button, there's no simple way to create _that_. Or is there? >> >> Shouldn't this be made much simpler for the dev? Even if they need to manage their own buttons for these standard utility-style popups (which isn't a great experience given it's currently handled for us by default), can't we provide a way to instantiate the window icons as nodes? >> >> Maybe I am missing something. >> >> Also, in general, maybe some documentation on how to use HeaderBar for DialogPanes. E.g., I assume you'd need to dialogPane.setHeader(headerBar) on each and every dialog. > >> Have DialogPanes and Alerts been considered for use with HeaderBar & StageStyle.EXTENDED? > > I haven't spent much time thinking about this yet. > >> I.e., re: Alerts, cater for **hiding** minimise / maximise icons by default, but still showing the close (X) icon. >> >> Seems to me that StageStyle.EXTENDED implies all three icons must be shown, and if any other configuration is required, it involes hiding everything (by setting height to 0) and creating your own button(s). Which, if all you want is the close button, there's no simple way to create _that_. Or is there? > > Not yet. In an earlier iteration of this feature, there was an `EXTENDED_UTILITY` stage style, which gave you a utility-style extended window with a close button only (which I think is exactly what you're asking). This didn't make it into the final feature, because it would essentially be a combination of two existing styles (`EXTENDED` and `UTILITY`). I think before adding other styles, we should first discuss whether this is the right direction in the first place. > > Rather than adding those combinatorial styles, I would rather remove/deprecate `UTILITY` and `TRANSPARENT`, so that you can essentially choose between three fundamental stage styles: `DECORATED`, `UNDECORATED`, and `EXTENDED`. Then you could add utility-ness and transparent-ness as independent attributes with a new `Stage.initUtility(boolean)` and `Stage.initTransparent(boolean)` API. > >> Shouldn't this be made much simpler for the dev? Even if they need to manage their own buttons for these standard utility-style popups (which isn't a great experience given it's currently handled for us by default), can't we provide a way to instantiate the window icons as nodes? >> >> Maybe I am missing something. >> >> Also, in general, maybe some documentation on how to use HeaderBar for DialogPanes. E.g., I assume you'd need to dialogPane.setHeader(headerBar) on each and every dialog. > > Yes, I agree that this should be much simpler. This would be a good enhancement for the future. finally in! good job @mstr2 ! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2970586530 From angorya at openjdk.org Fri Jun 13 14:52:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Jun 2025 14:52:57 GMT Subject: RFR: 8359445: GHA: Update gradle wrapper-validation action to v4 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 14:26:04 GMT, Kevin Rushforth wrote: > As noted in JBS, our GitHub Actions workflow uses `gradle/actions/wrapper-validation at v3`. We should update to the latest version, which is v4. > > In addition to it being a good idea to use the latest, we've seen a lot of intermittent failures in gradle validation, and I hope this might help. lgtm, the GHA builds and runs, apparently. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1826#pullrequestreview-2925106285 From mstrauss at openjdk.org Fri Jun 13 15:44:29 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 13 Jun 2025 15:44:29 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] In-Reply-To: References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> Message-ID: On Sat, 7 Jun 2025 18:45:06 GMT, Nir Lisker wrote: > Noting that this proposed change supersedes the previous changes that were done for for https://bugs.openjdk.org/browse/JDK-8226911. The proposed behavioral change makes sense. Can I interest you in a review of the API and/or the implementation? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1822#issuecomment-2970782460 From duke at openjdk.org Fri Jun 13 16:02:55 2025 From: duke at openjdk.org (Cormac Redmond) Date: Fri, 13 Jun 2025 16:02:55 GMT Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v86] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 00:58:03 GMT, Michael Strau? wrote: >> Have DialogPanes and Alerts been considered for use with HeaderBar & StageStyle.EXTENDED? >> >> I.e., re: Alerts, cater for **hiding** minimise / maximise icons by default, but still showing the close (X) icon. >> >> Seems to me that StageStyle.EXTENDED implies all three icons must be shown, and if any other configuration is required, it involes hiding everything (by setting height to 0) and creating your own button(s). Which, if all you want is the close button, there's no simple way to create _that_. Or is there? >> >> Shouldn't this be made much simpler for the dev? Even if they need to manage their own buttons for these standard utility-style popups (which isn't a great experience given it's currently handled for us by default), can't we provide a way to instantiate the window icons as nodes? >> >> Maybe I am missing something. >> >> Also, in general, maybe some documentation on how to use HeaderBar for DialogPanes. E.g., I assume you'd need to dialogPane.setHeader(headerBar) on each and every dialog. > >> Have DialogPanes and Alerts been considered for use with HeaderBar & StageStyle.EXTENDED? > > I haven't spent much time thinking about this yet. > >> I.e., re: Alerts, cater for **hiding** minimise / maximise icons by default, but still showing the close (X) icon. >> >> Seems to me that StageStyle.EXTENDED implies all three icons must be shown, and if any other configuration is required, it involes hiding everything (by setting height to 0) and creating your own button(s). Which, if all you want is the close button, there's no simple way to create _that_. Or is there? > > Not yet. In an earlier iteration of this feature, there was an `EXTENDED_UTILITY` stage style, which gave you a utility-style extended window with a close button only (which I think is exactly what you're asking). This didn't make it into the final feature, because it would essentially be a combination of two existing styles (`EXTENDED` and `UTILITY`). I think before adding other styles, we should first discuss whether this is the right direction in the first place. > > Rather than adding those combinatorial styles, I would rather remove/deprecate `UTILITY` and `TRANSPARENT`, so that you can essentially choose between three fundamental stage styles: `DECORATED`, `UNDECORATED`, and `EXTENDED`. Then you could add utility-ness and transparent-ness as independent attributes with a new `Stage.initUtility(boolean)` and `Stage.initTransparent(boolean)` API. > >> Shouldn't this be made much simpler for the dev? Even if they need to manage their own buttons for these standard utility-style popups (which isn't a great experience given it's currently handled for us by default), can't we provide a way to instantiate the window icons as nodes? >> >> Maybe I am missing something. >> >> Also, in general, maybe some documentation on how to use HeaderBar for DialogPanes. E.g., I assume you'd need to dialogPane.setHeader(headerBar) on each and every dialog. > > Yes, I agree that this should be much simpler. This would be a good enhancement for the future. > finally in! good job @mstr2 ! Yes, impressive. Thanks @mstr2 . ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2970832182 From kcr at openjdk.org Fri Jun 13 17:26:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Jun 2025 17:26:58 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 01:00:31 GMT, Thiago Milczarek Sayao wrote: > Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. > > JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. > > GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. > > Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 > > Major Linux distributions already provide GTK 3.20 or newer: > - Ubuntu LTS 18.04+ (ships GTK 3.22+) > - Debian 9+ (ships GTK 3.22+) > - Fedora 24+ (ships GTK 3.20+) > - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) I ran a CI build including headful tests, and all looks good to me. Running on a system (my old Ubuntu 16.04 box) with an older GTK3 fails with the expected error message: Exception in thread "main" java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1164) Caused by: java.lang.UnsupportedOperationException: Minimum GTK version required is 3.20.0. System has 3.18.9. at javafx.graphics at 25-ea/com.sun.glass.ui.gtk.GtkApplication._initGTK(Native Method) at javafx.graphics at 25-ea/com.sun.glass.ui.gtk.GtkApplication.(GtkApplication.java:165) at javafx.graphics at 25-ea/com.sun.glass.ui.gtk.GtkPlatformFactory.createApplication(GtkPlatformFactory.java:40) at javafx.graphics at 25-ea/com.sun.glass.ui.Application.run(Application.java:143) ... Compiling on a machine with an older GTK3 fails with the expected error message: Starting process 'command 'pkg-config''. Working directory: . Command: pkg-config --exists gtk+-3.0 >= 3.20.0 Successfully started process 'command 'pkg-config'' FAILURE: Build failed with an exception. * Where: Script 'buildSrc/linux.gradle' line: 103 * What went wrong: A problem occurred evaluating script. > GTK3 3.20.0+ development packages not found. If GTK3 packages are installed, please remove the build directory and try again. @tsayao The review likely won't be finished until Monday, but even if it is, please wait until then to give others time to comment. I left one minor suggestion and will reapprove if you make changes. @lukostyra Can you be the second reviewer? @tiainen Do you also want a change to build it? I don't imagine it will cause you any problems, but wanted to give you a chance to comment. buildSrc/linux.gradle line 28: > 26: ext.LINUX = [:] > 27: > 28: def gtk3MinMinorVersion = "20" Minor: maybe add a comment saying that the minimum GTK3 version is 3.20? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1825#pullrequestreview-2925521698 PR Comment: https://git.openjdk.org/jfx/pull/1825#issuecomment-2971031398 PR Review Comment: https://git.openjdk.org/jfx/pull/1825#discussion_r2145529940 From mhanl at openjdk.org Sat Jun 14 11:21:32 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 14 Jun 2025 11:21:32 GMT Subject: RFR: 8359445: GHA: Update gradle wrapper-validation action to v4 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 14:26:04 GMT, Kevin Rushforth wrote: > As noted in JBS, our GitHub Actions workflow uses `gradle/actions/wrapper-validation at v3`. We should update to the latest version, which is v4. > > In addition to it being a good idea to use the latest, we've seen a lot of intermittent failures in gradle validation, and I hope this might help. Looks good. I also hope it helps with intermittent validation failures (Got that at least >10 times in the last month). ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1826#pullrequestreview-2928192418 From mhanl at openjdk.org Sat Jun 14 11:42:03 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 14 Jun 2025 11:42:03 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests Message-ID: As written in the ticket, we might want to clarify that we use `JUnit5` for testing in the `CONTRIBUTING` guidelines. This is a first idea of how we could document this and also link to the JUnit page in case contributors are not familiar with the framework (or `JUnit5` in particular). Feedback welcome! ------------- Commit messages: - 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests Changes: https://git.openjdk.org/jfx/pull/1828/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296284 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1828.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1828/head:pull/1828 PR: https://git.openjdk.org/jfx/pull/1828 From mhanl at openjdk.org Sat Jun 14 11:55:33 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 14 Jun 2025 11:55:33 GMT Subject: RFR: 8354795: DialogPane show details button wipes out base style class "hyperlink" In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 08:51:36 GMT, John Hendrikx wrote: > The "show details" hyperlink button in an alert dialog that has an expandable detail area wipes out its base style class by overwriting all styles. This means styling in modena.css that targets `.hyperlink` is no longer applied, like the default text fill colors. > > The culprit is this code in DialogPane: > > InvalidationListener expandedListener = o -> { > final boolean isExpanded = isExpanded(); > detailsButton.setText(isExpanded ? lessText : moreText); > detailsButton.getStyleClass().setAll("details-button", (isExpanded ? "less" : "more")); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ > }; > > Here it uses `setAll` to set styles, wiping out the default `.hyperlink` style from "Hyperlink detailsButton = new HyperLink()" I think wiping default style classes should not be done. Maybe somewhat related and only my understanding: There are quite some places in JavaFX Controls where e.g. a `StackPane` is used to somewhat mimic a `Control` (often a `Button`). Example: The `TitleRegion` is a `StackPane`, but behaves like a `Button`. This may was done to avoid focus issues, but I can also imagine that this was done to not wipe default style classes / break styling. In the example the `title` style class is set there (If it would be a `Button`, it would be wiped as well there, which might be expected or not for some developers). So to come back, this looks to be the only place where this is done, right? I agree that is should keep the `hyperlink` style class and not wipe them. Or something else must be used, which is probably not feasable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2972657648 From nlisker at openjdk.org Sun Jun 15 05:47:34 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 15 Jun 2025 05:47:34 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] In-Reply-To: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> Message-ID: On Fri, 6 Jun 2025 23:23:05 GMT, Michael Strau? wrote: > JavaFX unnecessarily restricts interpolation in the following ways: > 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1]. > 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:
    >
    > The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):
    > > > Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function. > > This PR includes the following changes: > 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1]. > 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1]. > 3. `SplineInterpolator` now accepts control points with any Y coordinate. > > Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:
    > I left just a couple of general comments. Most of the changes remove the clamping. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/region/BorderImageSlices.java line 62: > 60: Objects.requireNonNull(endValue, "endValue cannot be null"); > 61: > 62: if (t == 0 || equals(endValue)) { `==` on floating point could produce unexpected results since there's +0 and -0. Here it doesn't seem to matter because it's an optimization, but I see more of these in the new code, so might be worth double checking. modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 44: > 42: * Two components are combined by linear interpolation such that the intermediate value is > 43: * produced by computing {@code (1 - t) * start + t * end}. This interpolation type is usually > 44: * applicable for numeric components. I think that the use of "start" and "end" is confusing now since they don't correspond to actual start and end. You can get values that are "after the end". It might be seen more as an extrapolation at this point. In general, this interface now also functions as an extrapolator. ------------- PR Review: https://git.openjdk.org/jfx/pull/1822#pullrequestreview-2928973183 PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2147445913 PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2147434388 From mhanl at openjdk.org Sun Jun 15 14:27:22 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 15 Jun 2025 14:27:22 GMT Subject: RFR: 8359599: Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells Message-ID: When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them. This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`. This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called. The contract of `refresh()` is also a big vague, stating: Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells necessary to populate the visual bounds of the control. In other words, this forces the XXX to update what it is showing to the user. This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself. As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved). ------------- Commit messages: - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells Changes: https://git.openjdk.org/jfx/pull/1830/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1830&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359599 Stats: 476 lines in 14 files changed: 316 ins; 109 del; 51 mod Patch: https://git.openjdk.org/jfx/pull/1830.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1830/head:pull/1830 PR: https://git.openjdk.org/jfx/pull/1830 From mhanl at openjdk.org Sun Jun 15 19:05:45 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 15 Jun 2025 19:05:45 GMT Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a temporary Stage Message-ID: Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls. It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise. Take the following test code: VirtualFlowTestUtils.clickOnRow(tableView, 2); VirtualFlowTestUtils.clickOnRow(tableView, 4); What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after. This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic. So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods. For the example above, this would result in: stageLoader = new StageLoader(tableView); VirtualFlowTestUtils.clickOnRow(tableView, 2); VirtualFlowTestUtils.clickOnRow(tableView, 4); The stageLoader should be disposed in an @AfterEach. Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty. Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly. ------------- Commit messages: - Fix jcheck whitespace - [TestBug] VirtualFlowTestUtils should not create a temporary Stage Changes: https://git.openjdk.org/jfx/pull/1829/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1829&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359598 Stats: 364 lines in 12 files changed: 292 ins; 47 del; 25 mod Patch: https://git.openjdk.org/jfx/pull/1829.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1829/head:pull/1829 PR: https://git.openjdk.org/jfx/pull/1829 From mstrauss at openjdk.org Sun Jun 15 20:06:11 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 15 Jun 2025 20:06:11 GMT Subject: RFR: 8359601: Fix window button states of an extended stage Message-ID: The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: #### Windows 11 | Window attributes | Iconify | Maximize | Close | |---|---|---|---| | resizable, not modal | visible | visible | visible | | not resizable, not modal | visible | visible, disabled | visible | | resizable, modal | visible, disabled | visible | visible | | not resizable, modal | hidden | hidden | visible, utility-style | #### Ubuntu 24 / Fedora 41 (GNOME) | Window attributes | Iconify | Maximize | Close | |---|---|---|---| | resizable, not modal | visible | visible | visible | | not resizable, not modal | visible | hidden | visible | | resizable, modal | visible, _not working_ | visible, _not working_ | visible | | not resizable, modal | visible, _not working_ | hidden | visible | #### Kubuntu 24 (KDE) | Window attributes | Iconify | Maximize | Close | |---|---|---|---| | resizable, not modal | visible | visible | visible | | not resizable, not modal | visible | hidden | visible | | resizable, modal | visible, _not working_ | visible | visible | | not resizable, modal | visible, _not working_ | hidden | visible | ## Observations 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) ## Permitted window button operations Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: | Window attributes | Iconify | Maximize | Close | |---|---|---|---| | resizable, not modal | yes | yes | yes | | not resizable, not modal | yes | no | yes | | resizable, modal | no | yes | yes | | not resizable, modal | no | no | yes | ## Fixes This PR includes the following changes: 1. Unused code relating to window modality is removed. 2. The disabled states of `HeaderButtonOverlay` as well as `HeaderButtonBehavior` are changed to match the table above. 3. The stylesheets for GNOME and KDE are changed such that disabled buttons are hidden. 4. The stylesheet for Windows is changed such that a modal/non-resizable window looks like a utility window. ------------- Commit messages: - Fix disabled states of custom window buttons - Fix disabled/hidden states of default window buttons - Remove unused window modality code Changes: https://git.openjdk.org/jfx/pull/1831/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1831&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359601 Stats: 469 lines in 18 files changed: 181 ins; 254 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/1831.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1831/head:pull/1831 PR: https://git.openjdk.org/jfx/pull/1831 From michaelstrau2 at gmail.com Sun Jun 15 20:58:32 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 15 Jun 2025 22:58:32 +0200 Subject: StageStyle.EXTENDED & dialogs In-Reply-To: References: Message-ID: Hi Cormac, I think there are several overlapping problems here. Let's start with the window button states. I've prepared a PR to align the states of extended window buttons with what would be expected on the OS [0]. This seems to address your points 2, 3, and 4. Second, let's look at this piece of code: var dialog = new Dialog<>(); dialog.initStyle(StageStyle.EXTENDED); dialog.setTitle("My Dialog"); dialog.setContentText("My Content"); dialog.getDialogPane().getButtonTypes().addAll(ButtonType.OK); dialog.getDialogPane().setHeader(new HeaderBar()); dialog.show(); To me, this seems like it should work, but it doesn't (the `HeaderBar` has a height of 0). The reason for that is that `DialogPane` doesn't respect the minHeight of the `HeaderBar`; it only uses its prefHeight (which is 0). This is probably a bug: a control should never use prefHeight alone, but should use the result of clamp(prefHeight, minHeight, maxHeight) instead. Third: Assuming that the bug above is fixed, we have the question of whether we need additional API in `Alert`, `Dialog`, or `DialogPane`. I don't have a strong opinion on that yet. With all fixes in, it's certainly possible to create extended dialogs without new API. Is it too much work to wrap your content and a `HeaderBar` in a `BorderPane`? Do developers really repeatedly use the Alert/Dialog API in their code, or would they not usually create a utility method for that? [0] https://github.com/openjdk/jfx/pull/1831 On Fri, Jun 13, 2025 at 5:39?PM Cormac Redmond wrote: > > Hi, > > To keep the conversation going on window icons / HeaderBar, here are some observations/problems when using StageStyle.EXTENDED for a DialogPane (on Windows): > > You need a HeaderBar (at least to take up some space), and you'd need to set it via setHeader(), and if you already have actual header content, you'd need to wrap that content in (probably) a BorderPane (and put the HeaderBar in as top). E.g., it's quite a lot of work to do, everywhere required. > There's no way to control (hide or or disable) the window icons, all three are present > > Usually with StageStyle.DECORATED, the dialog's minimise icon is disabled, preventing you from minimizing it: this is not the case with EXTENDED, it's enabled > > If you minimise a modal/blocking dialog using the EXTENDED minimise icon, the dialog shrinks to just the size of the title bar, and (mostly) minimises to bottom left of the screen with just the window icons visible: and the whole application is then blocked; the minimized dialog's window icons, while visible, do nothing; so you cannot close or restore the dialog. Also, curiously, their colour changes in my example (presumably because a scene's fill has disappeared or something, changing from dark to light). > For Alerts, they'd typically get a StageStyle.UTILITY, I assume (i.e., just an X window icon); so there are similar problems there when wishing to use EXTENDED, with an inability to control the window icons (even just to hide the minimise/restore buttons). > > So overall, it seems impossible to leverage the new window icons to mimic existing default behaviour with regards to dialogs/alerts. You'd need to refrain from using EXTENDED for dialogs -- which is quite noticeable and ugly, particularly if there are major colour changes between your main window's title bar, and a dialog's (e.g., dark vs light). > > I imagine developers using the EXTENDED window icons / HeaderBar will be slow to adopt EXTENDED if their application has a non-uniform look-and-feel for dialogs/popups, etc. > > > > > Kind Regards, > Cormac Redmond From tsayao at openjdk.org Sun Jun 15 21:12:45 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 15 Jun 2025 21:12:45 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v2] In-Reply-To: References: Message-ID: > Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. > > JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. > > GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. > > Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 > > Major Linux distributions already provide GTK 3.20 or newer: > - Ubuntu LTS 18.04+ (ships GTK 3.22+) > - Debian 9+ (ships GTK 3.22+) > - Fedora 24+ (ships GTK 3.20+) > - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add Comment about gtk 3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1825/files - new: https://git.openjdk.org/jfx/pull/1825/files/e1dc7e47..ab611660 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1825&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1825&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1825.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1825/head:pull/1825 PR: https://git.openjdk.org/jfx/pull/1825 From mstrauss at openjdk.org Sun Jun 15 22:05:31 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 15 Jun 2025 22:05:31 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] In-Reply-To: References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> Message-ID: <2hckKMKHV7oCNMuoSkvLJC_mXesoegHytkygng7sSYo=.7d7172ab-c9aa-4f46-8d80-2ddd4236f9ad@github.com> On Sun, 15 Jun 2025 05:34:17 GMT, Nir Lisker wrote: >> JavaFX unnecessarily restricts interpolation in the following ways: >> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1]. >> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:
    >>
    >> The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):
    >> >> >> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function. >> >> This PR includes the following changes: >> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1]. >> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1]. >> 3. `SplineInterpolator` now accepts control points with any Y coordinate. >> >> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:
    >> > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/region/BorderImageSlices.java line 62: > >> 60: Objects.requireNonNull(endValue, "endValue cannot be null"); >> 61: >> 62: if (t == 0 || equals(endValue)) { > > `==` on floating point could produce unexpected results since there's +0 and -0. Here it doesn't seem to matter because it's an optimization, but I see more of these in the new code, so might be worth double checking. +0 and -0 seem to be equal when using the `==` operator: double a = 0.0; double b = -0.0; System.out.println(a == b); // prints "true" System.out.println(a < b); // prints "false" System.out.println(a > b); // prints "false" If the sign is relevant, one must use `Double.compare`: double a = 0.0; double b = -0.0; System.out.println(Double.compare(a, b)); // prints "1" System.out.println(Double.compare(b, a)); // prints "-1" ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2148839136 From mstrauss at openjdk.org Sun Jun 15 22:09:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 15 Jun 2025 22:09:47 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v2] In-Reply-To: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> Message-ID: > JavaFX unnecessarily restricts interpolation in the following ways: > 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1]. > 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:
    >
    > The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):
    > > > Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function. > > This PR includes the following changes: > 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1]. > 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1]. > 3. `SplineInterpolator` now accepts control points with any Y coordinate. > > Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:
    > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1822/files - new: https://git.openjdk.org/jfx/pull/1822/files/85aacc4d..92d06d7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1822&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1822&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1822.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1822/head:pull/1822 PR: https://git.openjdk.org/jfx/pull/1822 From mstrauss at openjdk.org Sun Jun 15 22:09:48 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 15 Jun 2025 22:09:48 GMT Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v2] In-Reply-To: References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com> Message-ID: On Sun, 15 Jun 2025 05:22:13 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 44: > >> 42: * Two components are combined by linear interpolation such that the intermediate value is >> 43: * produced by computing {@code (1 - t) * start + t * end}. This interpolation type is usually >> 44: * applicable for numeric components. > > I think that the use of "start" and "end" is confusing now since they don't correspond to actual start and end. You can get values that are "after the end". It might be seen more as an extrapolation at this point. In general, this interface now also functions as an extrapolator. I've added the following sentence: `Note that this formula produces values less than {@code start} for {@code t < 0} and values greater than {@code end} for {@code t > 1}.` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2148839873 From mstrauss at openjdk.org Sun Jun 15 22:14:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 15 Jun 2025 22:14:17 GMT Subject: RFR: 8345348: CSS media feature queries [v32] In-Reply-To: References: Message-ID: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: - Merge branch 'master' into feature/media-queries - use custom mediaFeature javadoc tag - Merge branch 'master' into feature/media-queries - fix wrong
    HTML tags - Merge branch 'master' into feature/media-queries - doc - reorder Scene.Preferences.colorScheme - move doc from Scene.Preferences to Platform.Preferences - Merge branch 'master' into feature/media-queries - add -fx vendor prefix to prefers-persistent-scrollbars - ... and 38 more: https://git.openjdk.org/jfx/compare/fd30c948...e769ce17 ------------- Changes: https://git.openjdk.org/jfx/pull/1655/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=31 Stats: 5238 lines in 43 files changed: 4072 ins; 1058 del; 108 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From credmond at certak.com Mon Jun 16 00:15:51 2025 From: credmond at certak.com (Cormac Redmond) Date: Mon, 16 Jun 2025 01:15:51 +0100 Subject: StageStyle.EXTENDED & dialogs In-Reply-To: References: Message-ID: Hi Michael, Amazing to address the main issue (utility window icons, etc.) so quickly. I will test your new PR tomorrow (I'm Irish time, late here). No, I do not think wrapping it in a BorderPane manually is a problem if it didn't present any unexpected problems. But, there'd be some pain/risk re: third-party or library dialogs, etc. Imagine you're using a library which returns a dialog with an already-populated header node, where all you want is consistent window icons (i.e., uniform colors or custom icons as per your main screen), you'd need to always check for header nodes and wrap them in a BorderPane with a HeaderBar in top. Or consider maybe a dialog header node that gets updated/replaced *after* the dialog is shown -- you'd lose your BorderPane/HeaderBar if you don't have control over that code that does the replace (i.e., in third-party code). Not sure if that's even possible, but I presume it is valid. Also, a dialog's headerText field would present a problem, presumably, as using a header node (to get the title bar / window icons) would mean you'd need to also check for or migrate headerText usages and stick it into a header node (i.e., the BorderPane's center as a Label, or whatever). This might break CSS. Similar issue for "graphic". Again, I'm thinking about third-party libs that might use these fields today. Would it be an idea that a pane (whether dialog or all) has a "title bar" node field, and leave header alone (where header takes in the meaning of "everything below title bar")..? Just some thoughts for now. I'll leave some proper comments on the PR after testing. Kind Regards, Cormac On Sun, 15 Jun 2025 at 21:58, Michael Strau? wrote: > Hi Cormac, > > I think there are several overlapping problems here. > > Let's start with the window button states. I've prepared a PR to align > the states of extended window buttons with what would be expected on > the OS [0]. This seems to address your points 2, 3, and 4. > > Second, let's look at this piece of code: > > var dialog = new Dialog<>(); > dialog.initStyle(StageStyle.EXTENDED); > dialog.setTitle("My Dialog"); > dialog.setContentText("My Content"); > dialog.getDialogPane().getButtonTypes().addAll(ButtonType.OK); > dialog.getDialogPane().setHeader(new HeaderBar()); > dialog.show(); > > To me, this seems like it should work, but it doesn't (the `HeaderBar` > has a height of 0). The reason for that is that `DialogPane` doesn't > respect the minHeight of the `HeaderBar`; it only uses its prefHeight > (which is 0). This is probably a bug: a control should never use > prefHeight alone, but should use the result of clamp(prefHeight, > minHeight, maxHeight) instead. > > Third: Assuming that the bug above is fixed, we have the question of > whether we need additional API in `Alert`, `Dialog`, or `DialogPane`. > I don't have a strong opinion on that yet. With all fixes in, it's > certainly possible to create extended dialogs without new API. Is it > too much work to wrap your content and a `HeaderBar` in a > `BorderPane`? Do developers really repeatedly use the Alert/Dialog API > in their code, or would they not usually create a utility method for > that? > > [0] https://github.com/openjdk/jfx/pull/1831 > > > > On Fri, Jun 13, 2025 at 5:39?PM Cormac Redmond > wrote: > > > > Hi, > > > > To keep the conversation going on window icons / HeaderBar, here are > some observations/problems when using StageStyle.EXTENDED for a DialogPane > (on Windows): > > > > You need a HeaderBar (at least to take up some space), and you'd need to > set it via setHeader(), and if you already have actual header content, > you'd need to wrap that content in (probably) a BorderPane (and put the > HeaderBar in as top). E.g., it's quite a lot of work to do, everywhere > required. > > There's no way to control (hide or or disable) the window icons, all > three are present > > > > Usually with StageStyle.DECORATED, the dialog's minimise icon is > disabled, preventing you from minimizing it: this is not the case with > EXTENDED, it's enabled > > > > If you minimise a modal/blocking dialog using the EXTENDED minimise > icon, the dialog shrinks to just the size of the title bar, and (mostly) > minimises to bottom left of the screen with just the window icons visible: > and the whole application is then blocked; the minimized dialog's window > icons, while visible, do nothing; so you cannot close or restore the > dialog. Also, curiously, their colour changes in my example (presumably > because a scene's fill has disappeared or something, changing from dark to > light). > > For Alerts, they'd typically get a StageStyle.UTILITY, I assume (i.e., > just an X window icon); so there are similar problems there when wishing to > use EXTENDED, with an inability to control the window icons (even just to > hide the minimise/restore buttons). > > > > So overall, it seems impossible to leverage the new window icons to > mimic existing default behaviour with regards to dialogs/alerts. You'd need > to refrain from using EXTENDED for dialogs -- which is quite noticeable and > ugly, particularly if there are major colour changes between your main > window's title bar, and a dialog's (e.g., dark vs light). > > > > I imagine developers using the EXTENDED window icons / HeaderBar will be > slow to adopt EXTENDED if their application has a non-uniform look-and-feel > for dialogs/popups, etc. > > > > > > > > > > Kind Regards, > > Cormac Redmond > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Jun 16 05:23:35 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Jun 2025 05:23:35 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests In-Reply-To: References: Message-ID: On Sat, 14 Jun 2025 11:37:30 GMT, Marius Hanl wrote: > As written in the ticket, we might want to clarify that we use `JUnit5` for testing in the `CONTRIBUTING` guidelines. > > This is a first idea of how we could document this and also link to the JUnit page in case contributors are not familiar with the framework (or `JUnit5` in particular). > > Feedback welcome! CONTRIBUTING.md line 232: > 230: * Wildcard imports – for example, `import java.util.*;` – are forbidden and may cause the build to fail. Please attempt to configure your IDE so it doesn't generate wildcard imports. An exception to this rule is that wildcard static imports in test classes are allowed, for example, `import static org.junit.jupiter.api.Assertions.*;`. > 231: * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. > 232: * Tests are written using [JUnit5](https://junit.org/junit5/). Should we mention about JUnit5 under **Test your changes** ([here](https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/CONTRIBUTING.md?plain=1#L66)), where we mention that a fix should have associated tests? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1828#discussion_r2149064957 From arapte at openjdk.org Mon Jun 16 05:33:37 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Jun 2025 05:33:37 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: On Thu, 12 Jun 2025 22:48:04 GMT, Andy Goryachev wrote: > Noticed that when the buttons show pages 11-20, the focus is on button 13, it announces "you are currently on selected page, group, 3 of 10" This is observed on windows too. Seems like an existing issue, may be we should report an issue and address separately. Otherwise LGTM ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2975155533 From arapte at openjdk.org Mon Jun 16 05:55:34 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Jun 2025 05:55:34 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: On Thu, 12 Jun 2025 20:46:49 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add accessible role description to the base component LGTM modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 188: > 186: jAccessibilityAttributeValue, (jlong)@"AXChildren"); > 187: GLASS_CHECK_EXCEPTION(env); > 188: return variantToID(env, jresult); A general comment(not for this PR): There seems to be many methods with same body except change in last parameter in call to `CallLongMethod`. May be can change these methods to have a helper method. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1823#pullrequestreview-2930720201 PR Review Comment: https://git.openjdk.org/jfx/pull/1823#discussion_r2149100376 From sykora at openjdk.org Mon Jun 16 07:34:35 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Mon, 16 Jun 2025 07:34:35 GMT Subject: RFR: 8358770: incubator.richtext pom missing dependency on incubator.input In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 15:27:33 GMT, Kevin Rushforth wrote: > This PR adds a missing maven dependency for `jfx.incubator.richtext` on the `jfx.incubator.input` module. The dependency is correctly present in the `module-info.java` of `jfx.incubator.richtext` as well as the gradle dependency for the project. It's only the maven dependency that is missing. While fixing this, I noticed that there is an unnecessary maven dependency in the `incubator.richtext` and `incubator.input` projects on the `graphics` project. Both projects already list `controls`, so do not need to list `graphics` or `base` (see the `fxml` and `web` projects for comparison). This looks correct. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1821#pullrequestreview-2930936099 From kcr at openjdk.org Mon Jun 16 12:36:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Jun 2025 12:36:41 GMT Subject: Integrated: 8359445: GHA: Update gradle wrapper-validation action to v4 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 14:26:04 GMT, Kevin Rushforth wrote: > As noted in JBS, our GitHub Actions workflow uses `gradle/actions/wrapper-validation at v3`. We should update to the latest version, which is v4. > > In addition to it being a good idea to use the latest, we've seen a lot of intermittent failures in gradle validation, and I hope this might help. This pull request has now been integrated. Changeset: 3922d38f Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/3922d38fd6b2cec8d7fa9a81f279c2add6dbeeb1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8359445: GHA: Update gradle wrapper-validation action to v4 Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1826 From kcr at openjdk.org Mon Jun 16 12:45:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Jun 2025 12:45:35 GMT Subject: Integrated: 8358770: incubator.richtext pom missing dependency on incubator.input In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 15:27:33 GMT, Kevin Rushforth wrote: > This PR adds a missing maven dependency for `jfx.incubator.richtext` on the `jfx.incubator.input` module. The dependency is correctly present in the `module-info.java` of `jfx.incubator.richtext` as well as the gradle dependency for the project. It's only the maven dependency that is missing. While fixing this, I noticed that there is an unnecessary maven dependency in the `incubator.richtext` and `incubator.input` projects on the `graphics` project. Both projects already list `controls`, so do not need to list `graphics` or `base` (see the `fxml` and `web` projects for comparison). This pull request has now been integrated. Changeset: 859a3080 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/859a308043b16382246a317e1eb9e1cb153604a7 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8358770: incubator.richtext pom missing dependency on incubator.input Reviewed-by: angorya, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1821 From zelmidaoui at openjdk.org Mon Jun 16 13:07:40 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Mon, 16 Jun 2025 13:07:40 GMT Subject: RFR: 8357393: RichTextArea: fails to properly save text attributes [v2] In-Reply-To: References: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com> Message-ID: On Thu, 29 May 2025 18:42:10 GMT, Andy Goryachev wrote: >> Fixing a bug that breaks proper saving of character attributes. >> >> This, unfortunately, makes a breaking change in the RichTextArea native format [0]. >> >> ## References >> >> [0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea_DataFormat_V2.md > > 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 six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser > - javadoc > - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser > - test > - tests > - fixed attribute serialization LGTM. I?ve tested it on macOS, and the issue is resolved with this fix. It is working as expected. ------------- Marked as reviewed by zelmidaoui (Author). PR Review: https://git.openjdk.org/jfx/pull/1813#pullrequestreview-2932055457 From kcr at openjdk.org Mon Jun 16 14:20:34 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Jun 2025 14:20:34 GMT Subject: RFR: 8359599: Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl wrote: > When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them. > > This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`. > > This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called. > > The contract of `refresh()` is also a big vague, stating: > > Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells > necessary to populate the visual bounds of the control. > In other words, this forces the XXX to update what it is showing to the user. > This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself. > > > As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved). This is a risky change and will need to be carefully tested. Reviewers: @andy-goryachev-oracle @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-2976845612 From mstrauss at openjdk.org Mon Jun 16 15:31:20 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 16 Jun 2025 15:31:20 GMT Subject: RFR: 8345348: CSS media feature queries [v33] In-Reply-To: References: Message-ID: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits: - Merge branch 'master' into feature/media-queries - Merge branch 'master' into feature/media-queries - use custom mediaFeature javadoc tag - Merge branch 'master' into feature/media-queries - fix wrong
    HTML tags - Merge branch 'master' into feature/media-queries - doc - reorder Scene.Preferences.colorScheme - move doc from Scene.Preferences to Platform.Preferences - Merge branch 'master' into feature/media-queries - ... and 39 more: https://git.openjdk.org/jfx/compare/859a3080...a9e97db0 ------------- Changes: https://git.openjdk.org/jfx/pull/1655/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=32 Stats: 5238 lines in 43 files changed: 4072 ins; 1058 del; 108 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From angorya at openjdk.org Mon Jun 16 15:36:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Jun 2025 15:36:36 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: <2q9dHceYfNqEtMhq2Qttg3ha4cgBCt8ZyE_Fao4pWSo=.d6c3559f-c013-414a-b2a0-1507107e08eb@github.com> On Thu, 12 Jun 2025 20:46:49 GMT, Alexander Zuev wrote: >> Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add accessible role description to the base component Marked as reviewed by angorya (Reviewer). I am ok with addressing Pagination index issue in a separate PR, though I wonder how much work it is - since we are fixing it here, why not finish it in this PR. But if you prefer a separate PR, this lgtm. ------------- PR Review: https://git.openjdk.org/jfx/pull/1823#pullrequestreview-2932618876 PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2977108436 From angorya at openjdk.org Mon Jun 16 15:38:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Jun 2025 15:38:36 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 05:20:45 GMT, Ambarish Rapte wrote: >> As written in the ticket, we might want to clarify that we use `JUnit5` for testing in the `CONTRIBUTING` guidelines. >> >> This is a first idea of how we could document this and also link to the JUnit page in case contributors are not familiar with the framework (or `JUnit5` in particular). >> >> Feedback welcome! > > CONTRIBUTING.md line 232: > >> 230: * Wildcard imports – for example, `import java.util.*;` – are forbidden and may cause the build to fail. Please attempt to configure your IDE so it doesn't generate wildcard imports. An exception to this rule is that wildcard static imports in test classes are allowed, for example, `import static org.junit.jupiter.api.Assertions.*;`. >> 231: * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. >> 232: * Tests are written using [JUnit5](https://junit.org/junit5/). > > Should we mention about JUnit5 under **Test your changes** ([here](https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/CONTRIBUTING.md?plain=1#L66)), where we mention that a fix should have associated tests? (if possible) ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1828#discussion_r2150311386 From angorya at openjdk.org Mon Jun 16 15:41:35 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Jun 2025 15:41:35 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 15:35:59 GMT, Andy Goryachev wrote: >> CONTRIBUTING.md line 232: >> >>> 230: * Wildcard imports – for example, `import java.util.*;` – are forbidden and may cause the build to fail. Please attempt to configure your IDE so it doesn't generate wildcard imports. An exception to this rule is that wildcard static imports in test classes are allowed, for example, `import static org.junit.jupiter.api.Assertions.*;`. >>> 231: * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. >>> 232: * Tests are written using [JUnit5](https://junit.org/junit5/). >> >> Should we mention about JUnit5 under **Test your changes** ([here](https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/CONTRIBUTING.md?plain=1#L66)), where we mention that a fix should have associated tests? > > (if possible) ? minor: maybe move L232 before L231? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1828#discussion_r2150317254 From mfox at openjdk.org Mon Jun 16 16:00:59 2025 From: mfox at openjdk.org (Martin Fox) Date: Mon, 16 Jun 2025 16:00:59 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline In-Reply-To: References: Message-ID: <3kas-_2sLVoXg1Mz5j57auwRgghF6WWb3kXSRgSOajM=.636a07f8-b464-40bc-b33d-12234e3e6e63@github.com> On Thu, 12 Jun 2025 05:41:23 GMT, Ambarish Rapte wrote: > ### Description > This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS. > We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated. > Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing `-Dprism.order=mtl`) > The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use. > > ### Details about the changes > > **Shader changes** > - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl) > - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl > > **Build changes** - There are new tasks added to build.gradle for > - Generation/ Compilation/ linking of Metal shaders > - Compilation of Prism Java and Objective C files > > **Prism** - Prism is the rendering engine of JavaFX. > - Added Metal specific Java classes and respective native implementation which use Metal APIs > - Java side changes: > - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl > - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. > - Native side changes: > - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl > > **Glass** - Glass is the windowing toolkit of JavaFX > - Existing Glass classes are refactored to support both OpenGL and Metal pipelines > - Added Metal specific Glass implementation. > > ### Testing > - Testing performed on different hardware and macOS versions. > - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4) > - macOS versions - macOS 13, macOS 14 and macOS 15 > - Functional Testing: > - All headful tests pass with Metal pipeline. > - Verified samples applications: Ensemble and toys > - Performance Testing: > - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed) > > ### Note to reviewers : > - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline > - It would be a good idea to test both OpenGL and Metal pipelines > - Known issues and tasks ... Metal is here! Yes! It took me a while to sort out how the GlassView and GlassLayer classes work in this PR. It?s not clear based on the naming that the classes which handle drawing (GlassViewCGL3D and GlassViewMTL3D ) are not subclasses of the class that handles events (GlassView3D). The naming conventions could be clearer or at the very least there should be some comments in the code. I think some of this structure is being dictated by the way GlassViewCGL3D is derived from NSOpenGLView since that prevents us from making it a subclass of, say, GlassView3D. But I?m almost certain the NSOpenGLView reference is just cruft. All of the OpenGL processing happens in a CAOpenGLLayer which has nothing to do with the (unused) NSOpenGLView machinery. In the current master and this PR I can derive from NSView instead of NSOpenGLView and everything works fine. There is some code in Prism (MacOSXWindowSystemInterface.m) that can associate an NSOpenGLContext with an NSView but I don?t think a view is ever passed in. It would be nice to clean that code up since the view-related calls are deprecated and generating compiler warnings. I think the NSOpenGLView reference should be removed. Beyond that you could keep the current class structure and view layout since there?s something to be said for separating drawing and event processing into different NSViews. I would rather not see the 3D terminology carried over into the new classes. It's there to make a distinction that's no longer relevant (according to the comments there used to be a GlassView2D). But that is a personal pet peeve so feel free to ignore it. Look like it?s not possible to add comments to unchanged code in GitHub (?!) so I guess I have to write the following issues up here. In GlassWindow.m line 807 there?s this bit of mysterious code: CALayer *layer = [window->view layer]; if (([layer isKindOfClass:[CAOpenGLLayer class]] == YES) && (([window->nsWindow styleMask] & NSWindowStyleMaskTexturedBackground) == NO)) { [((CAOpenGLLayer*)layer) setOpaque:[window->nsWindow isOpaque]]; } It was put there to resolve [JDK-8095004](https://bugs.openjdk.org/browse/JDK-8095004) and [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040). In this PR the layer is nil at this point so this code isn?t doing anything. I haven?t verified whether this is causing a regression. In the master branch that setOpaque: call will always happen since the NSWindowStyleMaskTexturedBackground bit is never set (it?s associated with the obsolete UNIFIED stage style). Over in GlassView.m there?s a JNI method called _getNativeLayer that retrieves a CALayer. There?s no need to update this logic since the Java side is never called (it?s in MacView.java). This should all just be removed. ------------- PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-2932698156 From mhanl at openjdk.org Mon Jun 16 16:13:36 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 16 Jun 2025 16:13:36 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests In-Reply-To: References: Message-ID: <-nGWNkuP1f0Zf0jbTksobDv2HIxzmqlmZhJTWirwvjU=.c5971cc8-e723-43fb-a4c7-46a2f4a97658@github.com> On Mon, 16 Jun 2025 15:38:56 GMT, Andy Goryachev wrote: >> (if possible) ? > > minor: maybe move L232 before L231? > Should we mention about JUnit5 under **Test your changes** ([here](https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/CONTRIBUTING.md?plain=1#L66)), where we mention that a fix should have associated tests? I like that idea as well! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1828#discussion_r2150378738 From kcr at openjdk.org Mon Jun 16 16:39:33 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Jun 2025 16:39:33 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show In-Reply-To: References: Message-ID: On Tue, 13 May 2025 09:10:27 GMT, Lukasz Kostyra wrote: > Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`. > > The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference: > - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions > - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself. > - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case. > - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met. > > As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it. > > While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`. > > In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am... The test looks good and runs as expected on my Windows 11 system. I left two related questions about the delivery of the event. If the key press event might not be delivered synchronously from the robot key press call, then the test could fail spuriously. You might consider a couple changes to make the test more robust. tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 56: > 54: static final double STAGE_Y = 100; > 55: > 56: static boolean receivedEvent = false; Should this be volatile? It is set on one thread and read from another; unless you know that this is synchronously set by the robot key press call, I don't think you can be sure that the write `happens-before` the read. tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 113: > 111: robot.keyPress(KeyCode.A); > 112: }); > 113: assertTrue(receivedEvent, "Expected key press has NOT been received! Stage did not have focus after showing. Some tests might fail because of this." + Do you need to sleep before the assertion to ensure that the event has been delivered? ------------- PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-2932768315 PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2150403779 PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2150401174 From kizune at openjdk.org Mon Jun 16 17:06:37 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 16 Jun 2025 17:06:37 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: On Mon, 16 Jun 2025 05:30:53 GMT, Ambarish Rapte wrote: > > Noticed that when the buttons show pages 11-20, the focus is on button 13, it announces "you are currently on selected page, group, 3 of 10" > > This is observed on windows too. Seems like an existing issue, may be we should report an issue and address separately. And that's why i think it warrants a separate bug to work on - i do not want to break something cross-platform by implementing a mac-specific feature. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1823#issuecomment-2977380790 From kizune at openjdk.org Mon Jun 16 17:06:38 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 16 Jun 2025 17:06:38 GMT Subject: RFR: 8359257: Create accessibility protocol for TabGroup component [v3] In-Reply-To: References: <1RZE2YVUMDRPZpiU0bMqADIzOaZkkwA8l_3HFOQo5X4=.bd1be2b6-eab1-40ad-a161-86b93d1fcb9c@github.com> Message-ID: On Mon, 16 Jun 2025 05:52:53 GMT, Ambarish Rapte wrote: > May be can change these methods to have a helper method. I will probably do this refactoring in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1823#discussion_r2150468463 From kizune at openjdk.org Mon Jun 16 17:06:39 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 16 Jun 2025 17:06:39 GMT Subject: Integrated: 8359257: Create accessibility protocol for TabGroup component In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 21:13:12 GMT, Alexander Zuev wrote: > Create implementation of the TabGroup protocol and assign it to TAB_PANE and PAGINATION roles. This pull request has now been integrated. Changeset: 48282b10 Author: Alexander Zuev URL: https://git.openjdk.org/jfx/commit/48282b1067e37092916a9f7f0edafa66a43cfb5a Stats: 125 lines in 3 files changed: 124 ins; 0 del; 1 mod 8359257: Create accessibility protocol for TabGroup component Reviewed-by: arapte, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1823 From angorya at openjdk.org Mon Jun 16 17:43:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Jun 2025 17:43:37 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 16:24:40 GMT, Kevin Rushforth wrote: >> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`. >> >> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference: >> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions >> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself. >> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case. >> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met. >> >> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it. >> >> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`. >> >> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing... > > tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 56: > >> 54: static final double STAGE_Y = 100; >> 55: >> 56: static boolean receivedEvent = false; > > Should this be volatile? It is set on one thread and read from another; unless you know that this is synchronously set by the robot key press call, I don't think you can be sure that the write `happens-before` the read. or better an `AtomicBoolean` > tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 113: > >> 111: robot.keyPress(KeyCode.A); >> 112: }); >> 113: assertTrue(receivedEvent, "Expected key press has NOT been received! Stage did not have focus after showing. Some tests might fail because of this." + > > Do you need to sleep before the assertion to ensure that the event has been delivered? Perhaps we ought to have a utility (latch?) to ensure the sequence? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2150522663 PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2150522303 From angorya at openjdk.org Mon Jun 16 17:48:33 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Jun 2025 17:48:33 GMT Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a temporary Stage In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 13:56:05 GMT, Marius Hanl wrote: > Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls. > > It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise. > > Take the following test code: > > VirtualFlowTestUtils.clickOnRow(tableView, 2); > VirtualFlowTestUtils.clickOnRow(tableView, 4); > > > What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after. > > This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic. > > So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods. > > For the example above, this would result in: > > stageLoader = new StageLoader(tableView); > VirtualFlowTestUtils.clickOnRow(tableView, 2); > VirtualFlowTestUtils.clickOnRow(tableView, 4); > > > The stageLoader should be disposed in an @AfterEach. > > Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty. > Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly. It's a trivial change, but I wonder if 2 reviewers are needed. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java line 349: > 347: flow = (VirtualFlow)control.lookup("#virtual-flow"); > 348: > 349: if (sl != null) { should we have a check here with a helpful message (which recommends to use `StageLoader`), instead of returning `null`? ------------- PR Review: https://git.openjdk.org/jfx/pull/1829#pullrequestreview-2932969739 PR Review Comment: https://git.openjdk.org/jfx/pull/1829#discussion_r2150529464 From tsayao at openjdk.org Mon Jun 16 18:11:48 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 16 Jun 2025 18:11:48 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v33] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... 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 38 commits: - - Merge JavaFX controls on the title bar - Rename test methods - Merge branch 'master' into 8354943 # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp # modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h # modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp # modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h - Merge branch 'master' into 8354943 - - Fix for when extents are received while fullscreen or maximized - - Do not allow child stages to be fullscreen + tests - Minor adjustments - - Remove testWindowShowOrder because it fails due to the Window Manager ignoring too often focus requests - - Adjust includes - Remove work-around to allow unresizable Stages to be resized - Other minor adjustments - Merge branch 'master' into 8354943 - Fix typo - Improve StageOwnershipTest - ... and 28 more: https://git.openjdk.org/jfx/compare/fd30c948...4c2a368a ------------- Changes: https://git.openjdk.org/jfx/pull/1789/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=32 Stats: 4131 lines in 29 files changed: 2742 ins; 771 del; 618 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 duke at openjdk.org Mon Jun 16 23:11:34 2025 From: duke at openjdk.org (Cormac Redmond) Date: Mon, 16 Jun 2025 23:11:34 GMT Subject: RFR: 8359601: Fix window button states of an extended stage In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 20:01:11 GMT, Michael Strau? wrote: > The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: > > #### Windows 11 > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | visible, disabled | visible | > | resizable, modal | visible, disabled | visible | visible | > | not resizable, modal | hidden | hidden | visible, utility-style | > > #### Ubuntu 24 / Fedora 41 (GNOME) > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | hidden | visible | > | resizable, modal | visible, _not working_ | visible, _not working_ | visible | > | not resizable, modal | visible, _not working_ | hidden | visible | > > #### Kubuntu 24 (KDE) > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | hidden | visible | > | resizable, modal | visible, _not working_ | visible | visible | > | not resizable, modal | visible, _not working_ | hidden | visible | > > ## Observations > > 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. > * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) > 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. > * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) > > ## Permitted window button operations > > Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | yes | yes | yes | > | not resizable, not modal | yes | no | yes | > | resizable, modal | no | yes | yes | > | not resizable, modal | no | no | yes | > > ## Fixes > > This PR includes the following changes: > 1. Unused code relating to window modality is removed. > 2. The disabled states of `HeaderButtonOverlay` as well as `HeaderButtonBehavior` are changed to mat... Most of this seems to be working well! But I have found a likely bug. Hopefully fairly self-explanatory from the code. Minimise icon is normally disabled, but still enabled when EXTENDED is used & when dialog is resizable. Just flip comment on `dialog.initStyle(StageStyle.EXTENDED)` to see difference. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ButtonType; import javafx.scene.control.Dialog; import javafx.scene.layout.StackPane; import javafx.stage.Modality; import javafx.stage.Stage; import javafx.stage.StageStyle; public class MinimiseIconEnabledBug extends Application { @Override public void start(Stage primaryStage) { Button button = new Button("Click"); button.setOnAction(e -> { final Dialog dialog = new Dialog<>(); dialog.initOwner(primaryStage); // Existing behaviour: minimise icon disabled when commented // Possible "bug": Minimise icon enabled when uncommented // dialog.initStyle(StageStyle.EXTENDED); dialog.initModality(Modality.NONE); dialog.setResizable(true); // This is important dialog.setTitle("My Dialog"); dialog.setContentText("Lorem ipsum dolor sit amet, consectetur adipiscing..."); dialog.getDialogPane().getButtonTypes().addAll(ButtonType.OK); dialog.show(); }); StackPane root = new StackPane(button); Scene scene = new Scene(root, 300, 200); primaryStage.setTitle("My First JavaFX App"); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2978439674 From arapte at openjdk.org Tue Jun 17 00:13:50 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 17 Jun 2025 00:13:50 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 Message-ID: Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 No changes to gradle build script were needed for this upgrade. ------------- Commit messages: - javadoc 24 sha256 - chmod 644 gradlew - result of sh gradlew wrapper --gradle-version 8.14.2 - manual changes Changes: https://git.openjdk.org/jfx/pull/1832/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1832&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358802 Stats: 28 lines in 7 files changed: 0 ins; 1 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1832.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1832/head:pull/1832 PR: https://git.openjdk.org/jfx/pull/1832 From mstrauss at openjdk.org Tue Jun 17 00:23:48 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 17 Jun 2025 00:23:48 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v2] In-Reply-To: References: Message-ID: > The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: > > #### Windows 11 > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | visible, disabled | visible | > | resizable, modal | visible, disabled | visible | visible | > | not resizable, modal | hidden | hidden | visible, utility-style | > > #### Ubuntu 24 / Fedora 41 (GNOME) > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | hidden | visible | > | resizable, modal | visible, _not working_ | visible, _not working_ | visible | > | not resizable, modal | visible, _not working_ | hidden | visible | > > #### Kubuntu 24 (KDE) > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | hidden | visible | > | resizable, modal | visible, _not working_ | visible | visible | > | not resizable, modal | visible, _not working_ | hidden | visible | > > ## Observations > > 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. > * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) > 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. > * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) > > ## Permitted window button operations > > Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | yes | yes | yes | > | not resizable, not modal | yes | no | yes | > | resizable, modal | no | yes | yes | > | not resizable, modal | no | no | yes | > > ## Fixes > > This PR includes the following changes: > 1. Unused code relating to window modality is removed. > 2. The disabled states of `HeaderButtonOverlay` as well as `HeaderButtonBehavior` are changed to mat... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Handle non-modal owned window correctly ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1831/files - new: https://git.openjdk.org/jfx/pull/1831/files/b3d7ae62..06a0a5bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1831&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1831&range=00-01 Stats: 60 lines in 4 files changed: 42 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/1831.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1831/head:pull/1831 PR: https://git.openjdk.org/jfx/pull/1831 From mstrauss at openjdk.org Tue Jun 17 00:41:54 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 17 Jun 2025 00:41:54 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v3] In-Reply-To: References: Message-ID: > The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: > > #### Windows 11 > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | visible, disabled | visible | > | resizable, modal | visible, disabled | visible | visible | > | not resizable, modal | hidden | hidden | visible, utility-style | > > #### Ubuntu 24 / Fedora 41 (GNOME) > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | hidden | visible | > | resizable, modal | visible, _not working_ | visible, _not working_ | visible | > | not resizable, modal | visible, _not working_ | hidden | visible | > > #### Kubuntu 24 (KDE) > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | visible | visible | visible | > | not resizable, not modal | visible | hidden | visible | > | resizable, modal | visible, _not working_ | visible | visible | > | not resizable, modal | visible, _not working_ | hidden | visible | > > ## Observations > > 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. > * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) > 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. > * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) > > ## Permitted window button operations > > Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: > > | Window attributes | Iconify | Maximize | Close | > |---|---|---|---| > | resizable, not modal | yes | yes | yes | > | not resizable, not modal | yes | no | yes | > | resizable, modal | no | yes | yes | > | not resizable, modal | no | no | yes | > > ## Fixes > > This PR includes the following changes: > 1. Unused code relating to window modality is removed. > 2. The disabled states of `HeaderButtonOverlay` as well as `HeaderButtonBehavior` are changed to mat... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: small refactor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1831/files - new: https://git.openjdk.org/jfx/pull/1831/files/06a0a5bb..ef05139e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1831&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1831&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1831.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1831/head:pull/1831 PR: https://git.openjdk.org/jfx/pull/1831 From duke at openjdk.org Tue Jun 17 00:41:54 2025 From: duke at openjdk.org (Cormac Redmond) Date: Tue, 17 Jun 2025 00:41:54 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:23:48 GMT, Michael Strau? wrote: >> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: >> >> #### Windows 11 >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | visible, disabled | visible | >> | resizable, modal | visible, disabled | visible | visible | >> | not resizable, modal | hidden | hidden | visible, utility-style | >> >> #### Ubuntu 24 / Fedora 41 (GNOME) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible, _not working_ | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> #### Kubuntu 24 (KDE) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> ## Observations >> >> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. >> * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) >> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. >> * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) >> >> ## Permitted window button operations >> >> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | yes | yes | yes | >> | not resizable, not modal | yes | no | yes | >> | resizable, modal | no | yes | yes | >> | not resizable, modal | no | no | yes | >> >> ## Fixes >> >> This PR includes the following changes: >> 1. Unused code relating to window modality is removed... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Handle non-modal owned window correctly Another suspected issue (not really related to this PR), close request handlers are not called when using EXTENDED. E.g.: stage.setOnCloseRequest(event -> { System.out.println("Never called...");; }); Same for dialogs... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2978564173 From mstrauss at openjdk.org Tue Jun 17 00:41:54 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 17 Jun 2025 00:41:54 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:23:48 GMT, Michael Strau? wrote: >> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: >> >> #### Windows 11 >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | visible, disabled | visible | >> | resizable, modal | visible, disabled | visible | visible | >> | not resizable, modal | hidden | hidden | visible, utility-style | >> >> #### Ubuntu 24 / Fedora 41 (GNOME) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible, _not working_ | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> #### Kubuntu 24 (KDE) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> ## Observations >> >> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. >> * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) >> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. >> * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) >> >> ## Permitted window button operations >> >> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | yes | yes | yes | >> | not resizable, not modal | yes | no | yes | >> | resizable, modal | no | yes | yes | >> | not resizable, modal | no | no | yes | >> >> ## Fixes >> >> This PR includes the following changes: >> 1. Unused code relating to window modality is removed... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Handle non-modal owned window correctly Good catch, a non-modal owned window also can't be iconified. I've added code and tests for this scenario. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2978566477 From duke at openjdk.org Tue Jun 17 00:46:32 2025 From: duke at openjdk.org (Cormac Redmond) Date: Tue, 17 Jun 2025 00:46:32 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:37:22 GMT, Cormac Redmond wrote: > Another suspected issue (not really related to this PR), close request handlers are not called when using EXTENDED. E.g.: > > ``` > stage.setOnCloseRequest(event -> { > System.out.println("Never called...");; > }); > ``` > > Same for dialogs... Sample: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ButtonType; import javafx.scene.control.Dialog; import javafx.scene.layout.StackPane; import javafx.stage.Modality; import javafx.stage.Stage; import javafx.stage.StageStyle; public class MinimiseIconEnabledBug extends Application { @Override public void start(Stage primaryStage) { Button button = new Button("Click"); button.setOnAction(e -> { final Dialog dialog = new Dialog<>(); dialog.initOwner(primaryStage); // dialog.initStyle(StageStyle.EXTENDED); // uncomment for bug dialog.initModality(Modality.NONE); dialog.setResizable(true); // This is important dialog.getDialogPane().getButtonTypes().addAll(ButtonType.OK); dialog.setOnCloseRequest(dialogEvent -> { System.out.println("Close the dialog pane. This is not called when EXTENDED is used."); }); dialog.show(); }); StackPane root = new StackPane(button); Scene scene = new Scene(root, 300, 200); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2978574395 From mstrauss at openjdk.org Tue Jun 17 00:56:31 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 17 Jun 2025 00:56:31 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v3] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:41:54 GMT, Michael Strau? wrote: >> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: >> >> #### Windows 11 >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | visible, disabled | visible | >> | resizable, modal | visible, disabled | visible | visible | >> | not resizable, modal | hidden | hidden | visible, utility-style | >> >> #### Ubuntu 24 / Fedora 41 (GNOME) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible, _not working_ | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> #### Kubuntu 24 (KDE) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> ## Observations >> >> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. >> * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) >> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. >> * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) >> >> ## Permitted window button operations >> >> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | yes | yes | yes | >> | not resizable, not modal | yes | no | yes | >> | resizable, modal | no | yes | yes | >> | not resizable, modal | no | no | yes | >> >> ## Fixes >> >> This PR includes the following changes: >> 1. Unused code relating to window modality is removed... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small refactor I've filed another ticket for that: [JDK-8359763](https://bugs.openjdk.org/browse/JDK-8359763). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2978589007 From duke at openjdk.org Tue Jun 17 01:14:33 2025 From: duke at openjdk.org (Cormac Redmond) Date: Tue, 17 Jun 2025 01:14:33 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:38:31 GMT, Michael Strau? wrote: > Good catch, a non-modal owned window also can't be iconified. I've added code and tests for this scenario. Looks good, can't find anymore issues... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2978613337 From jvos at openjdk.org Tue Jun 17 07:34:34 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 17 Jun 2025 07:34:34 GMT Subject: RFR: 8359599: Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl wrote: > When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them. > > This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`. > > This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called. > > The contract of `refresh()` is also a big vague, stating: > > Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells > necessary to populate the visual bounds of the control. > In other words, this forces the XXX to update what it is showing to the user. > This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself. > > > As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved). It is indeed true that refresh() is often a very expensive operation. Whenever `VirtualFlow.recreateCells()` is called, most of the internal state of the VirtualFlow is destroyed, and everything is recalculated from scratch. I believe that is not a problem, as long as recreateCells() is not called (by the controls) unless really needed. In that light, this PR seems interesting, as it will limit the number of rebuild-from-scratch cases. I ran the basic controls tests after applying the PR, and (a bit to my surprise) they all passed, which is great. However, it is very likely that some code out there implicitly rely on the rebuild-from-scratch logic, and that code will then work different after applying this PR. I believe it would be good to find such a case where the behavior (which, I agree, is often a bit vaguely defined) changes, so that we can discuss this with a concrete example. Hence, while I like the idea here (avoiding unneeded heavy-cost operations in VirtualFlow), I would like to avoid a number of follow-up issues once this is merged -- driven by a change in "expected" behavior. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-2979258772 From jvos at openjdk.org Tue Jun 17 08:06:37 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 17 Jun 2025 08:06:37 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v2] In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 21:12:45 GMT, Thiago Milczarek Sayao wrote: >> Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. >> >> JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. >> >> GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. >> >> Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 >> >> Major Linux distributions already provide GTK 3.20 or newer: >> - Ubuntu LTS 18.04+ (ships GTK 3.22+) >> - Debian 9+ (ships GTK 3.22+) >> - Fedora 24+ (ships GTK 3.20+) >> - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add Comment about gtk 3 Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1825#pullrequestreview-2934570060 From sykora at openjdk.org Tue Jun 17 08:09:39 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Tue, 17 Jun 2025 08:09:39 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v2] In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 21:12:45 GMT, Thiago Milczarek Sayao wrote: >> Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. >> >> JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. >> >> GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. >> >> Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 >> >> Major Linux distributions already provide GTK 3.20 or newer: >> - Ubuntu LTS 18.04+ (ships GTK 3.22+) >> - Debian 9+ (ships GTK 3.22+) >> - Fedora 24+ (ships GTK 3.20+) >> - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add Comment about gtk 3 I did a sanity test on our build infrastructure and we didn't run into issues. So all is looking good for me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1825#issuecomment-2979356601 From jvos at openjdk.org Tue Jun 17 08:17:08 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 17 Jun 2025 08:17:08 GMT Subject: [jfx21u] RFR: 8351038: ConcurrentModificationException in EventType constructor Message-ID: Hi all, This pull request contains an almost-clean backport of commit 0e509616 from the openjdk/jfx repository. Only the (c) date had to be manually modified. The commit being backported was authored by Andy Goryachev on 19 Mar 2025 and was reviewed by Ambarish Rapte and Michael Strau?. Thanks! ------------- Commit messages: - Backport 0e50961631ebaa2ac2fc5132f0e4c8c3efa72d3d Changes: https://git.openjdk.org/jfx21u/pull/100/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351038 Stats: 83 lines in 2 files changed: 64 ins; 13 del; 6 mod Patch: https://git.openjdk.org/jfx21u/pull/100.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/100/head:pull/100 PR: https://git.openjdk.org/jfx21u/pull/100 From jpereda at openjdk.org Tue Jun 17 08:33:40 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 17 Jun 2025 08:33:40 GMT Subject: [jfx21u] RFR: 8351038: ConcurrentModificationException in EventType constructor In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 08:11:51 GMT, Johan Vos wrote: > Hi all, > > This pull request contains an almost-clean backport of commit 0e509616 from the openjdk/jfx repository. Only the (c) date had to be manually modified. > > The commit being backported was authored by Andy Goryachev on 19 Mar 2025 and was reviewed by Ambarish Rapte and Michael Strau?. > > Thanks! Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/100#pullrequestreview-2934682148 From jvos at openjdk.org Tue Jun 17 08:42:39 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 17 Jun 2025 08:42:39 GMT Subject: [jfx21u] Integrated: 8351038: ConcurrentModificationException in EventType constructor In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 08:11:51 GMT, Johan Vos wrote: > Hi all, > > This pull request contains an almost-clean backport of commit 0e509616 from the openjdk/jfx repository. Only the (c) date had to be manually modified. > > The commit being backported was authored by Andy Goryachev on 19 Mar 2025 and was reviewed by Ambarish Rapte and Michael Strau?. > > Thanks! This pull request has now been integrated. Changeset: 3bbff129 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/3bbff12986916db4f9416853012a298f690ba43b Stats: 83 lines in 2 files changed: 64 ins; 13 del; 6 mod 8351038: ConcurrentModificationException in EventType constructor Reviewed-by: jpereda Backport-of: 0e50961631ebaa2ac2fc5132f0e4c8c3efa72d3d ------------- PR: https://git.openjdk.org/jfx21u/pull/100 From jhendrikx at openjdk.org Tue Jun 17 08:44:52 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 17 Jun 2025 08:44:52 GMT Subject: RFR: 8351867: No UI changes while iconified [v2] In-Reply-To: References: Message-ID: > Adds code to trigger a scene update when a Window is restored > > This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479 John Hendrikx 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 'openjdk:master' into feature/minimize-issue - Ensure a redraw is performed after windows is restored ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1733/files - new: https://git.openjdk.org/jfx/pull/1733/files/f43bbff1..df83df1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=00-01 Stats: 148937 lines in 832 files changed: 47572 ins; 57104 del; 44261 mod Patch: https://git.openjdk.org/jfx/pull/1733.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1733/head:pull/1733 PR: https://git.openjdk.org/jfx/pull/1733 From tsayao at openjdk.org Tue Jun 17 13:19:52 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 17 Jun 2025 13:19:52 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v34] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Rollback unnecessary changes - Fix mistakes when merging ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/4c2a368a..08aa16f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=33 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=32-33 Stats: 108 lines in 5 files changed: 35 ins; 18 del; 55 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 tsayao at openjdk.org Tue Jun 17 13:47:01 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 17 Jun 2025 13:47:01 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v35] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Fix motion request ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/08aa16f3..227b3a71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=34 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=33-34 Stats: 5 lines in 2 files changed: 1 ins; 3 del; 1 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 mfox at openjdk.org Tue Jun 17 14:44:35 2025 From: mfox at openjdk.org (Martin Fox) Date: Tue, 17 Jun 2025 14:44:35 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show In-Reply-To: References: Message-ID: On Tue, 13 May 2025 09:10:27 GMT, Lukasz Kostyra wrote: > Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`. > > The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference: > - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions > - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself. > - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case. > - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met. > > As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it. > > While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`. > > In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am... tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 110: > 108: public void testStageHasFocusAfterShow() { > 109: Util.sleep(250); > 110: Util.runAndWait(() -> { If the stage isn't focused after the sleep the robot's key press might go to some other app entirely. You might want to add an assert after the sleep checking that stage.isFocused() returns true. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2152459654 From mfox at openjdk.org Tue Jun 17 14:48:36 2025 From: mfox at openjdk.org (Martin Fox) Date: Tue, 17 Jun 2025 14:48:36 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 17:39:35 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 113: >> >>> 111: robot.keyPress(KeyCode.A); >>> 112: }); >>> 113: assertTrue(receivedEvent, "Expected key press has NOT been received! Stage did not have focus after showing. Some tests might fail because of this." + >> >> Do you need to sleep before the assertion to ensure that the event has been delivered? > > Perhaps we ought to have a utility (latch?) to ensure the sequence? A delay of some sort is necessary to give the event loop time to process the event. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2152468920 From angorya at openjdk.org Tue Jun 17 14:51:44 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Jun 2025 14:51:44 GMT Subject: Integrated: 8341670: [Text,TextFlow] Public API for Text Layout Info In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Tue, 8 Oct 2024 16:07:54 GMT, Andy Goryachev wrote: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 25 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > > > ## WARNINGS > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/RichTextFX/pull/1246 This pull request has now been integrated. Changeset: 1ea980ea Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/1ea980ea6104ce39994fee0fcbaa460888a2747e Stats: 1574 lines in 13 files changed: 1478 ins; 52 del; 44 mod 8341670: [Text,TextFlow] Public API for Text Layout Info Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1596 From angorya at openjdk.org Tue Jun 17 14:56:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Jun 2025 14:56:50 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v34] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Wed, 11 Jun 2025 19:17:24 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 25 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> >> >> ## WARNINGS >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557 >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Thank you all for reviewing this PR! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2980705186 From kcr at openjdk.org Tue Jun 17 15:08:34 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 15:08:34 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v2] In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 21:12:45 GMT, Thiago Milczarek Sayao wrote: >> Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. >> >> JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. >> >> GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. >> >> Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 >> >> Major Linux distributions already provide GTK 3.20 or newer: >> - Ubuntu LTS 18.04+ (ships GTK 3.22+) >> - Debian 9+ (ships GTK 3.22+) >> - Fedora 24+ (ships GTK 3.20+) >> - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add Comment about gtk 3 Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1825#pullrequestreview-2936064667 From kcr at openjdk.org Tue Jun 17 15:20:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 15:20:35 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 14:46:08 GMT, Martin Fox wrote: >> Perhaps we ought to have a utility (latch?) to ensure the sequence? > > A delay of some sort is necessary to give the event loop time to process the event. Right. I think Andy was suggesting a latch (with a timeout) that would be triggered (counted down to 0) when the event was received. This would also remove the concern I raised about the flag not being volatile. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2152546804 From kevin.rushforth at oracle.com Tue Jun 17 15:46:28 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Jun 2025 08:46:28 -0700 Subject: Proposal: Bump minimum JDK for JavaFX 25 to JDK 23 (more generally, set min for JavaFX N to JDK N-2) Message-ID: <16ff41d0-c594-4b77-82f8-6b1830d15c63@oracle.com> All, Even though we build JavaFX 25 binaries with JDK 23 (which is being updated to JDK 24 this week), as the boot JDK, the latest version of JavaFX still runs with JDK 22, although it isn't tested with older JDK versions. In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. I propose to bump the minimum version of the JDK needed to run JavaFX 25 to JDK 23. I further propose to adopt a standard practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N; we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. I filed JDK-8359387 [1] to track this and prepared PR #1827 [2]. This will *not* affect update releases of earlier versions of JavaFX (e.g., JavaFX 24.0.NN or JavaFX 21.0.NN), which will continue to run with the same minimum JDK that they run on today. Note: in keeping with the "tip and tail" model [3], developers who want to run their application on an LTS of the JDK should also get a corresponding LTS of JavaFX. Comments are welcome. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8359387 [2] https://github.com/openjdk/jfx/pull/1827 [3] https://openjdk.org/jeps/14 From kcr at openjdk.org Tue Jun 17 15:51:12 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 15:51:12 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 Message-ID: This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23 - set gradle version min to 8.10.2 - 8359387: Bump minimum JDK version for JavaFX to JDK 23 Changes: https://git.openjdk.org/jfx/pull/1827/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1827&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359387 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1827.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1827/head:pull/1827 PR: https://git.openjdk.org/jfx/pull/1827 From kcr at openjdk.org Tue Jun 17 15:51:12 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 15:51:12 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. > > This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. Reviewers: @arapte @johanvos @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1827#issuecomment-2980901553 From arapte at openjdk.org Tue Jun 17 15:51:13 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 17 Jun 2025 15:51:13 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 In-Reply-To: References: Message-ID: <7RTAZXvz5ahwY22zyvZGWdZ3_FLYmbeP0HT-plQrp_I=.826bca95-8acd-4840-b21d-60e2add4f9bb@github.com> On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. > > This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. build.properties line 95: > 93: jfx.build.jdk.version.min=23 > 94: jfx.build.jdk.buildnum.min=37 > 95: jfx.jdk.target.version=23 gradle 8.5 does not support JDK23 so jfx.gradle.version.min should be updated to 8.10.2 ref: https://docs.gradle.org/8.10.2/release-notes.html ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1827#discussion_r2149619555 From kcr at openjdk.org Tue Jun 17 15:51:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 15:51:13 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 In-Reply-To: <7RTAZXvz5ahwY22zyvZGWdZ3_FLYmbeP0HT-plQrp_I=.826bca95-8acd-4840-b21d-60e2add4f9bb@github.com> References: <7RTAZXvz5ahwY22zyvZGWdZ3_FLYmbeP0HT-plQrp_I=.826bca95-8acd-4840-b21d-60e2add4f9bb@github.com> Message-ID: <_4ZwdqkOEHHESzUEgG42Wgz1Acw2F3g_vmZFw7VBFm8=.c0626644-c5ae-4d8b-a307-82304275b152@github.com> On Mon, 16 Jun 2025 10:33:19 GMT, Ambarish Rapte wrote: >> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. >> >> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. >> >> This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. >> >> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. > > build.properties line 95: > >> 93: jfx.build.jdk.version.min=23 >> 94: jfx.build.jdk.buildnum.min=37 >> 95: jfx.jdk.target.version=23 > > gradle 8.5 does not support JDK23 so jfx.gradle.version.min should be updated to 8.10.2 > ref: https://docs.gradle.org/8.10.2/release-notes.html fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1827#discussion_r2152601153 From angorya at openjdk.org Tue Jun 17 16:04:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Jun 2025 16:04:51 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: References: Message-ID: > # Tab Stop Policy > > Andy Goryachev > > > > > ## Summary > > Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize` > value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text > segments font [0]. > > ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40) > > > ## Goals > > The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text. > > > > ## Non-Goals > > The following are not the goals of this proposal: > > - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment` > - support the `leader` property (symbols to fill the empty space before the tab stop) > - support for `firstLineIndent` property > - deprecate the `TextFlow::tabsize` property > > > > ## Motivation > > The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content > contains text with different font sizes. > > In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided > in RTF or MS Word documents. > > > > > ## Description > > ### TextFlow > > > /** > * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. > *

    > * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)}, > * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within > * this {@code TextFlow}. > * > * @defaultValue null > * > * @since 999 TODO > */ > public final ObjectProperty tabStopPolicyProperty() { > > public final TabStopPolicy getTabStopPolicy() { > > public final void setTabStopPolicy(TabStopPolicy policy) { > > /** > * The size of a tab stop in spaces. > * Values less than 1 are treated as 1. This value overrides the > * {@code tabSize} of contained {@link Text} nodes. > *

    > + * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes > + * with different fonts are contained within this {@code TextFlow}. > + * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead. > * > * @defaultValue 8 > * > * @since 14 > */ > public final IntegerProperty tabSizeProperty() { > > > > ### TabStopPolicy > > > /** > * The TabStopPolicy determines the tab stop pos... Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops - cleanup - api - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops - cleanup - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops - seems to work - wired - moved - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops - ... and 46 more: https://git.openjdk.org/jfx/compare/1ea980ea...7acc55db ------------- Changes: https://git.openjdk.org/jfx/pull/1744/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=01 Stats: 591 lines in 12 files changed: 561 ins; 5 del; 25 mod Patch: https://git.openjdk.org/jfx/pull/1744.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744 PR: https://git.openjdk.org/jfx/pull/1744 From angorya at openjdk.org Tue Jun 17 16:10:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Jun 2025 16:10:16 GMT Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(), rangeShape() with non-empty padding/border Message-ID: ## Summary This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality. ## Problem A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set): - caretShape - hitTest - rangeShape Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes. ## Solution The solution is two-fold: 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality. The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670 ## Testing Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages): https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected ------------- Commit messages: - cleanup - Merge branch 'master' into 8341438.text.shapes.insets - layout info - tests - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets - cleanup - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - cleanup - removed getStrikeThroughShape - ... and 59 more: https://git.openjdk.org/jfx/compare/1ea980ea...c1d7029c Changes: https://git.openjdk.org/jfx/pull/1817/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341438 Stats: 555 lines in 5 files changed: 521 ins; 18 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1817.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1817/head:pull/1817 PR: https://git.openjdk.org/jfx/pull/1817 From kcr at openjdk.org Tue Jun 17 16:11:36 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 16:11:36 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:08:33 GMT, Ambarish Rapte wrote: > Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 > No changes to gradle build script were needed for this upgrade. Reviewers: @kevinrushforth @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1832#issuecomment-2980970409 From kcr at openjdk.org Tue Jun 17 16:15:33 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 16:15:33 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:08:33 GMT, Ambarish Rapte wrote: > Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 > No changes to gradle build script were needed for this upgrade. Please merge in the latest master to get the updated gradle wrapper-validation action (since you are updating the gradle wrapper, I'd like to see a GHA run with the newer action). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1832#issuecomment-2980984470 From kcr at openjdk.org Tue Jun 17 16:45:34 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 16:45:34 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:08:33 GMT, Ambarish Rapte wrote: > Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 > No changes to gradle build script were needed for this upgrade. LGTM gradlew line 117: > 115: esac > 116: > 117: CLASSPATH="\\\"\\\"" This is from the gradle distribution? It looks odd... ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1832#pullrequestreview-2936293006 PR Review Comment: https://git.openjdk.org/jfx/pull/1832#discussion_r2152659484 From tsayao at openjdk.org Tue Jun 17 20:24:15 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 17 Jun 2025 20:24:15 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v3] In-Reply-To: References: Message-ID: <-GFR1yH561V4PWOBa2-M6f1jVyghwpYk6FS6nLeK_Cc=.45ea52c4-1cb6-4e2a-b254-35c3509cf232@github.com> > Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. > > JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. > > GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. > > Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 > > Major Linux distributions already provide GTK 3.20 or newer: > - Ubuntu LTS 18.04+ (ships GTK 3.22+) > - Debian 9+ (ships GTK 3.22+) > - Fedora 24+ (ships GTK 3.20+) > - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add comment about version ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1825/files - new: https://git.openjdk.org/jfx/pull/1825/files/ab611660..93105e0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1825&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1825&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1825.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1825/head:pull/1825 PR: https://git.openjdk.org/jfx/pull/1825 From tsayao at openjdk.org Tue Jun 17 20:24:15 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 17 Jun 2025 20:24:15 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 16:56:04 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment about version > > buildSrc/linux.gradle line 28: > >> 26: ext.LINUX = [:] >> 27: >> 28: def gtk3MinMinorVersion = "20" > > Minor: maybe add a comment saying that the minimum GTK3 version is 3.20? Added ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1825#discussion_r2153098690 From tsayao at openjdk.org Tue Jun 17 20:24:15 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 17 Jun 2025 20:24:15 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v3] In-Reply-To: References: Message-ID: <3KwHTRIM8FMtCvAbvx5OhS0YZS4_zadsUl5d9cOjMf4=.edf76b10-9285-4911-9f69-6a308a5f2e0f@github.com> On Tue, 17 Jun 2025 20:19:16 GMT, Thiago Milczarek Sayao wrote: >> buildSrc/linux.gradle line 28: >> >>> 26: ext.LINUX = [:] >>> 27: >>> 28: def gtk3MinMinorVersion = "20" >> >> Minor: maybe add a comment saying that the minimum GTK3 version is 3.20? > > Added Sorry, I read your comment earlier, but when I did it later, I remembered it wrong. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1825#discussion_r2153102030 From kcr at openjdk.org Tue Jun 17 20:59:35 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 20:59:35 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v3] In-Reply-To: <-GFR1yH561V4PWOBa2-M6f1jVyghwpYk6FS6nLeK_Cc=.45ea52c4-1cb6-4e2a-b254-35c3509cf232@github.com> References: <-GFR1yH561V4PWOBa2-M6f1jVyghwpYk6FS6nLeK_Cc=.45ea52c4-1cb6-4e2a-b254-35c3509cf232@github.com> Message-ID: On Tue, 17 Jun 2025 20:24:15 GMT, Thiago Milczarek Sayao wrote: >> Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. >> >> JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. >> >> GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. >> >> Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 >> >> Major Linux distributions already provide GTK 3.20 or newer: >> - Ubuntu LTS 18.04+ (ships GTK 3.22+) >> - Debian 9+ (ships GTK 3.22+) >> - Fedora 24+ (ships GTK 3.20+) >> - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about version Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1825#pullrequestreview-2937074442 From tsayao at openjdk.org Tue Jun 17 22:26:19 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 17 Jun 2025 22:26:19 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v36] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - - Minor adjustments - - Configure optimizations ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/227b3a71..c7e7abfc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=35 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=34-35 Stats: 65 lines in 2 files changed: 29 ins; 11 del; 25 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 arapte at openjdk.org Tue Jun 17 22:50:13 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 17 Jun 2025 22:50:13 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 [v2] In-Reply-To: References: Message-ID: <-57a8QYTYAlDLCzuj85WbxiTBogKxRh3kjZkrb9shS0=.568ad1ce-6201-4d7a-a4ef-9cc417279f35@github.com> > Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 > No changes to gradle build script were needed for this upgrade. Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into jdk24.0.1-gradle8142 - javadoc 24 sha256 - chmod 644 gradlew - result of sh gradlew wrapper --gradle-version 8.14.2 - manual changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1832/files - new: https://git.openjdk.org/jfx/pull/1832/files/5962626f..a76b2926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1832&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1832&range=00-01 Stats: 1702 lines in 18 files changed: 1602 ins; 52 del; 48 mod Patch: https://git.openjdk.org/jfx/pull/1832.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1832/head:pull/1832 PR: https://git.openjdk.org/jfx/pull/1832 From nlisker at gmail.com Tue Jun 17 22:57:14 2025 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 18 Jun 2025 01:57:14 +0300 Subject: Proposal: Bump minimum JDK for JavaFX 25 to JDK 23 (more generally, set min for JavaFX N to JDK N-2) In-Reply-To: <16ff41d0-c594-4b77-82f8-6b1830d15c63@oracle.com> References: <16ff41d0-c594-4b77-82f8-6b1830d15c63@oracle.com> Message-ID: Sounds good. Java 23 contains mostly preview features, but brings Markdown docs. https://javaalmanac.io/jdk/23/ On Tue, Jun 17, 2025, 18:46 Kevin Rushforth wrote: > All, > > Even though we build JavaFX 25 binaries with JDK 23 (which is being > updated to JDK 24 this week), as the boot JDK, the latest version of > JavaFX still runs with JDK 22, although it isn't tested with older JDK > versions. > > In order for JavaFX to be able to use more recent JDK features, we > should increase the minimum version of the JDK that can run the latest > JavaFX. Additionally, there is an ongoing cost to keeping JavaFX > buildable and runnable on older versions of Java, and little reason to > continue to do so. > > I propose to bump the minimum version of the JDK needed to run JavaFX 25 > to JDK 23. I further propose to adopt a standard practice of setting the > minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for > use with JDK N; we also build and test it against JDK N-1 (which is > typically what we use as the boot JDK). Anything older than that, > including the proposed minimum JDK N-2 (23 in this specific case), is > untested. > > I filed JDK-8359387 [1] to track this and prepared PR #1827 [2]. This > will *not* affect update releases of earlier versions of JavaFX (e.g., > JavaFX 24.0.NN or JavaFX 21.0.NN), which will continue to run with the > same minimum JDK that they run on today. > > Note: in keeping with the "tip and tail" model [3], developers who want > to run their application on an LTS of the JDK should also get a > corresponding LTS of JavaFX. > > Comments are welcome. > > -- Kevin > > [1] https://bugs.openjdk.org/browse/JDK-8359387 > [2] https://github.com/openjdk/jfx/pull/1827 > [3] https://openjdk.org/jeps/14 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jun 17 23:03:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jun 2025 23:03:37 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 16:04:51 GMT, Andy Goryachev wrote: >> # Tab Stop Policy >> >> Andy Goryachev >> >> >> >> >> ## Summary >> >> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize` >> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text >> segments font [0]. >> >> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40) >> >> >> ## Goals >> >> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text. >> >> >> >> ## Non-Goals >> >> The following are not the goals of this proposal: >> >> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment` >> - support the `leader` property (symbols to fill the empty space before the tab stop) >> - support for `firstLineIndent` property >> - deprecate the `TextFlow::tabsize` property >> >> >> >> ## Motivation >> >> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content >> contains text with different font sizes. >> >> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided >> in RTF or MS Word documents. >> >> >> >> >> ## Description >> >> ### TextFlow >> >> >> /** >> * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. >> *

    >> * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)}, >> * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within >> * this {@code TextFlow}. >> * >> * @defaultValue null >> * >> * @since 999 TODO >> */ >> public final ObjectProperty tabStopPolicyProperty() { >> >> public final TabStopPolicy getTabStopPolicy() { >> >> public final void setTabStopPolicy(TabStopPolicy policy) { >> >> /** >> * The size of a tab stop in spaces. >> * Values less than 1 are treated as 1. This value overrides the >> * {@code tabSize} of contained {@link Text} nodes. >> *

    >> + * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes >> + * with different fonts are contained within this {@code TextFlow}. >> + * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead. >> * >> * @defaultValue 8 >> *... > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: > > - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops > - cleanup > - api > - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops > - cleanup > - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops > - seems to work > - wired > - moved > - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops > - ... and 46 more: https://git.openjdk.org/jfx/compare/1ea980ea...7acc55db Initial API comments. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 35: > 33: * @since 999 TODO > 34: */ > 35: public class TabStop { Should this be a record? If not, it should at least be a final class. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 41: > 39: * Constructs a new tab stop with the specified position. > 40: * > 41: * @param position the position in pixels Is pixels the right unit here? Should it be points instead? Or should it allow for the specification of units so that you could specify it in "em"s? @prrace might want to weigh in on this. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 39: > 37: * @since 999 TODO > 38: */ > 39: public class TabStopPolicy { Is there a reason this class is not final? It probably should be. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 51: > 49: /** > 50: * Specifies the unmodifiable list of tab stops, sorted by position from smallest to largest. > 51: * The list can be changed using "changed using" ... what? More importantly, this isn't an unmodifiable list, right? (it isn't implemented that way, and it would not be very useful if it were) So you can't enforce that it is sorted. Rather this should just be an ordinary observable list, like we have in other classes, and if you need a sorted view of it, then have one internally that keeps it sorted. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 60: > 58: > 59: /** > 60: * Provides default tab stops (beyond the last tab stop specified by {@code #tabStops()}, Having this be a plural when it is a single value (a double) is awkward. I would name the property `defaultStop` and document that the default is used for all stops beyond the last stop. modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 569: > 567: > 568: /** > 569: * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. `TabAdvancePolicy` --> `TabStopPolicy` modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 613: > 611: @Override > 612: public String getName() { > 613: return "tabAdvancePolicy"; `"tabStopPolicy"` ------------- PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-2937257228 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153291538 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153291078 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153293418 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153296860 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153303020 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153281868 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2153284183 From arapte at openjdk.org Wed Jun 18 00:00:33 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Jun 2025 00:00:33 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 16:10:49 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into jdk24.0.1-gradle8142 >> - javadoc 24 sha256 >> - chmod 644 gradlew >> - result of sh gradlew wrapper --gradle-version 8.14.2 >> - manual changes > > gradlew line 117: > >> 115: esac >> 116: >> 117: CLASSPATH="\\\"\\\"" > > This is from the gradle distribution? It looks odd... Yes, it seems to be an empty string, added when this command is run: `sh gradlew wrapper --gradle-version 8.14.2`. Earlier the gradle-wrapper.jar was used in classpath, but now it is used with -jar option. so CLASSPATH is kept empty. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1832#discussion_r2153356003 From arapte at openjdk.org Wed Jun 18 02:15:36 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Jun 2025 02:15:36 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. > > This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1827#pullrequestreview-2937518116 From lkostyra at openjdk.org Wed Jun 18 06:56:42 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Jun 2025 06:56:42 GMT Subject: RFR: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk [v3] In-Reply-To: <-GFR1yH561V4PWOBa2-M6f1jVyghwpYk6FS6nLeK_Cc=.45ea52c4-1cb6-4e2a-b254-35c3509cf232@github.com> References: <-GFR1yH561V4PWOBa2-M6f1jVyghwpYk6FS6nLeK_Cc=.45ea52c4-1cb6-4e2a-b254-35c3509cf232@github.com> Message-ID: On Tue, 17 Jun 2025 20:24:15 GMT, Thiago Milczarek Sayao wrote: >> Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. >> >> JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. >> >> GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. >> >> Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 >> >> Major Linux distributions already provide GTK 3.20 or newer: >> - Ubuntu LTS 18.04+ (ships GTK 3.22+) >> - Debian 9+ (ships GTK 3.22+) >> - Fedora 24+ (ships GTK 3.20+) >> - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about version Looks good ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1825#pullrequestreview-2937950537 From lkostyra at openjdk.org Wed Jun 18 07:06:33 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Jun 2025 07:06:33 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 14:42:26 GMT, Martin Fox wrote: >> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`. >> >> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference: >> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions >> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself. >> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case. >> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met. >> >> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it. >> >> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`. >> >> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing... > > tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 110: > >> 108: public void testStageHasFocusAfterShow() { >> 109: Util.sleep(250); >> 110: Util.runAndWait(() -> { > > If the stage isn't focused after the sleep the robot's key press might go to some other app entirely. You might want to add an assert after the sleep checking that stage.isFocused() returns true. I checked this and it actually is a bug, `isFocused()` returns true in this case (when the Stage is not focused). We don't capture the failure of `SetForegroundWindow()`, so JFX assumes we are in focus. It doesn't necessarily change the outcome of the test, the key press check will then fail, but it would be good for the flag to also reflect that. I'll add the assertion and file a separate issue for that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2153809248 From jhendrikx at openjdk.org Wed Jun 18 08:21:54 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 18 Jun 2025 08:21:54 GMT Subject: RFR: 8351867: No UI changes while iconified [v3] In-Reply-To: References: Message-ID: > Adds code to trigger a scene update when a Window is restored > > This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479 John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Also call entireSceneNeedsRepaint - Add test case ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1733/files - new: https://git.openjdk.org/jfx/pull/1733/files/df83df1b..2539511b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=01-02 Stats: 126 lines in 2 files changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1733.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1733/head:pull/1733 PR: https://git.openjdk.org/jfx/pull/1733 From arapte at openjdk.org Wed Jun 18 09:09:00 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Jun 2025 09:09:00 GMT Subject: RFR: 8359896: [TestBug][JUnit5] Possible configuration error Message-ID: A simple change to remove `@Test` annotation from two graphics unit tests. The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. ------------- Commit messages: - rm @Test annotation Changes: https://git.openjdk.org/jfx/pull/1833/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359896 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1833.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1833/head:pull/1833 PR: https://git.openjdk.org/jfx/pull/1833 From jhendrikx at openjdk.org Wed Jun 18 09:22:39 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 18 Jun 2025 09:22:39 GMT Subject: RFR: 8359896: [TestBug][JUnit5] Possible configuration error In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote: > A simple change to remove `@Test` annotation from two graphics unit tests. > > The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. > > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1833#pullrequestreview-2938428945 From lkostyra at openjdk.org Wed Jun 18 10:05:19 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Jun 2025 10:05:19 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show [v2] In-Reply-To: References: Message-ID: > Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`. > > The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference: > - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions > - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself. > - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case. > - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met. > > As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it. > > While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`. > > In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am... Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Review fixes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1804/files - new: https://git.openjdk.org/jfx/pull/1804/files/542a3830..91c69833 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=00-01 Stats: 18 lines in 1 file changed: 12 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1804.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1804/head:pull/1804 PR: https://git.openjdk.org/jfx/pull/1804 From lkostyra at openjdk.org Wed Jun 18 10:05:19 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Jun 2025 10:05:19 GMT Subject: RFR: 8351357: Add canary system test checking if Stage receives focus on show [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 15:18:17 GMT, Kevin Rushforth wrote: >> A delay of some sort is necessary to give the event loop time to process the event. > > Right. I think Andy was suggesting a latch (with a timeout) that would be triggered (counted down to 0) when the event was received. This would also remove the concern I raised about the flag not being volatile. With a latch I think we don't even need the boolean value (we can simply wait for latch to trigger) so I removed it ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2154198905 From jdv at openjdk.org Wed Jun 18 10:19:32 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 18 Jun 2025 10:19:32 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline In-Reply-To: <3kas-_2sLVoXg1Mz5j57auwRgghF6WWb3kXSRgSOajM=.636a07f8-b464-40bc-b33d-12234e3e6e63@github.com> References: <3kas-_2sLVoXg1Mz5j57auwRgghF6WWb3kXSRgSOajM=.636a07f8-b464-40bc-b33d-12234e3e6e63@github.com> Message-ID: On Mon, 16 Jun 2025 15:57:31 GMT, Martin Fox wrote: >> ### Description >> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS. >> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated. >> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing `-Dprism.order=mtl`) >> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use. >> >> ### Details about the changes >> >> **Shader changes** >> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl) >> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl >> >> **Build changes** - There are new tasks added to build.gradle for >> - Generation/ Compilation/ linking of Metal shaders >> - Compilation of Prism Java and Objective C files >> >> **Prism** - Prism is the rendering engine of JavaFX. >> - Added Metal specific Java classes and respective native implementation which use Metal APIs >> - Java side changes: >> - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl >> - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. >> - Native side changes: >> - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl >> >> **Glass** - Glass is the windowing toolkit of JavaFX >> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines >> - Added Metal specific Glass implementation. >> >> ### Testing >> - Testing performed on different hardware and macOS versions. >> - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4) >> - macOS versions - macOS 13, macOS 14 and macOS 15 >> - Functional Testing: >> - All headful tests pass with Metal pipeline. >> - Verified samples applications: Ensemble and toys >> - Performance Testing: >> - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed) >> >> ### Note to reviewers : >> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline >> - It woul... > > Metal is here! Yes! > > It took me a while to sort out how the GlassView and GlassLayer classes work in this PR. It?s not clear based on the naming that the classes which handle drawing (GlassViewCGL3D and GlassViewMTL3D ) are not subclasses of the class that handles events (GlassView3D). The naming conventions could be clearer or at the very least there should be some comments in the code. > > I think some of this structure is being dictated by the way GlassViewCGL3D is derived from NSOpenGLView since that prevents us from making it a subclass of, say, GlassView3D. But I?m almost certain the NSOpenGLView reference is just cruft. All of the OpenGL processing happens in a CAOpenGLLayer which has nothing to do with the (unused) NSOpenGLView machinery. In the current master and this PR I can derive from NSView instead of NSOpenGLView and everything works fine. > > There is some code in Prism (MacOSXWindowSystemInterface.m) that can associate an NSOpenGLContext with an NSView but I don?t think a view is ever passed in. It would be nice to clean that code up since the view-related calls are deprecated and generating compiler warnings. > > I think the NSOpenGLView reference should be removed. Beyond that you could keep the current class structure and view layout since there?s something to be said for separating drawing and event processing into different NSViews. > > I would rather not see the 3D terminology carried over into the new classes. It's there to make a distinction that's no longer relevant (according to the comments there used to be a GlassView2D). But that is a personal pet peeve so feel free to ignore it. > > Look like it?s not possible to add comments to unchanged code in GitHub (?!) so I guess I have to write the following issues up here. > > In GlassWindow.m line 807 there?s this bit of mysterious code: > > > CALayer *layer = [window->view layer]; > if (([layer isKindOfClass:[CAOpenGLLayer class]] == YES) && > (([window->nsWindow styleMask] & NSWindowStyleMaskTexturedBackground) == NO)) > { > [((CAOpenGLLayer*)layer) setOpaque:[window->nsWindow isOpaque]]; > } > > > It was put there to resolve [JDK-8095004](https://bugs.openjdk.org/browse/JDK-8095004) and [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040). In this PR the layer is nil at this point so this code isn?t doing anything. I haven?t verified whether this is causing a regression. In the master branch that setOpaque: call will always happen since the NSWindowStyleMaskTexturedBackground bit is never set (it?s ass... @beldenfox Thanks for your inputs. 1. Regarding adding comments in GlassView/Layer classes about how they are not subclasses but subViews/subLayers : Sure i will go ahead and add comments in the class. Also as you mentioned we can name them better: - GlassView3D -> GlassViewEvent(Since it is common class which handles events for both OpenGL and Metal pipeline) Or GlassSubView(Since it is added as subView in GlassView). Please suggest if you have better names that we can use here. - GlassViewCGL3D -> GlassViewCGL(With comment mentioning how it is not subclass but a subView of GlassView3D) - GlassViewMTL3D -> GlassViewMTL(With comment mentioning how it is not subclass but a subView of GlassView3D) - At other places also i will remove 3D in names and appropriate comment in CGL/MTL layer class. 2. Regarding NSOpenGLView : Since both CGL and MTL views are not subclass of same NSView we have current structure with Event handling in common class GlassView3D and CGL & MTL Views as subViews of GlassView3D. I also tried removing NSOpenGLView reference and then running Ensemble8 in ES2 pipeline and things work fine. But we want to minimize changes related to already present default ES2 pipeline in this PR as part of refactoring effort. We can work on it in as a follow-up issue. 3. Regarding change in MacOSXWindowSystemInterface.m : Same here we want to minimize changes related to ES2 in this PR. We can work on it in as a follow-up issue. 4. Regarding setOpaque() in GlassWindow.m : While refactoring Glass for Metal pipeline under [JDK-8325379](https://bugs.openjdk.org/browse/JDK-8325379) this was identified as follow up issue : [JDK-8356758](https://bugs.openjdk.org/browse/JDK-8356758). We were aware of how this code related to [JDK-8095004](https://bugs.openjdk.org/browse/JDK-8095004) but thanks for pointing to [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040) which was not verified. There are no regression seen with this refactoring, PickTest3D works properly in both ES2 and MTL pipeline of this PR and matches output seen with mainline code. I verified that test mentioned in [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040) on latest mainline code and i still see that black filling is drawn. Same behaviour is seen with ES2 and MTL pipeline with this PR. But it works properly in 8u431, looks like the issue has resurfaced so i have created new bug : [JDK-8359904](https://bugs.openjdk.org/browse/JDK-8 359904) 5. Regarding removal of JNI method getNativeLayer() from GlassView.m : Yes this is not used anywhere and we can remove it. I removed this code, built and tested Ensemble8, started CI headful test run. If everything is green will go ahead and remove it and its corresponding code in MacView.java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-2983606142 From mhanl at openjdk.org Wed Jun 18 10:23:33 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Jun 2025 10:23:33 GMT Subject: RFR: 8359896: [TestBug][JUnit5] Possible configuration error In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote: > A simple change to remove `@Test` annotation from two graphics unit tests. > > The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. > > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. Saw that as well some days ago, this is the right fix. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1833#pullrequestreview-2938646184 From tsayao at openjdk.org Wed Jun 18 10:23:34 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 18 Jun 2025 10:23:34 GMT Subject: Integrated: 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 01:00:31 GMT, Thiago Milczarek Sayao wrote: > Upgrade the minimum required GTK version for JavaFX to GTK 3.20 to enable modern features and better Linux desktop integration. > > JavaFX currently depends on GTK 3.8, [released](https://mail.gnome.org/archives/gtk-devel-list/2013-March/msg00108.html) in March 2013. This version is outdated and predates many useful GTK API improvements. > > GTK 3.20 was [released](https://mail.gnome.org/archives/gtk-list/2016-March/msg00026.html) on March 21, 2016. > > Updating the GTK minimum requirement to 3.20 would enable JavaFX to support new features, including the improvements proposed in #1605 > > Major Linux distributions already provide GTK 3.20 or newer: > - Ubuntu LTS 18.04+ (ships GTK 3.22+) > - Debian 9+ (ships GTK 3.22+) > - Fedora 24+ (ships GTK 3.20+) > - Oracle Linux and Red Hat Enterprise Linux 8+ (ships GTK 3.22+) This pull request has now been integrated. Changeset: 4257aa9f Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/4257aa9fb96f3ed1b7e59ab0f4f62a13909e272c Stats: 62 lines in 3 files changed: 37 ins; 23 del; 2 mod 8359396: [Linux] Require Gtk3 >= 3.20 for glass-gtk Reviewed-by: kcr, lkostyra, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1825 From mhanl at openjdk.org Wed Jun 18 10:44:35 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Jun 2025 10:44:35 GMT Subject: RFR: 8359599: Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 07:31:45 GMT, Johan Vos wrote: > Hence, while I like the idea here (avoiding unneeded heavy-cost operations in VirtualFlow), I would like to avoid a number of follow-up issues once this is merged -- driven by a change in "expected" behavior. I completely agree. We need to be careful with such changes. > However, it is very likely that some code out there implicitly rely on the rebuild-from-scratch logic, and that code will then work different after applying this PR. Since all rows (and cells) are reset and then updated, all changes that were not taken into account by the control are taken into account in any case then. On a side note here: In any JavaFX project, I have overwritten the `refresh` method (since it is not final) and always implemented the lightweight method as proposed here. I never found any problem. But I think there is one concrete case which breaks now. Take the following example (slightly modified version of the code in the ticket):

    Example import java.util.concurrent.atomic.AtomicBoolean; import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.FXCollections; import javafx.geometry.Insets; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.TableColumn; import javafx.scene.control.TableRow; import javafx.scene.control.TableView; import javafx.scene.layout.Priority; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class TableRefresh extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) throws Exception { TableView tv = new RefreshTableView<>(); tv.setEditable(true); AtomicBoolean alternate = new AtomicBoolean(false); tv.setRowFactory(e -> { if (alternate.get()) { System.out.println("Creating alternative row"); return new TableRow<>() { { setPadding(new Insets(5)); } }; } System.out.println("Creating row"); return new TableRow<>(); }); TableColumn col = new TableColumn<>("Name"); col.setCellValueFactory(i -> new SimpleStringProperty(i.getValue())); tv.getColumns().addAll(col); tv.setItems(FXCollections.observableArrayList("A", "B")); VBox.setVgrow(tv, Priority.ALWAYS); Button btn = new Button("Refresh"); btn.setOnAction(e -> { alternate.set(true); tv.refresh(); }); Scene scene = new Scene(new VBox(tv, btn)); stage.setScene(scene); stage.setTitle("Table Refresh"); stage.show(); } }
    Here, I'm aware that `refresh()` is recreating all rows, and update a boolean flag before calling `refresh()`, which leads to another path that is picked up and therefore other rows. In this case, it is much better to just set a new `TableRow` factory. This will do the same as what `refresh()` is doing right now (but not after this PR). In never saw this code in the wild though. But that is still a valid risk that we need to consider. This is the only problem I see right now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-2983677523 From mhanl at openjdk.org Wed Jun 18 10:46:35 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Jun 2025 10:46:35 GMT Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a temporary Stage In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 17:44:48 GMT, Andy Goryachev wrote: >> Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls. >> >> It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise. >> >> Take the following test code: >> >> VirtualFlowTestUtils.clickOnRow(tableView, 2); >> VirtualFlowTestUtils.clickOnRow(tableView, 4); >> >> >> What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after. >> >> This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic. >> >> So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods. >> >> For the example above, this would result in: >> >> stageLoader = new StageLoader(tableView); >> VirtualFlowTestUtils.clickOnRow(tableView, 2); >> VirtualFlowTestUtils.clickOnRow(tableView, 4); >> >> >> The stageLoader should be disposed in an @AfterEach. >> >> Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty. >> Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly. > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java line 349: > >> 347: flow = (VirtualFlow)control.lookup("#virtual-flow"); >> 348: >> 349: if (sl != null) { > > should we have a check here with a helpful message (which recommends to use `StageLoader`), instead of returning `null`? I thought about this as well. No strong opinion from my side. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1829#discussion_r2154281361 From mhanl at openjdk.org Wed Jun 18 12:15:14 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Jun 2025 12:15:14 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests [v2] In-Reply-To: References: Message-ID: > As written in the ticket, we might want to clarify that we use `JUnit5` for testing in the `CONTRIBUTING` guidelines. > > This is a first idea of how we could document this and also link to the JUnit page in case contributors are not familiar with the framework (or `JUnit5` in particular). > > Feedback welcome! Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Move JUnit5 reference to 'Test your changes' ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1828/files - new: https://git.openjdk.org/jfx/pull/1828/files/fb31f897..a78926ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1828&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1828&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1828.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1828/head:pull/1828 PR: https://git.openjdk.org/jfx/pull/1828 From mhanl at openjdk.org Wed Jun 18 13:10:33 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Jun 2025 13:10:33 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests [v2] In-Reply-To: <-nGWNkuP1f0Zf0jbTksobDv2HIxzmqlmZhJTWirwvjU=.c5971cc8-e723-43fb-a4c7-46a2f4a97658@github.com> References: <-nGWNkuP1f0Zf0jbTksobDv2HIxzmqlmZhJTWirwvjU=.c5971cc8-e723-43fb-a4c7-46a2f4a97658@github.com> Message-ID: <39x2t5eEA3aGGRyi6dtnWEW2rYjWOwt5AKGt2Z2X3yY=.13618731-6ab9-4a0d-bfd8-efe2020daeb7@github.com> On Mon, 16 Jun 2025 16:10:44 GMT, Marius Hanl wrote: > Should we mention about JUnit5 under **Test your changes** ([here](https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/CONTRIBUTING.md?plain=1#L66)), where we mention that a fix should have associated tests? Done. This location is indeed much better. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1828#discussion_r2154558466 From angorya at openjdk.org Wed Jun 18 14:46:35 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 14:46:35 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests [v2] In-Reply-To: References: Message-ID: <0sjl749qmJ0029Lr9ewD207fy3DT_t8J9m6FaZ3HYMQ=.166ee39d-3866-4e61-be9d-f1283067aeaa@github.com> On Wed, 18 Jun 2025 12:15:14 GMT, Marius Hanl wrote: >> As written in the ticket, we might want to clarify that we use `JUnit5` for testing in the `CONTRIBUTING` guidelines. >> >> This is a first idea of how we could document this and also link to the JUnit page in case contributors are not familiar with the framework (or `JUnit5` in particular). >> >> Feedback welcome! > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Move JUnit5 reference to 'Test your changes' Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1828#pullrequestreview-2939546422 From kizune at openjdk.org Wed Jun 18 14:54:36 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 18 Jun 2025 14:54:36 GMT Subject: RFR: 8359896: [TestBug][JUnit5] Possible configuration error In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote: > A simple change to remove `@Test` annotation from two graphics unit tests. > > The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. > > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. Marked as reviewed by kizune (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1833#pullrequestreview-2939575209 From kizune at openjdk.org Wed Jun 18 14:57:39 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 18 Jun 2025 14:57:39 GMT Subject: RFR: 8356652: Input field ignores custom input source characters [v2] In-Reply-To: References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com> Message-ID: On Fri, 16 May 2025 22:25:20 GMT, Martin Fox wrote: >> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead. >> >> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Second try at making Keyman work to some extent Looks good. ------------- Marked as reviewed by kizune (Committer). PR Review: https://git.openjdk.org/jfx/pull/1805#pullrequestreview-2939586997 From angorya at openjdk.org Wed Jun 18 15:02:41 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 15:02:41 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 22:48:03 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - cleanup >> - api >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - cleanup >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - seems to work >> - wired >> - moved >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - ... and 46 more: https://git.openjdk.org/jfx/compare/1ea980ea...7acc55db > > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 35: > >> 33: * @since 999 TODO >> 34: */ >> 35: public class TabStop { > > Should this be a record? If not, it should at least be a final class. No and no. The application code or the custom component should be able to extend the TabStop class to supply additional options. > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 41: > >> 39: * Constructs a new tab stop with the specified position. >> 40: * >> 41: * @param position the position in pixels > > Is pixels the right unit here? Should it be points instead? Or should it allow for the specification of units so that you could specify it in "em"s? > > @prrace might want to weigh in on this. Using the same units used everywhere else (text layout, padding, border, etc.) I think any conversion should be the responsibility of the application code. > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 39: > >> 37: * @since 999 TODO >> 38: */ >> 39: public class TabStopPolicy { > > Is there a reason this class is not final? It probably should be. good point, changed to `final`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2154840273 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2154836049 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2154841884 From angorya at openjdk.org Wed Jun 18 15:26:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 15:26:38 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: References: Message-ID: <3GOTEwlwHDbNuNblOkdCZBIcOSK1eehG50UVvvdyEs8=.0fe6d1ad-a130-4679-b49c-829a24ae412c@github.com> On Tue, 17 Jun 2025 23:00:21 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - cleanup >> - api >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - cleanup >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - seems to work >> - wired >> - moved >> - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops >> - ... and 46 more: https://git.openjdk.org/jfx/compare/1ea980ea...7acc55db > > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 60: > >> 58: >> 59: /** >> 60: * Provides default tab stops (beyond the last tab stop specified by {@code #tabStops()}, > > Having this be a plural when it is a single value (a double) is awkward. I would name the property `defaultStop` and document that the default is used for all stops beyond the last stop. This terminology is borrowed from a well known software product. I think it is apt as it describes the spacing (and the positions) of multiple tab stops, and also the users might be familiar with the term. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2154903798 From angorya at openjdk.org Wed Jun 18 15:29:34 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 15:29:34 GMT Subject: RFR: 8359896: [TestBug][JUnit5] Possible configuration error In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote: > A simple change to remove `@Test` annotation from two graphics unit tests. > > The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. > > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. Argh, my fault! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1833#pullrequestreview-2939721482 From angorya at openjdk.org Wed Jun 18 15:34:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 15:34:15 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3] In-Reply-To: References: Message-ID: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> > # Tab Stop Policy > > Andy Goryachev > > > > > ## Summary > > Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize` > value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text > segments font [0]. > > ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40) > > > ## Goals > > The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text. > > > > ## Non-Goals > > The following are not the goals of this proposal: > > - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment` > - support the `leader` property (symbols to fill the empty space before the tab stop) > - support for `firstLineIndent` property > - deprecate the `TextFlow::tabsize` property > > > > ## Motivation > > The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content > contains text with different font sizes. > > In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided > in RTF or MS Word documents. > > > > > ## Description > > ### TextFlow > > > /** > * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. > *

    > * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)}, > * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within > * this {@code TextFlow}. > * > * @defaultValue null > * > * @since 999 TODO > */ > public final ObjectProperty tabStopPolicyProperty() { > > public final TabStopPolicy getTabStopPolicy() { > > public final void setTabStopPolicy(TabStopPolicy policy) { > > /** > * The size of a tab stop in spaces. > * Values less than 1 are treated as 1. This value overrides the > * {@code tabSize} of contained {@link Text} nodes. > *

    > + * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes > + * with different fonts are contained within this {@code TextFlow}. > + * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead. > * > * @defaultValue 8 > * > * @since 14 > */ > public final IntegerProperty tabSizeProperty() { > > > > ### TabStopPolicy > > > /** > * The TabStopPolicy determines the tab stop pos... Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1744/files - new: https://git.openjdk.org/jfx/pull/1744/files/7acc55db..ef38166a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=01-02 Stats: 9 lines in 3 files changed: 2 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1744.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744 PR: https://git.openjdk.org/jfx/pull/1744 From lkostyra at openjdk.org Wed Jun 18 15:38:36 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Jun 2025 15:38:36 GMT Subject: RFR: 8351867: No UI changes while iconified [v3] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 08:21:54 GMT, John Hendrikx wrote: >> Adds code to trigger a scene update when a Window is restored >> >> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479 > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Also call entireSceneNeedsRepaint > - Add test case I have noticed the tests for maximized stages fail on my system: DrawAfterDeiconifyTest > maximizedStageRedrawsAfterDeiconify(StageStyle) > [1] DECORATED FAILED org.opentest4j.AssertionFailedError: expected:rgba(255,105,180,255) but was:rgba(0,255,0,255) at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38) at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:138) at app//test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:168) at app//test.robot.javafx.stage.DrawAfterDeiconifyTest.lambda$redrawsAfterDeiconify$6(DrawAfterDeiconifyTest.java:110) DrawAfterDeiconifyTest > maximizedStageRedrawsAfterDeiconify(StageStyle) > [2] UNDECORATED FAILED org.opentest4j.AssertionFailedError: expected:rgba(255,105,180,255) but was:rgba(0,255,0,255) at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38) at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:138) at app//test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:168) at app//test.robot.javafx.stage.DrawAfterDeiconifyTest.lambda$redrawsAfterDeiconify$6(DrawAfterDeiconifyTest.java:110) DrawAfterDeiconifyTest > maximizedStageRedrawsAfterDeiconify(StageStyle) > [3] TRANSPARENT FAILED org.opentest4j.AssertionFailedError: expected:rgba(255,105,180,255) but was:rgba(0,255,0,255) at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38) at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:138) at app//test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:168) at app//test.robot.javafx.stage.DrawAfterDeiconifyTest.lambda$redrawsAfterDeiconify$6(DrawAfterDeiconifyTest.java:110) This is on Windows 11, the Stage in fact does not change its background. I'm not sure what the problem could be, or if it's fixable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2984725453 From azvegint at openjdk.org Wed Jun 18 15:39:16 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 18 Jun 2025 15:39:16 GMT Subject: RFR: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place Message-ID: This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot. More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753) In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time. This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html). This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps). ---- * The remote desktop for Robot is enabled by default on GnomeShell 47+ * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46) * The key handling might still have bugs. * The main goal is to add this new functionality. If there are small issues that can't be solved right away, I will prefer to fix them in follow up fixes. ------------- Commit messages: - 8357584: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place Changes: https://git.openjdk.org/jfx/pull/1834/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357584 Stats: 1312 lines in 12 files changed: 1081 ins; 139 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1834.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1834/head:pull/1834 PR: https://git.openjdk.org/jfx/pull/1834 From arapte at openjdk.org Wed Jun 18 16:10:34 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Jun 2025 16:10:34 GMT Subject: RFR: 8296284: Update CONTRIBUTING guidelines to state that JUnit 5 is used for tests [v2] In-Reply-To: References: Message-ID: <0YAnnqMi10ryR46EHt1FomU-NNTLOwUWftJfx4EKWvY=.f1597734-e1d0-45cb-a254-a61b2269eccc@github.com> On Wed, 18 Jun 2025 12:15:14 GMT, Marius Hanl wrote: >> As written in the ticket, we might want to clarify that we use `JUnit5` for testing in the `CONTRIBUTING` guidelines. >> >> This is a first idea of how we could document this and also link to the JUnit page in case contributors are not familiar with the framework (or `JUnit5` in particular). >> >> Feedback welcome! > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Move JUnit5 reference to 'Test your changes' LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1828#pullrequestreview-2939872993 From sykora at openjdk.org Wed Jun 18 17:03:33 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Wed, 18 Jun 2025 17:03:33 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 In-Reply-To: References: Message-ID: <-tKaVK1lIKAWB8PzRM8SRXgjggs3jIlF_kTRADZgggU=.d3cfa196-63a1-44df-a0db-60f5cc1fd063@github.com> On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. > > This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. Builds all went fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1827#pullrequestreview-2940050640 From arapte at openjdk.org Wed Jun 18 17:23:33 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Jun 2025 17:23:33 GMT Subject: RFR: 8359896: [TestBug][JUnit5] Possible configuration error In-Reply-To: References: Message-ID: <3np2Xev7_PF-tSClU7Dbxi2RbJdpounq4-g41CjMHG4=.88818dee-c566-44cf-a27c-8186e03a9b22@github.com> On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote: > A simple change to remove `@Test` annotation from two graphics unit tests. > > The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. > > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. This is a very simple test only fix, so we can ignore the 24 hours to integrate rule. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1833#issuecomment-2985117349 From arapte at openjdk.org Wed Jun 18 17:23:33 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Jun 2025 17:23:33 GMT Subject: Integrated: 8359896: [TestBug][JUnit5] Possible configuration error In-Reply-To: References: Message-ID: <-axPNXOJpR68rhVPOpkjs319ZJtXCuRcHkyNGOwP0Bg=.305378a8-b6d3-45a4-ab48-4c2dd66597ef@github.com> On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote: > A simple change to remove `@Test` annotation from two graphics unit tests. > > The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results in warning message. > > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnSucceeded()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. > > WARNING: Possible configuration error: method [public void test.javafx.concurrent.ServiceLifecycleTest.cancelCalledFromOnFailed()] resulted in multiple TestDescriptors > [org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor, org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor]. > This is typically the result of annotating a method with multiple competing annotations such as @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, etc. This pull request has now been integrated. Changeset: f9e87922 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/f9e879225964f2ed2359cfc83accff674c476513 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8359896: [TestBug][JUnit5] Possible configuration error Reviewed-by: jhendrikx, mhanl, kizune, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1833 From kcr at openjdk.org Wed Jun 18 17:24:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Jun 2025 17:24:38 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3] In-Reply-To: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> References: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> Message-ID: <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com> On Wed, 18 Jun 2025 15:34:15 GMT, Andy Goryachev wrote: >> # Tab Stop Policy >> >> Andy Goryachev >> >> >> >> >> ## Summary >> >> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize` >> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text >> segments font [0]. >> >> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40) >> >> >> ## Goals >> >> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text. >> >> >> >> ## Non-Goals >> >> The following are not the goals of this proposal: >> >> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment` >> - support the `leader` property (symbols to fill the empty space before the tab stop) >> - support for `firstLineIndent` property >> - deprecate the `TextFlow::tabsize` property >> >> >> >> ## Motivation >> >> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content >> contains text with different font sizes. >> >> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided >> in RTF or MS Word documents. >> >> >> >> >> ## Description >> >> ### TextFlow >> >> >> /** >> * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. >> *

    >> * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)}, >> * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within >> * this {@code TextFlow}. >> * >> * @defaultValue null >> * >> * @since 999 TODO >> */ >> public final ObjectProperty tabStopPolicyProperty() { >> >> public final TabStopPolicy getTabStopPolicy() { >> >> public final void setTabStopPolicy(TabStopPolicy policy) { >> >> /** >> * The size of a tab stop in spaces. >> * Values less than 1 are treated as 1. This value overrides the >> * {@code tabSize} of contained {@link Text} nodes. >> *

    >> + * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes >> + * with different fonts are contained within this {@code TextFlow}. >> + * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead. >> * >> * @defaultValue 8 >> *... > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments More API comments. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 31: > 29: *

    > 30: * A tab stop is at a specified distance from the > 31: * left margin, aligns text in a specified way, and has a specified leader. Where is the alignment and leader specified? modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 33: > 31: * left margin, aligns text in a specified way, and has a specified leader. > 32: * > 33: * @since 999 TODO Change this to either 25 (if you'd like to shoot for getting it into 25) or 26. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 44: > 42: > 43: /** > 44: * Constructs a new {@code TabStopPolicy} instance. Minor: Maybe add "with an empty list of stops"? modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 53: > 51: * > 52: * @return the non-null, list of tab stops > 53: */ Minor: remove the comma. modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 60: > 58: /** > 59: * Provides default tab stops (beyond the last tab stop specified by {@code #tabStops()}, > 60: * as a fixed repeating distance in pixels from the last tab stop position. This is a little misleading. The stops are applied after the last tap stop position, but the distance is not fixed "from" that point. The next sentence explains this, but since the first sentence shows up in the method summary, I might reword this a bit to remove the possibility of this misunderstanding. How about: "as a fixed repeating distance in pixels for tabs after the last tab stop position." or similar? modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 64: > 62: * the leading edge of the {@code TextFlow} this policy is registered with. > 63: *

    > 64: * The value of less than or equal 0 disables the default stops. Minor: "A value less than or equal ..." modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 67: > 65: * > 66: * @return the default tab stops property > 67: * @defaultValue 0 Would "8" be a better default value? I think having tabs do something (instead of effectively being ignored) by default when you create a TabStopPolicy would be less surprising to app developers. ------------- PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-2940041342 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155112258 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155138326 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155120637 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155128701 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155108697 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155114912 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155133015 From kcr at openjdk.org Wed Jun 18 17:24:39 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Jun 2025 17:24:39 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 14:59:02 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 35: >> >>> 33: * @since 999 TODO >>> 34: */ >>> 35: public class TabStop { >> >> Should this be a record? If not, it should at least be a final class. > > No and no. The application code or the custom component should be able to extend the TabStop class to supply additional options. How would such extensibility work? What would the implementation do with additional options? Or is the intention that something other than TextFlow (e.g., RichTextArea or some third-party component would use that information, but TextFlow would ignore it? If so, that seems OK. >> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 41: >> >>> 39: * Constructs a new tab stop with the specified position. >>> 40: * >>> 41: * @param position the position in pixels >> >> Is pixels the right unit here? Should it be points instead? Or should it allow for the specification of units so that you could specify it in "em"s? >> >> @prrace might want to weigh in on this. > > Using the same units used everywhere else (text layout, padding, border, etc.) > I think any conversion should be the responsibility of the application code. That seems fine then, as long as this has been thought through. A loosely related question: what about setting the tab stop policy via CSS? I can see apps that would want to do this. It could be added later if you don't see it as a primary use case. >> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 60: >> >>> 58: >>> 59: /** >>> 60: * Provides default tab stops (beyond the last tab stop specified by {@code #tabStops()}, >> >> Having this be a plural when it is a single value (a double) is awkward. I would name the property `defaultStop` and document that the default is used for all stops beyond the last stop. > > This terminology is borrowed from a well known software product. I think it is apt as it describes the spacing (and the positions) of multiple tab stops, and also the users might be familiar with the term. Hmm. OK then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155098866 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155102659 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155105813 From kcr at openjdk.org Wed Jun 18 17:29:34 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Jun 2025 17:29:34 GMT Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 In-Reply-To: References: Message-ID: <3u6WMk3UjdyP3ccVO-ZFk_JPI-Mg4O-dT4LeSpuQvUk=.0034a9e5-8827-4562-9f07-9eb335129f97@github.com> On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested. > > This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note. Thanks for the reviews. I'll file the CSR, but let it sit for a while to also give others a chance to review or reply to the thread on the openjfx-dev mailing list. I will also need to merge master some time after #1832 is integrated, since there will be a (trivial) merge conflict for me to resolve. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1827#issuecomment-2985133895 From kcr at openjdk.org Wed Jun 18 17:30:36 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Jun 2025 17:30:36 GMT Subject: RFR: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 15:33:45 GMT, Alexander Zvegintsev wrote: > This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot. > More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753) > > In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time. > > This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html). > This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps). > > ---- > > * The remote desktop for Robot is enabled by default on GnomeShell 47+ > * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46) > * The key handling might still have bugs. > * The main goal is to add this new functionality. If there are small issues that can't be solved right away, I will prefer to fix them in follow up fixes. Reviewers: @kevinrushforth @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/1834#issuecomment-2985137637 From mstrauss at openjdk.org Wed Jun 18 18:13:37 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 18 Jun 2025 18:13:37 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: References: Message-ID: <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com> On Wed, 18 Jun 2025 17:02:13 GMT, Kevin Rushforth wrote: >> This terminology is borrowed from a well known software product. I think it is apt as it describes the spacing (and the positions) of multiple tab stops, and also the users might be familiar with the term. > > Hmm. OK then. This doesn't read like a proper English sentence to me. In Microsoft Word, there's a spinner control titled "Default tab stops:", which I suppose should be read as, for example: "Default tab stops every 0.5 cm". As for naming the API, I suggest something like `defaultTabWidth` or `defaultWidth` (the word "tab" doesn't need to be repeated, as it's declared in a class named `TabStopPolicy`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155215581 From angorya at openjdk.org Wed Jun 18 18:39:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 18:39:37 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3] In-Reply-To: <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com> References: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com> Message-ID: <5-uiE_6WHAsNaf9wC6h9H0SOiuT_6tdRWneKhbr_9F8=.0981e5d6-b692-4adb-b8fc-0d57d686f134@github.com> On Wed, 18 Jun 2025 17:06:20 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 31: > >> 29: *

    >> 30: * A tab stop is at a specified distance from the >> 31: * left margin, aligns text in a specified way, and has a specified leader. > > Where is the alignment and leader specified? oops, a leftover from an earlier version. there is no support currently for the alignment or the leader. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155253910 From angorya at openjdk.org Wed Jun 18 18:39:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 18:39:37 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2] In-Reply-To: <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com> References: <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com> Message-ID: On Wed, 18 Jun 2025 18:11:17 GMT, Michael Strau? wrote: >> Hmm. OK then. > > This doesn't read like a proper English sentence to me. In Microsoft Word, there's a spinner control titled "Default tab stops:", which I suppose should be read as, for example: "Default tab stops every 0.5 cm". > > As for naming the API, I suggest something like `defaultTabWidth` or `defaultWidth` (the word "tab" doesn't need to be repeated, as it's declared in a class named `TabStopPolicy`). Not sure if defaultTabWidth is a good choice here though, because it's not, it's actually tab stops - think of the typewriter (I know, referring to an ancient technology like floppy disk for the 'save' icon does not age well) I am open to suggestions. I am used to "default tab stops", perhaps we could just explain it better? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155251249 From angorya at openjdk.org Wed Jun 18 18:45:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 18:45:36 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3] In-Reply-To: <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com> References: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com> Message-ID: On Wed, 18 Jun 2025 17:22:07 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStop.java line 33: > >> 31: * left margin, aligns text in a specified way, and has a specified leader. >> 32: * >> 33: * @since 999 TODO > > Change this to either 25 (if you'd like to shoot for getting it into 25) or 26. I hope to get it to 25, but we'll see. Will change once we know more. > modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 67: > >> 65: * >> 66: * @return the default tab stops property >> 67: * @defaultValue 0 > > Would "8" be a better default value? I think having tabs do something (instead of effectively being ignored) by default when you create a TabStopPolicy would be less surprising to app developers. No, this value is in pixels (unlike the `tabSize` property). I think it's better to let the application specify it explicitly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155263491 PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2155260675 From angorya at openjdk.org Wed Jun 18 18:54:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 18:54:17 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v4] In-Reply-To: References: Message-ID: <1eBgt4tf9YPFk57g89Fp-mMyYaTfl3XSmemD_KbuQd0=.c9283892-bc55-49ff-8863-855e07a264f0@github.com> > # Tab Stop Policy > > Andy Goryachev > > > > > ## Summary > > Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize` > value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text > segments font [0]. > > ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40) > > > ## Goals > > The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text. > > > > ## Non-Goals > > The following are not the goals of this proposal: > > - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment` > - support the `leader` property (symbols to fill the empty space before the tab stop) > - support for `firstLineIndent` property > - deprecate the `TextFlow::tabsize` property > > > > ## Motivation > > The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content > contains text with different font sizes. > > In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided > in RTF or MS Word documents. > > > > > ## Description > > ### TextFlow > > > /** > * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. > *

    > * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)}, > * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within > * this {@code TextFlow}. > * > * @defaultValue null > * > * @since 999 TODO > */ > public final ObjectProperty tabStopPolicyProperty() { > > public final TabStopPolicy getTabStopPolicy() { > > public final void setTabStopPolicy(TabStopPolicy policy) { > > /** > * The size of a tab stop in spaces. > * Values less than 1 are treated as 1. This value overrides the > * {@code tabSize} of contained {@link Text} nodes. > *

    > + * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes > + * with different fonts are contained within this {@code TextFlow}. > + * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead. > * > * @defaultValue 8 > * > * @since 14 > */ > public final IntegerProperty tabSizeProperty() { > > > > ### TabStopPolicy > > > /** > * The TabStopPolicy determines the tab stop pos... Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: final tab stop ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1744/files - new: https://git.openjdk.org/jfx/pull/1744/files/ef38166a..f873a5b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=02-03 Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1744.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744 PR: https://git.openjdk.org/jfx/pull/1744 From angorya at openjdk.org Wed Jun 18 18:54:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Jun 2025 18:54:18 GMT Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3] In-Reply-To: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> References: <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com> Message-ID: On Wed, 18 Jun 2025 15:34:15 GMT, Andy Goryachev wrote: >> # Tab Stop Policy >> >> Andy Goryachev >> >> >> >> >> ## Summary >> >> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize` >> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text >> segments font [0]. >> >> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40) >> >> >> ## Goals >> >> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text. >> >> >> >> ## Non-Goals >> >> The following are not the goals of this proposal: >> >> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment` >> - support the `leader` property (symbols to fill the empty space before the tab stop) >> - support for `firstLineIndent` property >> - deprecate the `TextFlow::tabsize` property >> >> >> >> ## Motivation >> >> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content >> contains text with different font sizes. >> >> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided >> in RTF or MS Word documents. >> >> >> >> >> ## Description >> >> ### TextFlow >> >> >> /** >> * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}. >> *

    >> * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)}, >> * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within >> * this {@code TextFlow}. >> * >> * @defaultValue null >> * >> * @since 999 TODO >> */ >> public final ObjectProperty tabStopPolicyProperty() { >> >> public final TabStopPolicy getTabStopPolicy() { >> >> public final void setTabStopPolicy(TabStopPolicy policy) { >> >> /** >> * The size of a tab stop in spaces. >> * Values less than 1 are treated as 1. This value overrides the >> * {@code tabSize} of contained {@link Text} nodes. >> *

    >> + * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes >> + * with different fonts are contained within this {@code TextFlow}. >> + * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead. >> * >> * @defaultValue 8 >> *... > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments > question: what about setting the tab stop policy via CSS? A very good question! It might be entirely possible (in a separate PR), though judging by experience from adding tab stops to the rich editor demo https://github.com/openjdk/jfx/pull/1800 it's probably unnecessary, since TextFlow is somewhat of a low-level control. Another complication is that the policy is a complex entity, with a list of (possibly complex) `TabStop`s, and other fields, so I am not sure how easy it would be to add CSS support. How would it look in CSS? Also, decided to make the `TabStop` class `final`. We can always remove the `final` keyword if the use case arises. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-2985361243 PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-2985364601 From sykora at openjdk.org Wed Jun 18 19:32:33 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Wed, 18 Jun 2025 19:32:33 GMT Subject: RFR: 8358802: Update boot JDK to 24.0.1 [v2] In-Reply-To: <-57a8QYTYAlDLCzuj85WbxiTBogKxRh3kjZkrb9shS0=.568ad1ce-6201-4d7a-a4ef-9cc417279f35@github.com> References: <-57a8QYTYAlDLCzuj85WbxiTBogKxRh3kjZkrb9shS0=.568ad1ce-6201-4d7a-a4ef-9cc417279f35@github.com> Message-ID: On Tue, 17 Jun 2025 22:50:13 GMT, Ambarish Rapte wrote: >> Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 >> No changes to gradle build script were needed for this upgrade. > > Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into jdk24.0.1-gradle8142 > - javadoc 24 sha256 > - chmod 644 gradlew > - result of sh gradlew wrapper --gradle-version 8.14.2 > - manual changes Builds and tests ran fine with the updated JDK. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1832#pullrequestreview-2940438196 From mfox at openjdk.org Wed Jun 18 20:23:37 2025 From: mfox at openjdk.org (Martin Fox) Date: Wed, 18 Jun 2025 20:23:37 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline In-Reply-To: References: <3kas-_2sLVoXg1Mz5j57auwRgghF6WWb3kXSRgSOajM=.636a07f8-b464-40bc-b33d-12234e3e6e63@github.com> Message-ID: On Wed, 18 Jun 2025 10:16:41 GMT, Jayathirth D V wrote: >> Metal is here! Yes! >> >> It took me a while to sort out how the GlassView and GlassLayer classes work in this PR. It?s not clear based on the naming that the classes which handle drawing (GlassViewCGL3D and GlassViewMTL3D ) are not subclasses of the class that handles events (GlassView3D). The naming conventions could be clearer or at the very least there should be some comments in the code. >> >> I think some of this structure is being dictated by the way GlassViewCGL3D is derived from NSOpenGLView since that prevents us from making it a subclass of, say, GlassView3D. But I?m almost certain the NSOpenGLView reference is just cruft. All of the OpenGL processing happens in a CAOpenGLLayer which has nothing to do with the (unused) NSOpenGLView machinery. In the current master and this PR I can derive from NSView instead of NSOpenGLView and everything works fine. >> >> There is some code in Prism (MacOSXWindowSystemInterface.m) that can associate an NSOpenGLContext with an NSView but I don?t think a view is ever passed in. It would be nice to clean that code up since the view-related calls are deprecated and generating compiler warnings. >> >> I think the NSOpenGLView reference should be removed. Beyond that you could keep the current class structure and view layout since there?s something to be said for separating drawing and event processing into different NSViews. >> >> I would rather not see the 3D terminology carried over into the new classes. It's there to make a distinction that's no longer relevant (according to the comments there used to be a GlassView2D). But that is a personal pet peeve so feel free to ignore it. >> >> Look like it?s not possible to add comments to unchanged code in GitHub (?!) so I guess I have to write the following issues up here. >> >> In GlassWindow.m line 807 there?s this bit of mysterious code: >> >> >> CALayer *layer = [window->view layer]; >> if (([layer isKindOfClass:[CAOpenGLLayer class]] == YES) && >> (([window->nsWindow styleMask] & NSWindowStyleMaskTexturedBackground) == NO)) >> { >> [((CAOpenGLLayer*)layer) setOpaque:[window->nsWindow isOpaque]]; >> } >> >> >> It was put there to resolve [JDK-8095004](https://bugs.openjdk.org/browse/JDK-8095004) and [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040). In this PR the layer is nil at this point so this code isn?t doing anything. I haven?t verified whether this is causing a regression. In the master branch that setOpaque: call will always happen since the NSWindowSt... > > @beldenfox Thanks for your inputs. > > 1. Regarding adding comments in GlassView/Layer classes about how they are not subclasses but subViews/subLayers : Sure i will go ahead and add comments in the class. Also as you mentioned we can name them better: > > - GlassView3D -> GlassViewEventHandler(Since it is common class which handles events for both OpenGL and Metal pipeline) Or GlassSubView(Since it is added as subView in GlassHostView in GlassView.m). Please suggest if you have better names that we can use here. > - GlassViewCGL3D -> GlassViewCGL(With comment mentioning how it is not subclass but a subView of GlassView3D) > - GlassViewMTL3D -> GlassViewMTL(With comment mentioning how it is not subclass but a subView of GlassView3D) > - At other places also i will remove 3D in names and appropriate comment in CGL/MTL layer class. > > 2. Regarding NSOpenGLView : Since both CGL and MTL views are not subclass of same NSView we have current structure with Event handling in common class GlassView3D and CGL & MTL Views as subViews of GlassView3D. I also tried removing NSOpenGLView reference and then running Ensemble8 in ES2 pipeline and things work fine. But we want to minimize changes related to already present default ES2 pipeline in this PR as part of refactoring effort. We can work on it in as a follow-up issue. > > 3. Regarding change in MacOSXWindowSystemInterface.m : Same here we want to minimize changes related to ES2 in this PR. We can work on it in as a follow-up issue. > > 4. Regarding setOpaque() in GlassWindow.m : While refactoring Glass for Metal pipeline under [JDK-8325379](https://bugs.openjdk.org/browse/JDK-8325379) this was identified as follow up issue : [JDK-8356758](https://bugs.openjdk.org/browse/JDK-8356758). We were aware of how this code related to [JDK-8095004](https://bugs.openjdk.org/browse/JDK-8095004) but thanks for pointing to [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040) which was not verified. There are no regression seen with this refactoring, PickTest3D works properly in both ES2 and MTL pipeline of this PR and matches output seen with mainline code. I verified that test mentioned in [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040) on latest mainline code and i still see that black filling is drawn. Same behaviour is seen with ES2 and MTL pipeline with this PR. But it works properly in 8u431, looks like the issue has resurfaced so i have created new bug : [JDK-8359904](https://bugs.openjdk.org/browse/JDK -8359904) > > 5. Regard... @jayathirthrao Thanks for the thorough response. And, again, it's great to see Metal happening. > * GlassView3D -> GlassViewEventHandler(Since it is common class which handles events for both OpenGL and Metal pipeline) Or GlassSubView(Since it is added as subView in GlassHostView in GlassView.m). Please suggest if you have better names that we can use here. I want to keep the GlassView prefix since these classes implement the platform side of the View class in the toolkit. If we were to rename anything it would be GlassViewCGL and GlassViewMTL since these are more closely related to Prism than the toolkit View class. But I'm overthinking things. For now I think we should keep GlassView and GlassView3D along with GlassViewCGL and GlassViewMTL and just clarify what's going on in the comments. At some point I want to combine GlassView and GlassView3D into one class but that can wait for a follow-up issue. > 4. Regarding setOpaque() in GlassWindow.m In my testing the setOpaque call isn't happening in this PR since the layer hasn't been created yet. But it doesn't seem to matter (?) I'm having a hard time reproducing the original PickTest3D bug in the master branch. The screenshots in the bug report show translucency but the original bug report doesn't mention it and the PickTest3D code doesn't call for it. I tweaked PickTest3D to try a few combinations of setOpacity and DECORATED/TRANSPARENT and that setOpaque call didn't seem to make any difference even in the master branch. I must be missing something. As for the UNIFIED issue I don't think there's a bug. The implementation relied on the OS to draw a brushed metal background but Apple removed that years ago and now just draws black. I will take a look but only because I want to understand how this works; we might need similar logic if we want to support desktop translucency effects. UNIFIED is deprecated and doesn't work on Windows either so we should probably close the new bug as Never Fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-2985583069 From mfox at openjdk.org Wed Jun 18 20:35:36 2025 From: mfox at openjdk.org (Martin Fox) Date: Wed, 18 Jun 2025 20:35:36 GMT Subject: RFR: 8351867: No UI changes while iconified [v3] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 15:36:23 GMT, Lukasz Kostyra wrote: > I have noticed the tests for maximized stages fail on my system: That's expected. This PR fixes the case where the window goes from iconified to restored. When looking at the code I realized the same fix needs to be applied when the window goes from iconified to maximized so I added that to the test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2985608651 From duke at openjdk.org Wed Jun 18 21:08:44 2025 From: duke at openjdk.org (Pabulaner IV) Date: Wed, 18 Jun 2025 21:08:44 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX Message-ID: This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX. The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method. The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus. I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it works without any errors. Co-Author: @FlorianKirmaier ------------- Commit messages: - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX Changes: https://git.openjdk.org/jfx/pull/1835/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359108 Stats: 42 lines in 4 files changed: 27 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1835.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1835/head:pull/1835 PR: https://git.openjdk.org/jfx/pull/1835 From prr at openjdk.org Wed Jun 18 21:32:31 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 21:32:31 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 20:58:20 GMT, Pabulaner IV wrote: > This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX. > > The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method. > > The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus. > > I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it works without any errors. > > Co-Author: @FlorianKirmaier I'm not at all sure this fix is the right thing to do. What if Swing removed all menu items that aren't owned by Swing ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-2985747667 From mfox at openjdk.org Wed Jun 18 21:50:34 2025 From: mfox at openjdk.org (Martin Fox) Date: Wed, 18 Jun 2025 21:50:34 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline In-Reply-To: References: <3kas-_2sLVoXg1Mz5j57auwRgghF6WWb3kXSRgSOajM=.636a07f8-b464-40bc-b33d-12234e3e6e63@github.com> Message-ID: On Wed, 18 Jun 2025 20:20:45 GMT, Martin Fox wrote: > I'm having a hard time reproducing the original PickTest3D bug in the master branch. Spoke too soon. PickTest3D has been tweaked since the original Mac bug was posted and resolved. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-2985787928 From jhendrikx at openjdk.org Wed Jun 18 21:56:32 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 18 Jun 2025 21:56:32 GMT Subject: RFR: 8351867: No UI changes while iconified [v3] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 20:32:37 GMT, Martin Fox wrote: > > I have noticed the tests for maximized stages fail on my system: > > That's expected. This PR fixes the case where the window goes from iconified to restored. When looking at the code I realized the same fix needs to be applied when the window goes from iconified to maximized so I added that to the test. Do I need to add additional code for that case? The fix is now in `WindowEvent.RESTORE`, which I think should be catching both cases, or does de-iconifying to a maximized stage somehow not send a restore event? The terms are somewhat confusing; if `RESTORE` indicates go to a non-maximized/non-minimized/non-iconified "normal" state, then I suppose I need to add more code in `MAXIMIZE` as well... Edit: I see that iconified state is explicitly set to `false` in the `MAXIMIZE` branch, so it looks like we'd need to do the same there. I'll do some tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2985794673 From kcr at openjdk.org Wed Jun 18 22:14:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Jun 2025 22:14:31 GMT Subject: RFR: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 15:33:45 GMT, Alexander Zvegintsev wrote: > This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot. > More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753) > > In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time. > > This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html). > This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps). > > ---- > > * The remote desktop for Robot is enabled by default on GnomeShell 47+ > * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46) > * The key handling might still have bugs. > * The main goal is to add this new functionality. If there are small issues that can't be solved right away, I will prefer to fix them in follow up fixes. @arapte Would you also be able to look into this in case I am not able to? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1834#issuecomment-2985836298 From mfox at openjdk.org Wed Jun 18 22:59:32 2025 From: mfox at openjdk.org (Martin Fox) Date: Wed, 18 Jun 2025 22:59:32 GMT Subject: RFR: 8351867: No UI changes while iconified [v3] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 21:52:22 GMT, John Hendrikx wrote: > Do I need to add additional code for that case? The fix is now in `WindowEvent.RESTORE`, which I think should be catching both cases, or does de-iconifying to a maximized stage somehow not send a restore event? At least on Windows you can go straight from an iconified state to a maximized state and the only event you'll see is WindowEvent.MAXIMIZE. That should be true on the Mac as well but there are bugs in the way glass handles maximized windows so I'm not entirely sure what the event sequence is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2985963747 From tsayao at openjdk.org Thu Jun 19 00:25:34 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 19 Jun 2025 00:25:34 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v3] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:41:54 GMT, Michael Strau? wrote: >> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: >> >> #### Windows 11 >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | visible, disabled | visible | >> | resizable, modal | visible, disabled | visible | visible | >> | not resizable, modal | hidden | hidden | visible, utility-style | >> >> #### Ubuntu 24 / Fedora 41 (GNOME) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible, _not working_ | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> #### Kubuntu 24 (KDE) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> ## Observations >> >> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. >> * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) >> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. >> * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) >> >> ## Permitted window button operations >> >> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | yes | yes | yes | >> | not resizable, not modal | yes | no | yes | >> | resizable, modal | no | yes | yes | >> | not resizable, modal | no | no | yes | >> >> ## Fixes >> >> This PR includes the following changes: >> 1. Unused code relating to window modality is removed... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small refactor JavaFX modal windows are not native modals, as evidenced by the code removal on this PR (it's not used) . On GNOME, native modal windows automatically remove the minimize and maximize buttons. ![image](https://github.com/user-attachments/assets/5c5935dd-b8db-43b7-8a5e-2459bd2fc1e9) I did an experiment and found that it's possible to get native modal windows (at least with GTK Glass) by passing the modality flag from `WindowStage` to `createWindow`. I haven?t done extensive testing, but it seems to work - likely because the modality can?t be changed afterward. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2986109841 From tsayao at openjdk.org Thu Jun 19 00:27:58 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 19 Jun 2025 00:27:58 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v37] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Use a small C++ Observable implementation to notify values to java only when they change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/c7e7abfc..43dfc193 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=36 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=35-36 Stats: 355 lines in 4 files changed: 163 ins; 87 del; 105 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 jvos at openjdk.org Thu Jun 19 08:39:13 2025 From: jvos at openjdk.org (Johan Vos) Date: Thu, 19 Jun 2025 08:39:13 GMT Subject: RFR: 8324941: POC for Headless platform for JavaFX Message-ID: After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository. ### the Headless Platform The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems) ### changes The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages. This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless) ### enable the Headless Platform Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win). ### testing `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test` runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail. ### robot tests Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those. ------------- Commit messages: - Add headless platform code Changes: https://git.openjdk.org/jfx/pull/1836/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324941 Stats: 1474 lines in 11 files changed: 1470 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1836.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836 PR: https://git.openjdk.org/jfx/pull/1836 From jvos at openjdk.org Thu Jun 19 08:47:08 2025 From: jvos at openjdk.org (Johan Vos) Date: Thu, 19 Jun 2025 08:47:08 GMT Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2] In-Reply-To: References: Message-ID: > After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository. > > ### the Headless Platform > The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. > The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems) > > ### changes > The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages. > This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless) > > ### enable the Headless Platform > Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win). > > ### testing > `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test` > runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail. > > ### robot tests > Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Fix missing ; ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1836/files - new: https://git.openjdk.org/jfx/pull/1836/files/c245d56a..56ebac20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1836.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836 PR: https://git.openjdk.org/jfx/pull/1836 From arapte at openjdk.org Thu Jun 19 10:20:55 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 19 Jun 2025 10:20:55 GMT Subject: Integrated: 8358802: Update boot JDK to 24.0.1 In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:08:33 GMT, Ambarish Rapte wrote: > Support for JDK 24 was added in Gradle 8.14.2. Hence update bootjdk to JDK 24.0.1 and gradle to 8.14.2 > No changes to gradle build script were needed for this upgrade. This pull request has now been integrated. Changeset: fc4642db Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/fc4642dbb008ed0e49996c1eea10b92fad5f7dcf Stats: 28 lines in 7 files changed: 0 ins; 1 del; 27 mod 8358802: Update boot JDK to 24.0.1 8358800: Update Gradle to 8.14.2 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1832 From arapte at openjdk.org Thu Jun 19 10:35:41 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 19 Jun 2025 10:35:41 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v2] In-Reply-To: References: Message-ID: <0XN8XW0GkgOy05b4hRMLNi3wAXJZKOl85YmMNVSnddU=.d0bd9055-6047-45f4-a6fd-b38f8d9da8d8@github.com> > ### Description > This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS. > We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated. > Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing `-Dprism.order=mtl`) > The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use. > > ### Details about the changes > > **Shader changes** > - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl) > - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl > > **Build changes** - There are new tasks added to build.gradle for > - Generation/ Compilation/ linking of Metal shaders > - Compilation of Prism Java and Objective C files > > **Prism** - Prism is the rendering engine of JavaFX. > - Added Metal specific Java classes and respective native implementation which use Metal APIs > - Java side changes: > - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl > - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. > - Native side changes: > - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl > > **Glass** - Glass is the windowing toolkit of JavaFX > - Existing Glass classes are refactored to support both OpenGL and Metal pipelines > - Added Metal specific Glass implementation. > > ### Testing > - Testing performed on different hardware and macOS versions. > - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4) > - macOS versions - macOS 13, macOS 14 and macOS 15 > - Functional Testing: > - All headful tests pass with Metal pipeline. > - Verified samples applications: Ensemble and toys > - Performance Testing: > - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed) > > ### Note to reviewers : > - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline > - It would be a good idea to test both OpenGL and Metal pipelines > - Known issues and tasks ... Ambarish Rapte 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 impl-metal - implement metal rendering pipeline ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1824/files - new: https://git.openjdk.org/jfx/pull/1824/files/9634aafe..ca8b6af0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=00-01 Stats: 8639 lines in 103 files changed: 7798 ins; 602 del; 239 mod Patch: https://git.openjdk.org/jfx/pull/1824.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824 PR: https://git.openjdk.org/jfx/pull/1824 From tsayao at openjdk.org Thu Jun 19 12:26:42 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 19 Jun 2025 12:26:42 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v38] In-Reply-To: References: Message-ID: <2IhwWW94l59aAsENrPo0LdFjGzx5Qaev1JZVbaxF4Cw=.538a1265-36c0-4e37-9a92-3a0ee75a713e@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. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... 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 45 commits: - Merge branch 'master' into 8354943 - Fixes and geometry fixes - Use a small C++ Observable implementation to notify values to java only when they change - - Minor adjustments - - Configure optimizations - - Fix motion request - - Rollback unnecessary changes - Fix mistakes when merging - - Merge JavaFX controls on the title bar - Rename test methods - Merge branch 'master' into 8354943 # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp # modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h # modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp # modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h - Merge branch 'master' into 8354943 - ... and 35 more: https://git.openjdk.org/jfx/compare/fc4642db...28db9a56 ------------- Changes: https://git.openjdk.org/jfx/pull/1789/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=37 Stats: 4240 lines in 29 files changed: 2861 ins; 794 del; 585 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 jhendrikx at openjdk.org Thu Jun 19 12:48:06 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 19 Jun 2025 12:48:06 GMT Subject: RFR: 8351867: No UI changes while iconified [v4] In-Reply-To: References: Message-ID: > Adds code to trigger a scene update when a Window is restored > > This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479 John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Also repaint when going to maximized ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1733/files - new: https://git.openjdk.org/jfx/pull/1733/files/2539511b..c8d199cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=02-03 Stats: 35 lines in 1 file changed: 15 ins; 18 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1733.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1733/head:pull/1733 PR: https://git.openjdk.org/jfx/pull/1733 From tsayao at openjdk.org Thu Jun 19 12:52:18 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 19 Jun 2025 12:52:18 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v39] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add test to stage icon (manual) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/28db9a56..92e8b152 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=38 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=37-38 Stats: 21 lines in 1 file changed: 17 ins; 2 del; 2 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 jdv at openjdk.org Thu Jun 19 14:02:57 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 19 Jun 2025 14:02:57 GMT Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v2] In-Reply-To: References: <3kas-_2sLVoXg1Mz5j57auwRgghF6WWb3kXSRgSOajM=.636a07f8-b464-40bc-b33d-12234e3e6e63@github.com> Message-ID: On Wed, 18 Jun 2025 21:48:22 GMT, Martin Fox wrote: >> @jayathirthrao Thanks for the thorough response. And, again, it's great to see Metal happening. >> >>> * GlassView3D -> GlassViewEventHandler(Since it is common class which handles events for both OpenGL and Metal pipeline) Or GlassSubView(Since it is added as subView in GlassHostView in GlassView.m). Please suggest if you have better names that we can use here. >> >> I want to keep the GlassView prefix since these classes implement the platform side of the View class in the toolkit. If we were to rename anything it would be GlassViewCGL and GlassViewMTL since these are more closely related to Prism than the toolkit View class. But I'm overthinking things. For now I think we should keep GlassView and GlassView3D along with GlassViewCGL and GlassViewMTL and just clarify what's going on in the comments. At some point I want to combine GlassView and GlassView3D into one class but that can wait for a follow-up issue. >> >>> 4. Regarding setOpaque() in GlassWindow.m >> >> In my testing the setOpaque call isn't happening in this PR since the layer hasn't been created yet. But it doesn't seem to matter (?) >> >> I'm having a hard time reproducing the original PickTest3D bug in the master branch. The screenshots in the bug report show translucency but the original bug report doesn't mention it and the PickTest3D code doesn't call for it. I tweaked PickTest3D to try a few combinations of setOpacity and DECORATED/TRANSPARENT and that setOpaque call didn't seem to make any difference even in the master branch. I must be missing something. >> >> As for the UNIFIED issue I don't think there's a bug. The implementation relied on the OS to draw a brushed metal background but Apple removed that years ago and now just draws black. I will take a look but only because I want to understand how this works; we might need similar logic if we want to support desktop translucency effects. UNIFIED is deprecated and doesn't work on Windows either so we should probably close the new bug as Never Fix. > >> I'm having a hard time reproducing the original PickTest3D bug in the master branch. > > Spoke too soon. PickTest3D has been tweaked since the original Mac bug was posted and resolved. @beldenfox Found out the root cause for why we are seeing layer as nil GlassWindow.m. We have additional level of abstraction for views and we set layer for GlassViewCGL/MTL and not for GlassView3D. We already have change in GlassView.m->getGlassView() to get GlassView3D object and then call getLayer() on it. We need to make similar change in GlassWindow.m->getMacView(), with this change we are able to get appropriate layer by calling getLayer(). This change is made and testing is in progress. Also what i am also noticing is setOpaque() in GlassWindow.m is never called on OpenGL pipeline when i run Ensemble8 demos, PickTest3D or test present in [JDK-8095040](https://bugs.openjdk.org/browse/JDK-8095040). I will keep this OpenGL specific setOpaque call since we don't want to make changes related to OpenGL in this PR. But i will add comment about refactoring and moving it to CGL specific class in future. Regarding classname change, i will keep GlassView3D name as it is but remove 3D references in other classes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-2988208764 From duke at openjdk.org Thu Jun 19 14:26:48 2025 From: duke at openjdk.org (Pabulaner IV) Date: Thu, 19 Jun 2025 14:26:48 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 20:58:20 GMT, Pabulaner IV wrote: > This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX. > > The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method. > > The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus. > > I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it works without any errors. > > Co-Author: @FlorianKirmaier If You mean it why I didn't fix it there the answer is that when You have for example two screens and You switch from a Swing window that is in the first screen to a other unrelated window in another screen, the menu bar should stay in the first screen. If Swing would remove the menu items on focus loss, this menu would be gone as well. If You mean it as a edge case and if my code would handle it correctly, it would, as it just removes all items not owned by JavaFX and so if there are no menus that fall in that category, it simply will do nothing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-2988282653 From tsayao at openjdk.org Thu Jun 19 15:10:23 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 19 Jun 2025 15:10:23 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v40] In-Reply-To: References: Message-ID: > This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend. > > > Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management. > > List of changes: > 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size. > 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead. > 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped); > 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility; > 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) > 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages; > 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; > 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. > > A simple manual test is provided: > `java @build/run.args tests/manual/stage/TestStage.java ` > > > List of fixed issues: > > 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425) > 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891) > 4. [[Linux] Initial window pos... Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix popup autohide problem (focus) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1789/files - new: https://git.openjdk.org/jfx/pull/1789/files/92e8b152..4bea0ba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=39 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=38-39 Stats: 10 lines in 1 file changed: 5 ins; 4 del; 1 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 mstrauss at openjdk.org Thu Jun 19 17:19:35 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 19 Jun 2025 17:19:35 GMT Subject: RFR: 8359601: Fix window button states of an extended stage [v3] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:41:54 GMT, Michael Strau? wrote: >> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms: >> >> #### Windows 11 >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | visible, disabled | visible | >> | resizable, modal | visible, disabled | visible | visible | >> | not resizable, modal | hidden | hidden | visible, utility-style | >> >> #### Ubuntu 24 / Fedora 41 (GNOME) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible, _not working_ | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> #### Kubuntu 24 (KDE) >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | visible | visible | visible | >> | not resizable, not modal | visible | hidden | visible | >> | resizable, modal | visible, _not working_ | visible | visible | >> | not resizable, modal | visible, _not working_ | hidden | visible | >> >> ## Observations >> >> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes. >> * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden) >> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible. >> * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?) >> >> ## Permitted window button operations >> >> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes: >> >> | Window attributes | Iconify | Maximize | Close | >> |---|---|---|---| >> | resizable, not modal | yes | yes | yes | >> | not resizable, not modal | yes | no | yes | >> | resizable, modal | no | yes | yes | >> | not resizable, modal | no | no | yes | >> >> ## Fixes >> >> This PR includes the following changes: >> 1. Unused code relating to window modality is removed... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small refactor > JavaFX modal windows are not native modals, as evidenced by the code removal on this PR (it's not used) . On GNOME, native modal windows automatically remove the minimize and maximize buttons. > > I did an experiment and found that it's possible to get native modal windows (at least with GTK Glass) by passing the modality flag from `WindowStage` to `createWindow`. I haven?t done extensive testing, but it seems to work - likely because the modality can?t be changed afterward. That's a good idea for an enhancement. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-2988750400 From mfox at openjdk.org Thu Jun 19 17:43:30 2025 From: mfox at openjdk.org (Martin Fox) Date: Thu, 19 Jun 2025 17:43:30 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 20:58:20 GMT, Pabulaner IV wrote: > This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX. > > The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method. > > The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus. > > I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it works without any errors. > > Co-Author: @FlorianKirmaier Any fix that happens inside Glass is the wrong fix. I think I have an idea of what?s happening under the hood with this PR. When a JavaFX window loses focus JavaFX removes most of the items from NSApp.mainMenu. I suppose when the Swing window gains focus Swing is re-writing most of NSApp.mainMenu without JavaFX knowing about it. And the same thing is happening when focus moves from a Swing window to a JavaFX window. So window focus is being used as an informal protocol to determine whether Swing or JavaFX controls *most* of the system menu. This will all break down with the application menu, the first menu in the menu bar after the Apple logo menu. That one requires special handling since it must be present at all times. JavaFX sets that up once and never touches it again. I don?t know how Swing handles this menu but I?m guessing it does something similar. It looks like this PR is removing the Swing items from the application menu so JavaFX can re-populate it. Or something like that. It doesn?t matter. If you want Swing and JavaFX to coordinate on the system menu there needs to be a formal protocol for doing so and that formal protocol must take into account the special needs of the application menu. Neither system should be messing around at the platform level adding and removing the other guy?s menu items. JavaFX is not designed to support that sort of manipulation and I doubt Swing is either. If it works it?s entirely by accident. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-2988787155