From arapte at openjdk.org Thu Jan 2 13:19:55 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Jan 2025 13:19:55 GMT Subject: RFR: 8315873: [GHA] Update checkout and cache action to use v4 Message-ID: In GHA, the two actions `checkout` and `cache` need to be updated to version 4. **Checkout action** - The Node is updated to version 20. - We do not explicitly specify node version - But we use the action checkout, which should be updated to latest version as advised. - With checkout at v4, GHA would use node 20. - Although, apart from warning we may not see any real issue, as we don?t use node and don?t specify any version. - End of life for Actions Node16 : https://github.blog/changelog/2024-09-25-end-of-life-for-actions-node16/ - GitHub Actions: Transitioning from Node 16 to Node 20: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/ - Updated dates for Actions runner using Node20 instead of Node16 by default: https://github.blog/changelog/2024-05-17-updated-dates-for-actions-runner-using-node20-instead-of-node16-by-default/ - Action checkout version 4.00 Release note: https://github.com/actions/checkout/releases/tag/v4.0.0 **Cache action** - Currently we use action cache version 2, for Windows build - Cache v1-v2 will be deprecated starting February 1st, 2025 - Our workflow will start to fail on windows, starting Feb 1st, 2025 - Refer: Notice of upcoming deprecations and changes in GitHub Actions services: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/ - Refer: Important changes under What?s new : https://github.com/actions/cache Verification: 1. The build should complete successfully on all platforms. 2. **cache action**: In GitHub actions, it showed a warning related to `cache` action: See the Windows x64 related warning on any recent build under actions tab : https://github.com/arapte/jfx/actions/runs/12428608806 **Warning message:** `Your workflow is using a version of actions/cache that is scheduled for deprecation, actions/cache at v2. Please update your workflow to use the latest version of actions/cache to avoid interruptions. Learn more: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/` This warning disappears with this change: https://github.com/arapte/jfx/actions/runs/12581903371 3. **checkout action**: no specific check point. ------------- Commit messages: - gha actions/cache v4 - commented - gha actions/cache v4 - gha checkout v4 Changes: https://git.openjdk.org/jfx/pull/1669/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1669&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315873 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1669.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1669/head:pull/1669 PR: https://git.openjdk.org/jfx/pull/1669 From lkostyra at openjdk.org Thu Jan 2 16:10:55 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 2 Jan 2025 16:10:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: <5tzXUi-81r0r25EhSct8xVowwmO_Jmsltzl0okGv5Ew=.5e9b6ec1-9224-468c-bfef-c918313d060b@github.com> On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset Checked my sections and gave it some random testing, all looks good. Good work @andy-goryachev-oracle ! Raising the limit to include my "R"eviewing of: - jfx.incubator.scene.control.richtext - jfx.incubator.scene.control.richtext.skin ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2527832433 PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2568007801 From lkostyra at openjdk.org Fri Jan 3 14:06:04 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 3 Jan 2025 14:06:04 GMT Subject: RFR: 8342233: Regression: TextInputControl selection is backwards in RTL mode In-Reply-To: References: Message-ID: <4YWmb2M2t3ZZGTlm_Vx1X5izHQcjLY2U8yMmBP_j5GU=.aa54fc5e-d593-473a-90b8-e4c946a29e05@github.com> On Fri, 25 Oct 2024 22:00:37 GMT, Andy Goryachev wrote: > A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode. > > The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`. > > The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266). > > --- > > I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167) > > The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) . Looks good ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1609#pullrequestreview-2529131932 From angorya at openjdk.org Mon Jan 6 16:50:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Jan 2025 16:50:47 GMT Subject: Integrated: 8342233: Regression: TextInputControl selection is backwards in RTL mode In-Reply-To: References: Message-ID: <1OrJxmtyYrlCgI3q6fEUuLSUd3eB4usTMbcKapQoPyc=.66d560e6-6c33-44e1-886a-1d2cd7d31832@github.com> On Fri, 25 Oct 2024 22:00:37 GMT, Andy Goryachev wrote: > A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode. > > The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`. > > The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266). > > --- > > I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167) > > The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) . This pull request has now been integrated. Changeset: 98916fee Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/98916feed6a9ff4da63ff778fdb0336d43ffaca8 Stats: 610 lines in 8 files changed: 559 ins; 23 del; 28 mod 8342233: Regression: TextInputControl selection is backwards in RTL mode Reviewed-by: kizune, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1609 From mstrauss at openjdk.org Mon Jan 6 19:32:42 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 6 Jan 2025 19:32:42 GMT Subject: Integrated: 8343398: Add reducedData preference In-Reply-To: References: Message-ID: <9zgcpuxvTT93JLJeCzcy5LIH6Xpqh4xYYy2pVl_JNDw=.65202097-fbba-4da2-b153-44f2210f75c4@github.com> On Tue, 3 Dec 2024 15:17:19 GMT, Michael Strau? wrote: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. This pull request has now been integrated. Changeset: 76d5e1ae Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/76d5e1ae1c396442dce095063cea7bcaff4cd497 Stats: 551 lines in 20 files changed: 342 ins; 76 del; 133 mod 8343398: Add reducedData preference Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1656 From angorya at openjdk.org Mon Jan 6 19:41:39 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Jan 2025 19:41:39 GMT Subject: RFR: 8315873: [GHA] Update checkout and cache action to use v4 In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 13:16:00 GMT, Ambarish Rapte wrote: > In GHA, the two actions `checkout` and `cache` need to be updated to version 4. > > **Checkout action** > > - The Node is updated to version 20. > - We do not explicitly specify node version > - But we use the action checkout, which should be updated to latest version as advised. > - With checkout at v4, GHA would use node 20. > - Although, apart from warning we may not see any real issue, as we don?t use node and don?t specify any version. > - End of life for Actions Node16 : https://github.blog/changelog/2024-09-25-end-of-life-for-actions-node16/ > - GitHub Actions: Transitioning from Node 16 to Node 20: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/ > - Updated dates for Actions runner using Node20 instead of Node16 by default: https://github.blog/changelog/2024-05-17-updated-dates-for-actions-runner-using-node20-instead-of-node16-by-default/ > - Action checkout version 4.00 Release note: https://github.com/actions/checkout/releases/tag/v4.0.0 > > **Cache action** > - Currently we use action cache version 2, for Windows build > - Cache v1-v2 will be deprecated starting February 1st, 2025 > - **Our workflow could start to FAIL on Windows, starting Feb 1st, 2025** > - Refer: Notice of upcoming deprecations and changes in GitHub Actions services: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/ > - Refer: Important changes under What?s new : https://github.com/actions/cache > > > Verification: > 1. The build should complete successfully on all platforms. > 2. **cache action**: In GitHub actions, it showed a warning related to `cache` action: See the Windows x64 related warning on any recent build under actions tab : https://github.com/arapte/jfx/actions/runs/12428608806 > **Warning message:** > `Your workflow is using a version of actions/cache that is scheduled for deprecation, actions/cache at v2. Please update your workflow to use the latest version of actions/cache to avoid interruptions. Learn more: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/` > This warning disappears with this change: https://github.com/arapte/jfx/actions/runs/12581903371 > 3. **checkout action**: no specific check point. - GHA runs succeed on all platforms, as evident from this PR - there are no more checkout@ and cache@ patterns in submit.yml ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1669#pullrequestreview-2532839049 From jvos at openjdk.org Tue Jan 7 09:04:55 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 7 Jan 2025 09:04:55 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction @jperedadnr can you review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2574742199 From kcr at openjdk.org Tue Jan 7 13:45:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Jan 2025 13:45:44 GMT Subject: RFR: 8315873: [GHA] Update checkout and cache action to use v4 In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 13:16:00 GMT, Ambarish Rapte wrote: > In GHA, the two actions `checkout` and `cache` need to be updated to version 4. > > **Checkout action** > > - The Node is updated to version 20. > - We do not explicitly specify node version > - But we use the action checkout, which should be updated to latest version as advised. > - With checkout at v4, GHA would use node 20. > - Although, apart from warning we may not see any real issue, as we don?t use node and don?t specify any version. > - End of life for Actions Node16 : https://github.blog/changelog/2024-09-25-end-of-life-for-actions-node16/ > - GitHub Actions: Transitioning from Node 16 to Node 20: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/ > - Updated dates for Actions runner using Node20 instead of Node16 by default: https://github.blog/changelog/2024-05-17-updated-dates-for-actions-runner-using-node20-instead-of-node16-by-default/ > - Action checkout version 4.00 Release note: https://github.com/actions/checkout/releases/tag/v4.0.0 > > **Cache action** > - Currently we use action cache version 2, for Windows build > - Cache v1-v2 will be deprecated starting February 1st, 2025 > - **Our workflow could start to FAIL on Windows, starting Feb 1st, 2025** > - Refer: Notice of upcoming deprecations and changes in GitHub Actions services: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/ > - Refer: Important changes under What?s new : https://github.com/actions/cache > > > Verification: > 1. The build should complete successfully on all platforms. > 2. **cache action**: In GitHub actions, it showed a warning related to `cache` action: See the Windows x64 related warning on any recent build under actions tab : https://github.com/arapte/jfx/actions/runs/12428608806 > **Warning message:** > `Your workflow is using a version of actions/cache that is scheduled for deprecation, actions/cache at v2. Please update your workflow to use the latest version of actions/cache to avoid interruptions. Learn more: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/` > This warning disappears with this change: https://github.com/arapte/jfx/actions/runs/12581903371 > 3. **checkout action**: no specific check point. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1669#pullrequestreview-2534371691 From arapte at openjdk.org Tue Jan 7 13:50:42 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 7 Jan 2025 13:50:42 GMT Subject: Integrated: 8315873: [GHA] Update checkout and cache action to use v4 In-Reply-To: References: Message-ID: <5LYyAkIbSMOf7lX9-MiZyJzKndEUdugAzVjTiEfa-Mg=.a4edc139-7754-40ef-85c5-9357b01cf641@github.com> On Thu, 2 Jan 2025 13:16:00 GMT, Ambarish Rapte wrote: > In GHA, the two actions `checkout` and `cache` need to be updated to version 4. > > **Checkout action** > > - The Node is updated to version 20. > - We do not explicitly specify node version > - But we use the action checkout, which should be updated to latest version as advised. > - With checkout at v4, GHA would use node 20. > - Although, apart from warning we may not see any real issue, as we don?t use node and don?t specify any version. > - End of life for Actions Node16 : https://github.blog/changelog/2024-09-25-end-of-life-for-actions-node16/ > - GitHub Actions: Transitioning from Node 16 to Node 20: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/ > - Updated dates for Actions runner using Node20 instead of Node16 by default: https://github.blog/changelog/2024-05-17-updated-dates-for-actions-runner-using-node20-instead-of-node16-by-default/ > - Action checkout version 4.00 Release note: https://github.com/actions/checkout/releases/tag/v4.0.0 > > **Cache action** > - Currently we use action cache version 2, for Windows build > - Cache v1-v2 will be deprecated starting February 1st, 2025 > - **Our workflow could start to FAIL on Windows, starting Feb 1st, 2025** > - Refer: Notice of upcoming deprecations and changes in GitHub Actions services: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/ > - Refer: Important changes under What?s new : https://github.com/actions/cache > > > Verification: > 1. The build should complete successfully on all platforms. > 2. **cache action**: In GitHub actions, it showed a warning related to `cache` action: See the Windows x64 related warning on any recent build under actions tab : https://github.com/arapte/jfx/actions/runs/12428608806 > **Warning message:** > `Your workflow is using a version of actions/cache that is scheduled for deprecation, actions/cache at v2. Please update your workflow to use the latest version of actions/cache to avoid interruptions. Learn more: https://github.blog/changelog/2024-09-16-notice-of-upcoming-deprecations-and-changes-in-github-actions-services/` > This warning disappears with this change: https://github.com/arapte/jfx/actions/runs/12581903371 > 3. **checkout action**: no specific check point. This pull request has now been integrated. Changeset: 6ec588c5 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/6ec588c5635964769b354bce37e68d7a6c00985a Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod 8315873: [GHA] Update checkout and cache action to use v4 Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1669 From mmack at openjdk.org Tue Jan 7 18:09:53 2025 From: mmack at openjdk.org (Markus Mack) Date: Tue, 7 Jan 2025 18:09:53 GMT Subject: RFR: 8342703: CSS transition is not started when initial value was not specified [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 17:49:37 GMT, Michael Strau? wrote: >> When the initial value of a styleable property is not specified in a stylesheet, no transition is started: >> >> .button { >> transition: -fx-opacity 1s; >> } >> >> .button:hover { >> -fx-opacity: 0.5; >> } >> >> The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1. >> >> The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time. >> >> The logic to detect this situation is currently as follows: >> >> // If this.origin == null, we're setting the value for the first time. >> // No transition should be started in this case. >> TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ? >> NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null; >> >> >> However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this: >> >> A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied: >> 1. The node was added to a scene graph >> 2. CSS processing was completed for a scene pulse > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into fixes/css-initial-value > - use HashSet instead of IdentityHashMap > - start transitions only when not in initial CSS state I did some testing, adding transitions to css properties that have no explicit initial values in css. The issue is clearly reproducible with the current master, and fixed with this PR. One thing I noticed is that transitions of "-fx-background-insets" jump without a smooth animation. Probably this is due to a difference in the number of list elements (-fx-background-insets is an array), which does not seem to have animation support (yet), so it's not an issue with this PR. Code changes look good as well, I see the addition to `Node` has already been discussed. ------------- Marked as reviewed by mmack (Author). PR Review: https://git.openjdk.org/jfx/pull/1607#pullrequestreview-2535062218 From angorya at openjdk.org Tue Jan 7 20:38:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 Jan 2025 20:38:49 GMT Subject: RFR: 8342703: CSS transition is not started when initial value was not specified [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 17:49:37 GMT, Michael Strau? wrote: >> When the initial value of a styleable property is not specified in a stylesheet, no transition is started: >> >> .button { >> transition: -fx-opacity 1s; >> } >> >> .button:hover { >> -fx-opacity: 0.5; >> } >> >> The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1. >> >> The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time. >> >> The logic to detect this situation is currently as follows: >> >> // If this.origin == null, we're setting the value for the first time. >> // No transition should be started in this case. >> TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ? >> NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null; >> >> >> However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this: >> >> A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied: >> 1. The node was added to a scene graph >> 2. CSS processing was completed for a scene pulse > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into fixes/css-initial-value > - use HashSet instead of IdentityHashMap > - start transitions only when not in initial CSS state can see the transitions failing in master with the monkey tester, and running as expected with this fix. left one minor suggestion - will re-approve should you decide to make the change. modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 74: > 72: public void applyStyle(StyleOrigin origin, Boolean v) { > 73: // If the value is applied for the first time, we don't start a transition. > 74: TransitionDefinition transition = getBean() instanceof Node node && !NodeHelper.isInitialCssState(node) ? minor: to simplify the code in many places, you could change `isInitialState` to accept an `Object` argument instead of `Node` and do an `instanceof` there. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1607#pullrequestreview-2535277219 PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1905986753 From mstrauss at openjdk.org Tue Jan 7 20:51:43 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Jan 2025 20:51:43 GMT Subject: RFR: 8342703: CSS transition is not started when initial value was not specified [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 20:11:46 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into fixes/css-initial-value >> - use HashSet instead of IdentityHashMap >> - start transitions only when not in initial CSS state > > modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 74: > >> 72: public void applyStyle(StyleOrigin origin, Boolean v) { >> 73: // If the value is applied for the first time, we don't start a transition. >> 74: TransitionDefinition transition = getBean() instanceof Node node && !NodeHelper.isInitialCssState(node) ? > > minor: to simplify the code in many places, you could change `isInitialState` to accept an `Object` argument instead of `Node` and do an `instanceof` there. I don't think this would work, since we need the `Node`-typed `node` variable as an argument for `NodeHelper.findTransitionDefinition`, so we can't remove the `instanceof` test here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1906022456 From angorya at openjdk.org Tue Jan 7 20:54:43 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 Jan 2025 20:54:43 GMT Subject: RFR: 8342703: CSS transition is not started when initial value was not specified [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 20:49:20 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 74: >> >>> 72: public void applyStyle(StyleOrigin origin, Boolean v) { >>> 73: // If the value is applied for the first time, we don't start a transition. >>> 74: TransitionDefinition transition = getBean() instanceof Node node && !NodeHelper.isInitialCssState(node) ? >> >> minor: to simplify the code in many places, you could change `isInitialState` to accept an `Object` argument instead of `Node` and do an `instanceof` there. > > I don't think this would work, since we need the `Node`-typed `node` variable as an argument for `NodeHelper.findTransitionDefinition`, so we can't remove the `instanceof` test here. NodeHelper: public static boolean isInitialCssState(Object node) { if(node instanceof Node n) { return nodeAccessor.isInitialCssState(n); } return false; } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1906025294 From angorya at openjdk.org Tue Jan 7 21:00:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 Jan 2025 21:00:47 GMT Subject: RFR: 8342703: CSS transition is not started when initial value was not specified [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 20:52:15 GMT, Andy Goryachev wrote: >> I don't think this would work, since we need the `Node`-typed `node` variable as an argument for `NodeHelper.findTransitionDefinition`, so we can't remove the `instanceof` test here. > > NodeHelper: > > > public static boolean isInitialCssState(Object node) { > if(node instanceof Node n) { > return nodeAccessor.isInitialCssState(n); > } > return false; > } or better yet, move the instanceof and get initialCssState logic to NodeHelper.findTransitionDefinition() ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1906031693 From kcr at openjdk.org Tue Jan 7 21:15:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Jan 2025 21:15:51 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. I can review / test this tomorrow. There are various cases to consider even without changing the scale, and we need to confirm that there are no regressions. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2576229641 From mstrauss at openjdk.org Tue Jan 7 21:16:45 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Jan 2025 21:16:45 GMT Subject: RFR: 8342703: CSS transition is not started when initial value was not specified [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 20:57:32 GMT, Andy Goryachev wrote: >> NodeHelper: >> >> >> public static boolean isInitialCssState(Object node) { >> if(node instanceof Node n) { >> return nodeAccessor.isInitialCssState(n); >> } >> return false; >> } > > or better yet, move the instanceof and get initialCssState logic to NodeHelper.findTransitionDefinition() I'll see whether I can refactor these methods a bit, but not as part of this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1906046323 From mstrauss at openjdk.org Tue Jan 7 21:16:45 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Jan 2025 21:16:45 GMT Subject: Integrated: 8342703: CSS transition is not started when initial value was not specified In-Reply-To: References: Message-ID: <9KJxF5dXwyXYmRKUC2dYclJqd0Bk2lgRPOsPKJKCR6c=.ca249ca8-ed16-456a-a8bc-9d1132a9808e@github.com> On Mon, 21 Oct 2024 15:32:28 GMT, Michael Strau? wrote: > When the initial value of a styleable property is not specified in a stylesheet, no transition is started: > > .button { > transition: -fx-opacity 1s; > } > > .button:hover { > -fx-opacity: 0.5; > } > > The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1. > > The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time. > > The logic to detect this situation is currently as follows: > > // If this.origin == null, we're setting the value for the first time. > // No transition should be started in this case. > TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ? > NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null; > > > However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this: > > A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied: > 1. The node was added to a scene graph > 2. CSS processing was completed for a scene pulse This pull request has now been integrated. Changeset: 5b074c4c Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/5b074c4c2b4f539301813322a6589cec28121553 Stats: 178 lines in 13 files changed: 152 ins; 8 del; 18 mod 8342703: CSS transition is not started when initial value was not specified Reviewed-by: mmack, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1607 From kizune at openjdk.org Tue Jan 7 21:24:03 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 7 Jan 2025 21:24:03 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/EventHandlerPriority.java line 36: > 34: USER_KB(5000), > 35: SKIN_KB(4000), > 36: SKIN_HIGH(3000), Just curious about the logic behind the priorities. Like why for skin kb (is it keyboard?) if above the high priority but for user high is about kb? I understand that this is just a search order in which event handlers will be called and if higher priority handler consumes event it will not be proposed to the next priority level handler? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1906053012 From kcr at openjdk.org Tue Jan 7 21:31:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Jan 2025 21:31:40 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. As a quick note, when the multi-monitor support was added for HiDPI, the code to check `WM_DPICHANGED` was intentionally removed. See [this comment in JDK-8146920](https://bugs.openjdk.org/browse/JDK-8146920?focusedId=14034147&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14034147). I'll look closer when I review it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2576255138 From angorya at openjdk.org Tue Jan 7 21:31:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 Jan 2025 21:31:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 7 Jan 2025 21:20:39 GMT, Alexander Zuev wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> added html charset > > modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/EventHandlerPriority.java line 36: > >> 34: USER_KB(5000), >> 35: SKIN_KB(4000), >> 36: SKIN_HIGH(3000), > > Just curious about the logic behind the priorities. Like why for skin kb (is it keyboard?) if above the high priority but for user high is about kb? I understand that this is just a search order in which event handlers will be called and if higher priority handler consumes event it will not be proposed to the next priority level handler? excellent question! the idea is to have the handler for key bindings (KB) to be checked before other skin handlers, which typically deal with multiple keys or catch-all cases. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1906062787 From jpereda at openjdk.org Tue Jan 7 22:21:41 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 7 Jan 2025 22:21:41 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 21:29:17 GMT, Kevin Rushforth wrote: >> This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. >> >> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. >> >> There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. >> >> There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. > > As a quick note, when the multi-monitor support was added for HiDPI, the code to check `WM_DPICHANGED` was intentionally removed. See [this comment in JDK-8146920](https://bugs.openjdk.org/browse/JDK-8146920?focusedId=14034147&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14034147). I'll look closer when I review it. Thanks for the link @kevinrushforth , it helps a lot clarifying a few things. I didn't find issues with `WM_DPICHANGED` (yet), but I didn't test those edge cases that are mentioned. I see several different issues related to DPI changes (with and without my patch), and I can reproduce the issue that @andy-goryachev-oracle mentioned, so definitely this PR needs more work, and probably some follow-ups. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2576337387 From kcr at openjdk.org Tue Jan 7 22:33:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 Jan 2025 22:33:46 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v5] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 20:02:15 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > whitespace error The doc changes look good to me. Can you create a CSR? Also can you please merge in the latest master (it's pretty out of date by now)? I'll review the implementation and also test it. @andy-goryachev-oracle or @hjohn Can one of you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2576353140 From mstrauss at openjdk.org Wed Jan 8 01:29:29 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 01:29:29 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into feature/root-pseudo-class - whitespace error - add child-indexed pseudo-classes - add pseudo-class table to Parent - update cssref - Set :root pseudo-class on sub-scene root node - Set :root pseudo-class on root node ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/afb5fa40..0939d1d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=04-05 Stats: 4514 lines in 771 files changed: 1808 ins; 793 del; 1913 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From aghaisas at openjdk.org Wed Jan 8 04:37:54 2025 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 8 Jan 2025 04:37:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset Marked as reviewed by aghaisas (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2535977218 From duke at openjdk.org Wed Jan 8 04:37:55 2025 From: duke at openjdk.org (Pascal) Date: Wed, 8 Jan 2025 04:37:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 46: > 44: * @since 24 > 45: */ > 46: public class KeyBinding There's also existing classes like `javafx.scene.input.KeyCodeCombination`, which have a different API. Will it increase maintenance burden and/or cause more friction for users to have two different APIs for a very similar purpose? Are there plans to consolidate these APIs in the future? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1905876586 From jhendrikx at openjdk.org Wed Jan 8 12:16:53 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 8 Jan 2025 12:16:53 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 01:29:29 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into feature/root-pseudo-class > - whitespace error > - add child-indexed pseudo-classes > - add pseudo-class table to Parent > - update cssref > - Set :root pseudo-class on sub-scene root node > - Set :root pseudo-class on root node modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1530: > 1528:

In the following example, all background color of all buttons uses the > 1529: looked up color "abc".

> 1530:

:root { abc: #f00 }
I see many places where `.root` is removed in favor of `:root`, but both are supported still? At least, the code in `Scene` leads me to believe that it will also apply the `.root` style class still. Should this legacy style class be mentioned in the CSS documentation still? modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 341: > 339: > 340: @Override > 341: protected void onChanged(Change c) { I hate to bring this up, and it perhaps should be dealt with separately, but how safe is this code in `onProposedChange` / `onChanged` when it is re-entered due to the many potential listener callbacks? For example, the removal of a child on `parent` can trigger list change listeners from the user that can trigger all kinds of other changes that eventually lead to more children changes on this node, triggering a nested `onChanged`; the new changes are adding more opportunities in the form of listeners on pseudo state changes. For example, `onProposedChange` will blatantly reset `geomChanged` to `false` in all cases, even if it rejects the change later. It doesn't check if an `onChange` is in progress higher up the call stack, effectively resetting a flag that is in active use... I believe this may be quite a difficult problem to solve if nested calls remain allowed, and one of the easiest ways to fix it IMHO is to reject any changes (in `onProposedChange`) when a change is already in progress. For users this would effectively mean that listeners triggered during a child modification will not be allowed to make further modifications to the same children list until the first one completes. This is not a common situation, but can happen with very dynamic UI's that construct new nodes in response to triggers; without such protection for nested changes, the errors that crop up are often of a form that seem to be multi-threading issues (where certain invariants seem to be broken), while in reality they're just re-entrant code calls that use instance fields in an unsafe manner. modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 375: > 373: } > 374: > 375: toggleStructuralPseudoClasses(n, List.of()); This (and other `toggleStructuralPseudoClasses` and `pseudoClassStateChanged` calls later) introduces new opportunities for user listener call backs in the middle of a pretty critical code path. `n.getParent().children.remove(n);` a few lines above is also such an opportunity. modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 381: > 379: // the index of the first change to separate unchanged from changed elements. > 380: if (firstDirtyChildIndex < 0) { > 381: firstDirtyChildIndex = from; Does this need some special casing in case the first element is modified indirectly? Let's say I have two elements, I remove the last element. Indirectly, the first element now gets the "only" and "last" pseudo classes; this may need to be communicated as a modification to the peer for example? modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 470: > 468: // Add the "last-child" pseudo-class to the last child. > 469: if (size() > 0) { > 470: getLast().pseudoClassStateChanged(LAST_CHILD_PSEUDO_CLASS, true); These code paths seem to do double work. Would it not be better to treat each flag separately, instead of having some paths manipulate multiple flags, that then may get set/reset again individually? The first `if/else if` in this block will reset all flags, only to have some of them be set/reset again later. This may also lead to listener confusion; let's say I have 2 children. I remove the last child. The "only child" block (`size() == 1`) triggers; it removes the `odd` pseudo class; a listener may trigger on this; however, just a bit later, this `odd` tag is then re-added (at least, I hope it is as I'm not entirely sure the `firstDirtyChildIndex` will be set low enough...) modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 479: > 477: n.pseudoClassStateChanged(NTH_EVEN_CHILD_PSEUDO_CLASS, i % 2 != 0); > 478: n.pseudoClassStateChanged(NTH_ODD_CHILD_PSEUDO_CLASS, i % 2 == 0); > 479: } With this new code, Nodes with many children being manipulated may incur some significant new costs now that these pseudo classes need to be changed for potentially many/all children. Where before adding a new first child mostly had a cost in shifting the child array with a copy, now we also potentially have two listener call backs per child (and I'm unsure, but these may even trigger some CSS recalculations or CSS cache invalidations). Nodes with many children may suffer from this, and mostly needlessly as these pseudo classes will see very limited use. I think there's some potential for performance regression here that is perhaps sufficient to warrant the exclusion of this feature or making it optional. modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 790: > 788: """.getBytes(StandardCharsets.UTF_8))); > 789: > 790: assertNotEquals(Background.fill(Color.RED), root.getBackground()); This is just checking the default state of a stack pane. Would it not be fairer to first set it up in a Scene, with a different stylesheet or no stylesheet, then applying one that uses `:root` and checking the before and after states? modules/javafx.graphics/src/test/java/test/javafx/scene/Parent_pseudoClasses_Test.java line 60: > 58: assertNotPseudoClass(ONLY_CHILD, child1); > 59: assertPseudoClass(ONLY_CHILD, child2); > 60: } How about a case where the last child is removed, and seeing if the first and now only child gets the correct states? I think there currently is definitely a bug where the odd/even may not be reapplied in that case... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907081969 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907034950 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907039143 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907077704 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907061458 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907071898 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907088577 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907090798 From duke at openjdk.org Wed Jan 8 14:00:56 2025 From: duke at openjdk.org (Burning_TNT) Date: Wed, 8 Jan 2025 14:00:56 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v9] In-Reply-To: References: Message-ID: <9fTguI5IyC_SlMKI6SPKbXQMtoNP7fmZx6Fmh6Axj5A=.414e8ae5-101b-40b2-ad2d-ca22e3cdbda5@github.com> On Wed, 4 Dec 2024 21:10:24 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Address minor review observations > Hi, I reproduced this bug on OpenJFX 17.0.10, but not on 17.0.9. Therefore, I think it might be introduced in https://github.com/openjdk/jfx/pull/915. Could you please consider backporting this fix to JavaFX 17? The same as yushijinhun. Sent again as he forgot to accept the content. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2577737286 From angorya at openjdk.org Wed Jan 8 15:33:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 15:33:57 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 7 Jan 2025 18:20:15 GMT, Pascal wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> added html charset > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 46: > >> 44: * @since 24 >> 45: */ >> 46: public class KeyBinding > > There's also existing classes like `javafx.scene.input.KeyCodeCombination`, which have a different API. Will it increase maintenance burden and/or cause more friction for users to have two different APIs for a very similar purpose? Are there plans to consolidate these APIs in the future? Good question! I've decided to create a new class for the incubator for two main reasons: 1. the only way to construct `KeyCombination` is from a `String`, which incurs the penalty of parsing 2. `KeyCombination` does not differentiate key pressed / key released / key typed events While 1) can be easily addressed by adding a Builder, introducing 2) may cause issues with the existing code, since `KeyCombination` is an existing public API. Any suggestions? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1907377236 From duke at openjdk.org Wed Jan 8 16:49:51 2025 From: duke at openjdk.org (Pascal) Date: Wed, 8 Jan 2025 16:49:51 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: <9B-s3f3O7c2J7WJWw_zFctYBolOiPW-EbyTzwtTP5JA=.b2070a50-a9bc-41ec-bf47-1eb1e41000fb@github.com> On Wed, 8 Jan 2025 15:30:57 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 46: >> >>> 44: * @since 24 >>> 45: */ >>> 46: public class KeyBinding >> >> There's also existing classes like `javafx.scene.input.KeyCodeCombination`, which have a different API. Will it increase maintenance burden and/or cause more friction for users to have two different APIs for a very similar purpose? Are there plans to consolidate these APIs in the future? > > Good question! > > I've decided to create a new class for the incubator for two main reasons: > 1. the only way to construct `KeyCombination` is from a `String`, which incurs the penalty of parsing > 2. `KeyCombination` does not differentiate key pressed / key released / key typed events > > While 1) can be easily addressed by adding a Builder, introducing 2) may cause issues with the existing code, since `KeyCombination` is an existing public API. > > Any suggestions? `KeyCombination` is just the abstract base class. Subclasses like `javafx.scene.input.KeyCodeCombination` provide normal constructors without any parsing: public KeyCodeCombination(final @NamedArg("code") KeyCode code, final @NamedArg("modifiers") Modifier... modifiers) { /* ... */ } The abstract class provides a _match_ method which subclasses can (and do) override, so it could be possible to create a subclass that implements the method based on pressed/typed: @Override public boolean match(final KeyEvent event) { // KeyEvent has e.g. KEY_PRESSED and KEY_RELEASED, so should be possible to check here... return checkPressedReleasedTyped(event) && super.match(event); } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1907491055 From mstrauss at openjdk.org Wed Jan 8 17:28:35 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 17:28:35 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v7] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: refactoring, add tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/0939d1d0..3c694165 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=05-06 Stats: 525 lines in 4 files changed: 351 ins; 150 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From mstrauss at openjdk.org Wed Jan 8 17:30:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 17:30:17 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 12:05:56 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into feature/root-pseudo-class >> - whitespace error >> - add child-indexed pseudo-classes >> - add pseudo-class table to Parent >> - update cssref >> - Set :root pseudo-class on sub-scene root node >> - Set :root pseudo-class on root node > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1530: > >> 1528:

In the following example, all background color of all buttons uses the >> 1529: looked up color "abc".

>> 1530:

:root { abc: #f00 }
> > I see many places where `.root` is removed in favor of `:root`, but both are supported still? At least, the code in `Scene` leads me to believe that it will also apply the `.root` style class still. Should this legacy style class be mentioned in the CSS documentation still? It will still be supported for backwards compatibility, but I see no reason to mention that now that we have the standard-conformant `:root` pseudo-class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907546471 From mstrauss at openjdk.org Wed Jan 8 17:35:03 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 17:35:03 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 12:02:45 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into feature/root-pseudo-class >> - whitespace error >> - add child-indexed pseudo-classes >> - add pseudo-class table to Parent >> - update cssref >> - Set :root pseudo-class on sub-scene root node >> - Set :root pseudo-class on root node > > modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 381: > >> 379: // the index of the first change to separate unchanged from changed elements. >> 380: if (firstDirtyChildIndex < 0) { >> 381: firstDirtyChildIndex = from; > > Does this need some special casing in case the first element is modified indirectly? Let's say I have two elements, I remove the last element. Indirectly, the first element now gets the "only" and "last" pseudo classes; this may need to be communicated as a modification to the peer for example? As long as the pseudoclasses are set correctly with `pseudoClassStateChanged`, the peers will be notified as necessary. I don't think there is any special-casing required here. > modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 470: > >> 468: // Add the "last-child" pseudo-class to the last child. >> 469: if (size() > 0) { >> 470: getLast().pseudoClassStateChanged(LAST_CHILD_PSEUDO_CLASS, true); > > These code paths seem to do double work. Would it not be better to treat each flag separately, instead of having some paths manipulate multiple flags, that then may get set/reset again individually? The first `if/else if` in this block will reset all flags, only to have some of them be set/reset again later. > > This may also lead to listener confusion; let's say I have 2 children. I remove the last child. The "only child" block (`size() == 1`) triggers; it removes the `odd` pseudo class; a listener may trigger on this; however, just a bit later, this `odd` tag is then re-added (at least, I hope it is as I'm not entirely sure the `firstDirtyChildIndex` will be set low enough...) I've refactored the implementation here a bit to prevent repeatedly clearing and setting a pseudo-class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907549197 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907551351 From mstrauss at openjdk.org Wed Jan 8 17:42:00 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 17:42:00 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 11:57:44 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into feature/root-pseudo-class >> - whitespace error >> - add child-indexed pseudo-classes >> - add pseudo-class table to Parent >> - update cssref >> - Set :root pseudo-class on sub-scene root node >> - Set :root pseudo-class on root node > > modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 479: > >> 477: n.pseudoClassStateChanged(NTH_EVEN_CHILD_PSEUDO_CLASS, i % 2 != 0); >> 478: n.pseudoClassStateChanged(NTH_ODD_CHILD_PSEUDO_CLASS, i % 2 == 0); >> 479: } > > With this new code, Nodes with many children being manipulated may incur some significant new costs now that these pseudo classes need to be changed for potentially many/all children. Where before adding a new first child mostly had a cost in shifting the child array with a copy, now we also potentially have two listener call backs per child (and I'm unsure, but these may even trigger some CSS recalculations or CSS cache invalidations). Nodes with many children may suffer from this, and mostly needlessly as these pseudo classes will see very limited use. > > I think there's some potential for performance regression here that is perhaps sufficient to warrant the exclusion of this feature or making it optional. I think this concern is out of proportion. Generally, nodes will not have such a huge number of children that simply flipping a few pseudo-classes will be prohibitively expensive. CSS recalculation will, in most cases, only happen once per pulse anyway. I don't know why we would be optimizing for pathological applications that register two pseudo-class listeners for each of their tens of thousands of children in a container, _and_ do heavy work in those listeners. > modules/javafx.graphics/src/test/java/test/javafx/scene/Parent_pseudoClasses_Test.java line 60: > >> 58: assertNotPseudoClass(ONLY_CHILD, child1); >> 59: assertPseudoClass(ONLY_CHILD, child2); >> 60: } > > How about a case where the last child is removed, and seeing if the first and now only child gets the correct states? I think there currently is definitely a bug where the odd/even may not be reapplied in that case... I've added more tests, including the scenario you point out. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907558879 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907559803 From mstrauss at openjdk.org Wed Jan 8 17:48:03 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 17:48:03 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: <2FG2pIW8aJLWk0Fy38d77kcZ-0jPlfem6Yv5V1txcws=.6ecbd6c0-797d-4047-8133-17d414250208@github.com> On Wed, 8 Jan 2025 11:25:37 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into feature/root-pseudo-class >> - whitespace error >> - add child-indexed pseudo-classes >> - add pseudo-class table to Parent >> - update cssref >> - Set :root pseudo-class on sub-scene root node >> - Set :root pseudo-class on root node > > modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 341: > >> 339: >> 340: @Override >> 341: protected void onChanged(Change c) { > > I hate to bring this up, and it perhaps should be dealt with separately, but how safe is this code in `onProposedChange` / `onChanged` when it is re-entered due to the many potential listener callbacks? For example, the removal of a child on `parent` can trigger list change listeners from the user that can trigger all kinds of other changes that eventually lead to more children changes on this node, triggering a nested `onChanged`; the new changes are adding more opportunities in the form of listeners on pseudo state changes. > > For example, `onProposedChange` will blatantly reset `geomChanged` to `false` in all cases, even if it rejects the change later. It doesn't check if an `onChange` is in progress higher up the call stack, effectively resetting a flag that is in active use... > > I believe this may be quite a difficult problem to solve if nested calls remain allowed, and one of the easiest ways to fix it IMHO is to reject any changes (in `onProposedChange`) when a change is already in progress. For users this would effectively mean that listeners triggered during a child modification will not be allowed to make further modifications to the same children list until the first one completes. This is not a common situation, but can happen with very dynamic UI's that construct new nodes in response to triggers; without such protection for nested changes, the errors that crop up are often of a form that seem to be multi-threading issues (where certain invariants seem to be broken), while in reality they're just re-entrant code calls that use instance fields in an unsafe manner. One option might be to move all pseudo-class modifications to the end of the `onChange` method. This would make the code equivalent to being called after the callback has completed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907567157 From angorya at openjdk.org Wed Jan 8 19:15:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 19:15:17 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <9B-s3f3O7c2J7WJWw_zFctYBolOiPW-EbyTzwtTP5JA=.b2070a50-a9bc-41ec-bf47-1eb1e41000fb@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> <9B-s3f3O7c2J7WJWw_zFctYBolOiPW-EbyTzwtTP5JA=.b2070a50-a9bc-41ec-bf47-1eb1e41000fb@github.com> Message-ID: On Wed, 8 Jan 2025 16:46:11 GMT, Pascal wrote: >> Good question! >> >> I've decided to create a new class for the incubator for two main reasons: >> 1. the only way to construct `KeyCombination` is from a `String`, which incurs the penalty of parsing >> 2. `KeyCombination` does not differentiate key pressed / key released / key typed events >> >> While 1) can be easily addressed by adding a Builder, introducing 2) may cause issues with the existing code, since `KeyCombination` is an existing public API. >> >> Any suggestions? > > `KeyCombination` is just the abstract base class. Subclasses like `javafx.scene.input.KeyCodeCombination` provide normal constructors without any parsing: > > > public KeyCodeCombination(final @NamedArg("code") KeyCode code, > final @NamedArg("modifiers") Modifier... modifiers) { /* ... */ } > > > The abstract class provides a _match_ method which subclasses can (and do) override, so it could be possible to create a subclass that implements the method based on pressed/typed: > > > @Override > public boolean match(final KeyEvent event) { > // KeyEvent has e.g. KEY_PRESSED and KEY_RELEASED, so should be possible to check here... > return checkPressedReleasedTyped(event) && super.match(event); > } You are right, in theory it is possible to coerce `KeyCombination` to do what's needed. In practice, it's going to be rather clunky. The main issue is that we can't use `KeyCombination` in the API calls because the base class has no concept or key pressed/released/typed. Basically, we would need to do one of the two things: 1. create a child class(es) of `KeyCombination` that contain the event type and accept only those, or 2. accept `KeyCombination` but do a check at runtime of whether the right class is passed, throwing an exception or ignoring the whole thing which is not optimal. Another alternative is to add three more modifiers (something like `KeyPressed`, `KeyReleased`, `KeyTyped`), maybe defaulting to `KeyPressed` when none is specified. Doing this, however, brings up another issue of possible backward compatibility when the new `KeyCombination` is used elsewhere - for example, what happens when the `MenuItem::setAccelerator` is called with a `KeyTyped` or `KeyReleased` modifier? The fact that the modified `KeyCombination` now encodes the type of the event may cause the existing code to misbehave, and we don't want to introduce regression. All that, and the fact that we already have a non-public `KeyBinding` class for the purposes of the existing non-public InputMap, is basically the rationale behind the proposed design. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1907667261 From mstrauss at openjdk.org Wed Jan 8 19:20:26 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 19:20:26 GMT Subject: Integrated: 8346227: Seal Paint and Material In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 23:33:18 GMT, Michael Strau? wrote: > The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. This pull request has now been integrated. Changeset: 3cfd317d Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/3cfd317df0d11391005f5ce753797fad3f30aead Stats: 22 lines in 5 files changed: 1 ins; 12 del; 9 mod 8346227: Seal Paint and Material Reviewed-by: nlisker, angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1665 From mstrauss at openjdk.org Wed Jan 8 19:24:33 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 19:24:33 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: move pseudo-class changes to end of onChanged ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/3c694165..a3a69ca2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=06-07 Stats: 92 lines in 1 file changed: 49 ins; 43 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From angorya at openjdk.org Wed Jan 8 19:58:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 19:58:42 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 17:28:04 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1530: >> >>> 1528:

In the following example, all background color of all buttons uses the >>> 1529: looked up color "abc".

>>> 1530:

:root { abc: #f00 }
>> >> I see many places where `.root` is removed in favor of `:root`, but both are supported still? At least, the code in `Scene` leads me to believe that it will also apply the `.root` style class still. Should this legacy style class be mentioned in the CSS documentation still? > > It will still be supported for backwards compatibility, but I see no reason to mention that now that we have the standard-conformant `:root` pseudo-class. I think we do need to mention the old selector in the CSS Ref because it is still supported. We should also tell the developers what they need to do with the existing stylesheets, whether to update them to use the new selector, or, if we plan to support the old one indefinitely, explain that. >> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 341: >> >>> 339: >>> 340: @Override >>> 341: protected void onChanged(Change c) { >> >> I hate to bring this up, and it perhaps should be dealt with separately, but how safe is this code in `onProposedChange` / `onChanged` when it is re-entered due to the many potential listener callbacks? For example, the removal of a child on `parent` can trigger list change listeners from the user that can trigger all kinds of other changes that eventually lead to more children changes on this node, triggering a nested `onChanged`; the new changes are adding more opportunities in the form of listeners on pseudo state changes. >> >> For example, `onProposedChange` will blatantly reset `geomChanged` to `false` in all cases, even if it rejects the change later. It doesn't check if an `onChange` is in progress higher up the call stack, effectively resetting a flag that is in active use... >> >> I believe this may be quite a difficult problem to solve if nested calls remain allowed, and one of the easiest ways to fix it IMHO is to reject any changes (in `onProposedChange`) when a change is already in progress. For users this would effectively mean that listeners triggered during a child modification will not be allowed to make further modifications to the same children list until the first one completes. This is not a common situation, but can happen with very dynamic UI's that construct new nodes in response to triggers; without such protection for nested changes, the errors that crop up are often of a form that seem to be multi-threading issues (where certain invariants seem to be broken), while in reality they're just re-entrant code calls that use instance fields in an unsafe manner. > > One option might be to move all pseudo-class modifications to the end of the `onChange` method. This would make the code equivalent to being called after the callback has completed. Is there a possibility of introducing an infinite loop? And if the code is moved to the end of `onChange`, might that cause a regression with the existing pseudo-classes? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907676024 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907683667 From angorya at openjdk.org Wed Jan 8 19:58:44 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 19:58:44 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:24:33 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > move pseudo-class changes to end of onChanged modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 2059: > 2057: nth-child() > 2058: applies when the node is the n-th child in its Parent container > 2059: (the only acceptable arguments are "even" and "odd") should we also specify that the numbering is 1-based? i.e. the child at index 0 is the first (1st) and therefore `ODD`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907737494 From angorya at openjdk.org Wed Jan 8 20:29:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 20:29:32 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:24:33 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > move pseudo-class changes to end of onChanged Anecdata: I did not see a noticeable performance difference on startup between this PR and the master branch with 48 children with the monkey tester: ![Screenshot 2025-01-08 at 12 22 46](https://github.com/user-attachments/assets/db60c108-ea25-431d-88c7-7d7e8c799703) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2578586183 From mstrauss at openjdk.org Wed Jan 8 21:36:26 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 21:36:26 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:09:11 GMT, Andy Goryachev wrote: >> It will still be supported for backwards compatibility, but I see no reason to mention that now that we have the standard-conformant `:root` pseudo-class. > > I think we do need to mention the old selector in the CSS Ref because it is still supported. > > We should also tell the developers what they need to do with the existing stylesheets, whether to update them to use the new selector, or, if we plan to support the old one indefinitely, explain that. Maybe we should deprecate the non-standard `.root` class and mention that in the cssref? >> One option might be to move all pseudo-class modifications to the end of the `onChange` method. This would make the code equivalent to being called after the callback has completed. > > Is there a possibility of introducing an infinite loop? > > And if the code is moved to the end of `onChange`, might that cause a regression with the existing pseudo-classes? It is possible, in the same way as it is possible to create an infinite loop for all cases where a listener callback modifies its obervable ad infinitum. There?s not much one can do in this case, except stop creating infinite loops. As for regressions: nothing comes to mind. All changed pseudo-classes will be picked up when CSS runs again in the next pulse. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907888207 PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907887130 From jhendrikx at openjdk.org Wed Jan 8 22:11:41 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 8 Jan 2025 22:11:41 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: <0b3yePZy79U6xEKTKGdPt9y6gw5n2WIeHj_vqovBjY4=.634b081d-5010-48ac-af4f-6c90b5d70cfe@github.com> On Wed, 8 Jan 2025 17:39:10 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 479: >> >>> 477: n.pseudoClassStateChanged(NTH_EVEN_CHILD_PSEUDO_CLASS, i % 2 != 0); >>> 478: n.pseudoClassStateChanged(NTH_ODD_CHILD_PSEUDO_CLASS, i % 2 == 0); >>> 479: } >> >> With this new code, Nodes with many children being manipulated may incur some significant new costs now that these pseudo classes need to be changed for potentially many/all children. Where before adding a new first child mostly had a cost in shifting the child array with a copy, now we also potentially have two listener call backs per child (and I'm unsure, but these may even trigger some CSS recalculations or CSS cache invalidations). Nodes with many children may suffer from this, and mostly needlessly as these pseudo classes will see very limited use. >> >> I think there's some potential for performance regression here that is perhaps sufficient to warrant the exclusion of this feature or making it optional. > > I think this concern is out of proportion. Generally, nodes will not have such a huge number of children that simply flipping a few pseudo-classes will be prohibitively expensive. CSS recalculation will, in most cases, only happen once per pulse anyway. > > I don't know why we would be optimizing for pathological applications that register two pseudo-class listeners for each of their tens of thousands of children in a container, _and_ do heavy work in those listeners. Perhaps it is not as dire, but it may be worth a short check how this works with say 1000 nodes with and without this new code (no need to register listeners, I agree that that is a different problem, I was more worried about how CSS handles this many changes). Perhaps also a case where there is also some style change going on linked to the odd or even pseudo class (although if that is much slower, then I guess that's what the user wanted...) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907919550 From jhendrikx at openjdk.org Wed Jan 8 22:15:08 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 8 Jan 2025 22:15:08 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 21:31:50 GMT, Michael Strau? wrote: >> I think we do need to mention the old selector in the CSS Ref because it is still supported. >> >> We should also tell the developers what they need to do with the existing stylesheets, whether to update them to use the new selector, or, if we plan to support the old one indefinitely, explain that. > > Maybe we should deprecate the non-standard `.root` class and mention that in the cssref? I only pointed this out as I didn't see removal of the old `.root` code, in which case it should either still be documented or mentioned that it will be removed in the future. I can go with either solution. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907922889 From jhendrikx at openjdk.org Wed Jan 8 22:18:36 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 8 Jan 2025 22:18:36 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:52:21 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> move pseudo-class changes to end of onChanged > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 2059: > >> 2057: nth-child() >> 2058: applies when the node is the n-th child in its Parent container >> 2059: (the only acceptable arguments are "even" and "odd") > > should we also specify that the numbering is 1-based? > i.e. the child at index 0 is the first (1st) and therefore `ODD`? While I was reviewing, I had to look that up so I could check if the code was doing the correct thing. CSS indeed considers the first child as having index 1, even though it will be index 0 in the list returned by `getChildren`. It may be worth pointing that out explicitly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907925276 From angorya at openjdk.org Wed Jan 8 22:22:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 22:22:36 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: <0b3yePZy79U6xEKTKGdPt9y6gw5n2WIeHj_vqovBjY4=.634b081d-5010-48ac-af4f-6c90b5d70cfe@github.com> References: <0b3yePZy79U6xEKTKGdPt9y6gw5n2WIeHj_vqovBjY4=.634b081d-5010-48ac-af4f-6c90b5d70cfe@github.com> Message-ID: On Wed, 8 Jan 2025 22:08:38 GMT, John Hendrikx wrote: >> I think this concern is out of proportion. Generally, nodes will not have such a huge number of children that simply flipping a few pseudo-classes will be prohibitively expensive. CSS recalculation will, in most cases, only happen once per pulse anyway. >> >> I don't know why we would be optimizing for pathological applications that register two pseudo-class listeners for each of their tens of thousands of children in a container, _and_ do heavy work in those listeners. > > Perhaps it is not as dire, but it may be worth a short check how this works with say 1000 nodes with and without this new code (no need to register listeners, I agree that that is a different problem, I was more worried about how CSS handles this many changes). Perhaps also a case where there is also some style change going on linked to the odd or even pseudo class (although if that is much slower, then I guess that's what the user wanted...) A thousand of nodes scenario is possible and I think it needs to be tested, just to estimate the impact. For example, a rich text type of control: TextFlow with a thousand small Text instances all styled differently (or tied to odd/even pseudo class). Although I am struggling to see the use case for such an arrangement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907928338 From jhendrikx at openjdk.org Wed Jan 8 22:34:36 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 8 Jan 2025 22:34:36 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:23:15 GMT, Andy Goryachev wrote: > Anecdata: I did not see a noticeable performance difference on startup between this PR and the master branch with 48 children with the monkey tester I wouldn't think you'd see it in those cases as that would primarily be hidden by the cost of adding all the children. The cases I worry about are containers that have say 1000+ children, and where just a few children (or just one) may be getting added/removed near the start of the container. Such containers can be some of the View classes that even though virtualized may be displaying 1000+ cells, or some other custom class (a Go/Minesweeper board made out of buttons or something). I think that normally a modification of the children list would primarily involve an array copy (but perhaps also peer updates). Now it will need to change/reset pseudo class state for odd/even states. Now, I'm assuming that if those states are unused in CSS that it will probably be unmeasurable, but a check here might be good, unless we just want to wait for someone to file a performance regression in the future... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2578793401 From angorya at openjdk.org Wed Jan 8 22:34:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 22:34:37 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:27:03 GMT, John Hendrikx wrote: > I wouldn't think you'd see it in those cases as that would primarily be hidden by the cost of adding all the children. I agree. Let me prototype something quickly - give me 10 minutes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2578802698 From angorya at openjdk.org Wed Jan 8 22:34:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 22:34:38 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:12:32 GMT, John Hendrikx wrote: >> Maybe we should deprecate the non-standard `.root` class and mention that in the cssref? > > I only pointed this out as I didn't see removal of the old `.root` code, in which case it should either still be documented or mentioned that it will be removed in the future. I can go with either solution. Even if it is deprecated for removal, it won't be an instantaneous event. We still need to document that, and even go further and add a warning that it will be removed, to make sure all the developers have updated their stylesheets. It probably makes more sense just to keep it, for backward compatibility. I don't think we want some banking application to go haywire when the selector gets removed. There is a value in backward compatibility. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907931566 From kcr at openjdk.org Wed Jan 8 22:34:39 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Jan 2025 22:34:39 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:23:38 GMT, Andy Goryachev wrote: >> I only pointed this out as I didn't see removal of the old `.root` code, in which case it should either still be documented or mentioned that it will be removed in the future. I can go with either solution. > > Even if it is deprecated for removal, it won't be an instantaneous event. We still need to document that, and even go further and add a warning that it will be removed, to make sure all the developers have updated their stylesheets. > > It probably makes more sense just to keep it, for backward compatibility. > > I don't think we want some banking application to go haywire when the selector gets removed. There is a value in backward compatibility. I am not in favor of deprecating this for removal. I can see a possible argument for simple deprecation (although since it isn't a Java level API, it isn't clear what that would mean or what the benefit would be), but that could be done later if there was a desire to pursue it. I do think we should continue to documenting it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907936768 From mstrauss at openjdk.org Wed Jan 8 22:34:40 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 22:34:40 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: <0b3yePZy79U6xEKTKGdPt9y6gw5n2WIeHj_vqovBjY4=.634b081d-5010-48ac-af4f-6c90b5d70cfe@github.com> Message-ID: <7fol1gRVTwzrQxWcKsXL6Ll9oz81rPCWlWE55x5EsIM=.877cc23e-8f45-440d-9404-1a8ec53c689a@github.com> On Wed, 8 Jan 2025 22:19:20 GMT, Andy Goryachev wrote: >> Perhaps it is not as dire, but it may be worth a short check how this works with say 1000 nodes with and without this new code (no need to register listeners, I agree that that is a different problem, I was more worried about how CSS handles this many changes). Perhaps also a case where there is also some style change going on linked to the odd or even pseudo class (although if that is much slower, then I guess that's what the user wanted...) > > A thousand of nodes scenario is possible and I think it needs to be tested, just to estimate the impact. For example, a rich text type of control: TextFlow with a thousand small Text instances all styled differently (or tied to odd/even pseudo class). > > Although I am struggling to see the use case for such an arrangement. It's worth pointing out that the usual case of back-insertion doesn't incur any unexpected overhead, as all nodes that come before the inserted node are unaffected by the change: var container = new StackPane(); for (int i = 0; i < 1000; ++i) { container.getChildren().add(new Button()); } It's only the unusual case of front-insertion that incurs some overhead by flipping the odd/even class for all subsequent nodes: var container = new StackPane(); for (int i = 0; i < 1000; ++i) { container.getChildren().add(0, new Button()); } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907934195 From kcr at openjdk.org Wed Jan 8 22:59:45 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Jan 2025 22:59:45 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset Nice work! Approved with some feedback that can be addressed in follow-up issues. I left a couple comments inline and have a few general comments below. ### Functional issues I noticed the following minor functional bugs: * Default width of RTA is less than half the size of TextArea (176 vs 478 on my Windows 11 system). Earlier the height was also too small, but you already fixed that. * When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). I can file the above bugs, unless you want to. ### Tests We need more automated unit tests. Please file follow-up test bugs to create additional tests for each of the following: * RichTextArea API tests * RichTextArea behavioral tests * InputMap tests ### Demos Please file the following demo build issues: * Ability to build and run the samples easily from the command line (possibly via ant / gradle). They are modular apps, so it isn't currently straight-forward. * Consider hooking the samples up to the build (so they are built as part of the "gradle apps" task. This depends on the previous. apps/samples/RichTextAreaDemo/test/test/com/oracle/demo/richtext/codearea/TestJavaSyntaxDecorator.java line 1: > 1: /* This class (and thus the entire `test/**` directory tree) is unused. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 115: > 113: * SimpleViewOnlyStyledModel m = new SimpleViewOnlyStyledModel(); > 114: * // add text segment using CSS style name (requires a stylesheet) > 115: * m.addWithStyles("RichTextArea ", "HEADER"); This example needs to be updated to reflect an earlier change in the API: `addWithStyles` --> `addWithStyleNames` modules/jfx.incubator.richtext/src/test/java/test/com/sun/jfx/incubator/scene/control/richtext/TestRichTextArea.java line 42: > 40: // TODO remove once a real test which needs the shim is added. > 41: @Test > 42: public void testShim() { Can you add a note to the follow-up bug that you will file to track adding these tests? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2538362284 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1907909939 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1907907103 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1907942520 From mstrauss at openjdk.org Wed Jan 8 23:00:16 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 23:00:16 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v9] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: updated cssref ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/a3a69ca2..ebd332e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=07-08 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From angorya at openjdk.org Wed Jan 8 23:00:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 23:00:17 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v8] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:24:33 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > move pseudo-class changes to end of onChanged Okay, check out HBox page in the latest monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest set Children to "1000 text nodes", open Tools -> Css Playground and play with the CSS, for example `.T1000:nth-child(odd) { -fx-fill-color:red; }` ![Screenshot 2025-01-08 at 14 42 37](https://github.com/user-attachments/assets/e780b03d-0c99-45a9-aa80-c0837a102534) To me on macOS 15.1.1, the style change looks instantaneous. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2578824255 From mstrauss at openjdk.org Wed Jan 8 23:00:18 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 23:00:18 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: References: Message-ID: <9B6r6Hr2NHFgDg9IqflvsU6alQDJSweW0QVzWSTkJck=.b52025bf-502c-4a0e-b127-421c0c3fd13d@github.com> On Wed, 8 Jan 2025 22:30:53 GMT, Kevin Rushforth wrote: >> Even if it is deprecated for removal, it won't be an instantaneous event. We still need to document that, and even go further and add a warning that it will be removed, to make sure all the developers have updated their stylesheets. >> >> It probably makes more sense just to keep it, for backward compatibility. >> >> I don't think we want some banking application to go haywire when the selector gets removed. There is a value in backward compatibility. > > I am not in favor of deprecating this for removal. I can see a possible argument for simple deprecation (although since it isn't a Java level API, it isn't clear what that would mean or what the benefit would be), but that could be done later if there was a desire to pursue it. > > I do think we should continue to documenting it. I've updated the language in cssref L2110: However, the root node of the scene matches the structural pseudo-class :root, as well as the legacy style class "root" (in addition to style classes already assigned to the node). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907954194 From angorya at openjdk.org Wed Jan 8 23:03:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 23:03:47 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v9] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:00:16 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 2057: > 2055: > 2056: > 2057: nth-child() There is no "`nth-child()`" name, there are two: "`nth-child(odd)`" and "`nth-child(even)`". I would recommend either to create two entries, or list two names separately. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907956553 From kcr at openjdk.org Wed Jan 8 23:14:03 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Jan 2025 23:14:03 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v6] In-Reply-To: <9B6r6Hr2NHFgDg9IqflvsU6alQDJSweW0QVzWSTkJck=.b52025bf-502c-4a0e-b127-421c0c3fd13d@github.com> References: <9B6r6Hr2NHFgDg9IqflvsU6alQDJSweW0QVzWSTkJck=.b52025bf-502c-4a0e-b127-421c0c3fd13d@github.com> Message-ID: <5lsWdz-paBkyOxIpp0RTG5CK-ONlAu41wE94hx0azr8=.48171dc7-ac9c-4d78-9fff-d48517cbb129@github.com> On Wed, 8 Jan 2025 22:57:00 GMT, Michael Strau? wrote: >> I am not in favor of deprecating this for removal. I can see a possible argument for simple deprecation (although since it isn't a Java level API, it isn't clear what that would mean or what the benefit would be), but that could be done later if there was a desire to pursue it. >> >> I do think we should continue to documenting it. > > I've updated the language in cssref L2110: > > However, the root node of the scene matches the > structural pseudo-class :root, as well as the legacy style > class "root" (in addition to style classes already assigned to the node). That looks good. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907963189 From angorya at openjdk.org Wed Jan 8 23:20:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 23:20:59 GMT Subject: Integrated: 8301121: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev wrote: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 This pull request has now been integrated. Changeset: 7312ad1a Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/7312ad1af3a67dd2fd528f3dba0192712359a242 Stats: 40087 lines in 209 files changed: 40078 ins; 9 del; 0 mod 8301121: RichTextArea Control (Incubator) 8343646: Public InputMap (Incubator) Reviewed-by: kcr, lkostyra, arapte, aghaisas, kizune ------------- PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Wed Jan 8 23:31:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 Jan 2025 23:31:18 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset Thank you all for taking time and effort testing, reviewing, and offering your help and providing suggestions! The followup for jfx24 will be addressed here - [JDK-8347305](https://bugs.openjdk.org/browse/JDK-8347305) . I expect more bugs to come in from application developers as they start playing with the demos and code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2578871938 From mstrauss at openjdk.org Wed Jan 8 23:47:10 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 23:47:10 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: updated cssref ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/ebd332e9..a199f6f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From mstrauss at openjdk.org Wed Jan 8 23:47:10 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Jan 2025 23:47:10 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v9] In-Reply-To: References: Message-ID: <44SoagovL0IRtHja0X2L3BeW8kgy8zZl36-O5JVE41g=.26450c7f-f34b-43d1-949c-af6fca3a295c@github.com> On Wed, 8 Jan 2025 23:00:34 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> updated cssref > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 2057: > >> 2055: >> 2056: >> 2057: nth-child() > > There is no "`nth-child()`" name, there are two: "`nth-child(odd)`" and "`nth-child(even)`". > > I would recommend either to create two entries, or list two names separately. > > Upd: or use the w3c-style declaration: `nth-child(odd | even)` I've opted for `nth-child(even | odd)`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1652#discussion_r1907985527 From kcr at openjdk.org Thu Jan 9 00:06:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 00:06:41 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: <9vU2nqSmyVu8Rpl9ryTGOV0NnC5hMdQjt-8Tfqrje0E=.18181a09-8bab-460e-a2d7-02ca4cea84a4@github.com> On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref The cssref changes look good. Can you update the CSR to match and I'll review it tomorrow? ------------- PR Review: https://git.openjdk.org/jfx/pull/1652#pullrequestreview-2538496889 From duke at openjdk.org Thu Jan 9 06:57:56 2025 From: duke at openjdk.org (Haidar Ali) Date: Thu, 9 Jan 2025 06:57:56 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset ?? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2577256280 From angorya at openjdk.org Thu Jan 9 16:50:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 16:50:49 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref Looks good to me. Performance updating 1000 children as tested with the monkey tester looks very good (macOS). One last question to everyone - do you think the change from .root to :root should be more pronounced in the CSS ref? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1652#pullrequestreview-2540441196 From kcr at openjdk.org Thu Jan 9 17:39:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 17:39:53 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref I wrote a test using a VBox in a ScrollPane (no scrolling is actually happening), where the VBox is initialized with 10,000 nodes. I then measured the time to add 1,000 nodes, one at a time at index 0. There is a noticeable performance drop with this PR. With the latest master, here are the results of adding 1,000 nodes 15 times (so there are 25,000 total nodes when this is all done). Added 1000 nodes in 17.016208 msec Added 1000 nodes in 12.272875 msec Added 1000 nodes in 11.467291 msec Added 1000 nodes in 3.575083 msec Added 1000 nodes in 4.963792 msec Added 1000 nodes in 9.705375 msec Added 1000 nodes in 9.232666 msec Added 1000 nodes in 8.88975 msec Added 1000 nodes in 10.242958 msec Added 1000 nodes in 10.33725 msec Added 1000 nodes in 10.780708 msec Added 1000 nodes in 10.877875 msec Added 1000 nodes in 11.293583 msec Added 1000 nodes in 11.499458 msec Added 1000 nodes in 10.199292 msec With this PR, here are the results: Added 1000 nodes in 220.310875 msec Added 1000 nodes in 195.185458 msec Added 1000 nodes in 236.359917 msec Added 1000 nodes in 254.438208 msec Added 1000 nodes in 269.650458 msec Added 1000 nodes in 323.805625 msec Added 1000 nodes in 344.086959 msec Added 1000 nodes in 422.552417 msec Added 1000 nodes in 458.606666 msec Added 1000 nodes in 560.954166 msec Added 1000 nodes in 637.210458 msec Added 1000 nodes in 613.063416 msec Added 1000 nodes in 773.218375 msec Added 1000 nodes in 838.431291 msec Added 1000 nodes in 896.401292 msec Note that in addition to it being slower to begin with, it gets progressively slower as the number of existing nodes increases (not surprisingly). This is bit of a corner case, but it does validate John's concern. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2580897575 From kcr at openjdk.org Thu Jan 9 18:22:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 18:22:46 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 17:37:28 GMT, Kevin Rushforth wrote: > This is bit of a corner case... And I confirm that there is no performance hit for the more common case of adding children at the end. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2580972244 From angorya at openjdk.org Thu Jan 9 18:22:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 18:22:47 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref yeah, if you have 25,000 nodes in one parent you have other issues, and most like you'll need a redesign. still, thank you for actual measurement - what was the platform and the amount of RAM? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2580976009 From mstrauss at openjdk.org Thu Jan 9 18:57:42 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 18:57:42 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref This outcome is what I would expect, and it puts an upper limit on the number of nodes that you can front-insert one by one into a container (the time complexity grows quadratically, so you'll pretty soon freeze the application). Note that back-inserting, or bulk-inserting nodes should have no noticeable performance impact. I think our options are the following: 1. Discard this feature. 2. Accept that this particular way of adding nodes to a container has a prohibitive time complexity for many nodes. 3. Do something clever, for example only toggle the pseudo-classes once per pulse. The disadvantage of this approach would be that the pseudo-classes of a node may be wrong after it is added to a container, and would then later fix themselves in the next pulse. 4. Do something even more clever, for example only set the pseudo-classes when someone is actually listening or retrieving their value. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581034955 From angorya at openjdk.org Thu Jan 9 19:02:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 19:02:49 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref `nth-child()` probably makes sense in the web world, but not in javafx, in my opinion. Can you give an example of where it can be useful? I also recall how it was snuck in into original PR, which started with a `:root`. Maybe we should pick #1 now and consider #4 as a possible future enhancement? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581044731 From mstrauss at openjdk.org Thu Jan 9 19:05:50 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 19:05:50 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: <_TN8KQwzVbjKsVpKNVUgNY91PLmAaX08DXwBcwHeUuE=.79ca7b3a-8380-4e1e-9ee8-a6497d8243fe@github.com> On Thu, 9 Jan 2025 18:59:39 GMT, Andy Goryachev wrote: > `nth-child()` probably makes sense in the web world, but not in javafx, in my opinion. > > Can you give an example of where it can be useful? > > I also recall how it was snuck in into original PR, which started with a `:root`. Maybe we should pick #1 now and consider #4 as a possible future enhancement? It's useful when you have a list of items that should have an alternating appearance. I've quite often used custom lists of items that are not ListViews, TableViews, etc. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581050838 From angorya at openjdk.org Thu Jan 9 19:11:43 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 19:11:43 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref so maybe it should have been done programmatically in the particular application, rather than impose a non-zero overhead on everyone (however small)? How difficult it would be to implement the option 4? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581059748 From kcr at openjdk.org Thu Jan 9 19:11:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 19:11:44 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: <_TN8KQwzVbjKsVpKNVUgNY91PLmAaX08DXwBcwHeUuE=.79ca7b3a-8380-4e1e-9ee8-a6497d8243fe@github.com> References: <_TN8KQwzVbjKsVpKNVUgNY91PLmAaX08DXwBcwHeUuE=.79ca7b3a-8380-4e1e-9ee8-a6497d8243fe@github.com> Message-ID: On Thu, 9 Jan 2025 19:03:00 GMT, Michael Strau? wrote: > Maybe we should pick 1 now and consider 4 as a possible future enhancement? I think this is worth considering. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581060316 From mstrauss at openjdk.org Thu Jan 9 19:15:55 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 19:15:55 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: <2R5If1rR5sawg2YSJp62s-pJuEr-Ls-FOE8LJ3Lk-IA=.8bacb02a-0f21-415b-a185-0e7e6d22d818@github.com> On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref By the way, I still think that front-inserting nodes one by one is a pathological situation, and can be easily fixed by just using `addAll` instead of `add` in a loop. In terms of a future enhancement, I can't really see us put in a lot of work just for one pathological use case. Discarding this feature will probably put it in the "never" category. On the other hand, there's a whole category of pseudo-classes that are unrepresentable right now in JavaFX, as they basically depend on a formula, like `nth-child(2n+1)`. But that's just speculation at this point. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581067203 From angorya at openjdk.org Thu Jan 9 19:18:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 19:18:47 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: <2R5If1rR5sawg2YSJp62s-pJuEr-Ls-FOE8LJ3Lk-IA=.8bacb02a-0f21-415b-a185-0e7e6d22d818@github.com> References: <2R5If1rR5sawg2YSJp62s-pJuEr-Ls-FOE8LJ3Lk-IA=.8bacb02a-0f21-415b-a185-0e7e6d22d818@github.com> Message-ID: On Thu, 9 Jan 2025 19:13:20 GMT, Michael Strau? wrote: > On the other hand, there's a whole category of pseudo-classes that are unrepresentable right now in JavaFX ... via CSS. One more reason to remove it and set styles programmatically when/if needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581071361 From mstrauss at openjdk.org Thu Jan 9 19:26:43 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 19:26:43 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:08:34 GMT, Andy Goryachev wrote: > so maybe it should have been done programmatically in the particular application, rather than impose a non-zero overhead on everyone (however small)? > > How difficult it would be to implement the option 4? I don't know how difficult that would be, but I can imagine that it's quite a lot of work. > ... via CSS. One more reason to remove it and set styles programmatically when/if needed. I think that CSS is one of the most unique and useful features of JavaFX, which is the reason why I think we should enhance its utility, not advise people to not use it to its fullest potential. Here's something to consider: Is there any thinkable use case where someone would _need_ to front-insert a large number of nodes one by one into a container, instead of using a bulk operation? Because if there isn't, and it's just a simple change to do the right thing, then we could also consider adding a javadoc note to that effect. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581081203 From kcr at openjdk.org Thu Jan 9 19:26:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 19:26:44 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref > Is there any thinkable use case where someone would need to front-insert a large number of nodes one by one into a container, instead of using a bulk operation? Because if there isn't, and it's just a simple change to do the right thing, then we could also consider adding a javadoc note to that effect. Not that I can think of. And this seems a reasonable approach. I also would hate to throw this out because of an uncommon usage case that has a reasonable alternative. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581085826 From kcr at openjdk.org Thu Jan 9 19:38:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 19:38:46 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:32:44 GMT, Andy Goryachev wrote: > I am ok with integrating this PR as is. As am I. I fired off a headful CI build with this fix. Once it passes, I'll approve. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581102911 From angorya at openjdk.org Thu Jan 9 19:38:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 19:38:45 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref I am not a big fan of CSS in its current state, but that's not important. The important part is that in 99.9% of use cases we won't see a difference, and there might be some use for this feature. May be a note somewhere (css ref? not sure where we could add a javadoc note) might be helpful, but really, once you are dealing with 10,000 of nodes in one parent you are doing something wrong. I am ok with integrating this PR as is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581099419 From angorya at openjdk.org Thu Jan 9 19:38:46 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Jan 2025 19:38:46 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:22:04 GMT, Michael Strau? wrote: >> so maybe it should have been done programmatically in the particular application, rather than impose a non-zero overhead on everyone (however small)? >> >> How difficult it would be to implement the option 4? > >> so maybe it should have been done programmatically in the particular application, rather than impose a non-zero overhead on everyone (however small)? >> >> How difficult it would be to implement the option 4? > > I don't know how difficult that would be, but I can imagine that it's quite a lot of work. > >> ... via CSS. One more reason to remove it and set styles programmatically when/if needed. > > I think that CSS is one of the most unique and useful features of JavaFX, which is the reason why I think we should enhance its utility, not advise people to not use it to its fullest potential. > > Here's something to consider: > Is there any thinkable use case where someone would _need_ to front-insert a large number of nodes one by one into a container, instead of using a bulk operation? Because if there isn't, and it's just a simple change to do the right thing, then we could also consider adding a javadoc note to that effect. Thank you @mstr2, @hjohn, and @kevinrushforth for a good discussion! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581105599 From kcr at openjdk.org Thu Jan 9 20:39:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Jan 2025 20:39:53 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: <3pKI-AdjQb-lmWjjobxN5mYJzq4J2ucY-la5144cBh0=.f3bed285-5599-481e-af5d-af81b75f48f9@github.com> On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref Test passed. The code and tests look good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1652#pullrequestreview-2540880466 From jhendrikx at openjdk.org Thu Jan 9 21:37:45 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 9 Jan 2025 21:37:45 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 18:53:39 GMT, Michael Strau? wrote: > This outcome is what I would expect, and it puts an upper limit on the number of nodes that you can front-insert one by one into a container (the time complexity grows quadratically, so you'll pretty soon freeze the application). > > Note that back-inserting, or bulk-inserting nodes should have no noticeable performance impact. > > I think our options are the following: > > 1. Discard this feature. > 2. Accept that this particular way of adding nodes to a container has a prohibitive time complexity for many nodes. > 3. Do something clever, for example only toggle the pseudo-classes once per pulse. The disadvantage of this approach would be that the pseudo-classes of a node may be wrong after it is added to a container, and would then later fix themselves in the next pulse. > 4. Do something even more clever, for example only set the pseudo-classes when someone is actually listening or retrieving their value. It may be possible to have these simply be synthetic (including first/only/last child). If the index of a child is known, and the size of its container, these can be trivially be computed on demand instead of fully materialized and made part of a list. I couldn't find how browsers generally do this, but I suspect it will be highly optimized. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581289531 From jhendrikx at openjdk.org Thu Jan 9 21:43:46 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 9 Jan 2025 21:43:46 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: <2R5If1rR5sawg2YSJp62s-pJuEr-Ls-FOE8LJ3Lk-IA=.8bacb02a-0f21-415b-a185-0e7e6d22d818@github.com> References: <2R5If1rR5sawg2YSJp62s-pJuEr-Ls-FOE8LJ3Lk-IA=.8bacb02a-0f21-415b-a185-0e7e6d22d818@github.com> Message-ID: On Thu, 9 Jan 2025 19:13:20 GMT, Michael Strau? wrote: > By the way, I still think that front-inserting nodes one by one is a pathological situation, and can be easily fixed by just using `addAll` instead of `add` in a loop. > > In terms of a future enhancement, I can't really see us put in a lot of work just for one pathological use case. Discarding this feature will probably put it in the "never" category. On the other hand, there's a whole category of pseudo-classes that are unrepresentable right now in JavaFX, as they basically depend on a formula, like `nth-child(2n+1)`. But that's just speculation at this point. I suspect browsers have an easy way to track the index of each child (without having to renumber them). All that would take is a different underlying list type as Nodes must be unique. A Tree structure for example can determine the index of a Node with O(log N) performance for adds/removals/find index. If browsers support advanced features like `nth-child(2n+1)` I suspect they will not be using a structure that require renumbering all items or require a full search to determine the index. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581298176 From mstrauss at openjdk.org Thu Jan 9 21:54:49 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 21:54:49 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 21:45:58 GMT, John Hendrikx wrote: > Note that you may not have choice where to insert, as the order of children also determines their Z ordering. You can always prepare the required list in advance, and then `setAll` it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581308533 From jhendrikx at openjdk.org Thu Jan 9 21:54:48 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 9 Jan 2025 21:54:48 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:22:04 GMT, Michael Strau? wrote: > > so maybe it should have been done programmatically in the particular application, rather than impose a non-zero overhead on everyone (however small)? > > How difficult it would be to implement the option 4? > > I don't know how difficult that would be, but I can imagine that it's quite a lot of work. > > > ... via CSS. One more reason to remove it and set styles programmatically when/if needed. > > I think that CSS is one of the most unique and useful features of JavaFX, which is the reason why I think we should enhance its utility, not advise people to not use it to its fullest potential. > > Here's something to consider: Is there any thinkable use case where someone would _need_ to front-insert a large number of nodes one by one into a container, instead of using a bulk operation? Because if there isn't, and it's just a simple change to do the right thing, then we could also consider adding a javadoc note to that effect. Note that you may not have choice where to insert, as the order of children also determines their Z ordering. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581304738 From mstrauss at openjdk.org Thu Jan 9 21:54:49 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 21:54:49 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: <2R5If1rR5sawg2YSJp62s-pJuEr-Ls-FOE8LJ3Lk-IA=.8bacb02a-0f21-415b-a185-0e7e6d22d818@github.com> Message-ID: On Thu, 9 Jan 2025 21:41:09 GMT, John Hendrikx wrote: > I suspect browsers have an easy way to track the index of each child (without having to renumber them). All that would take is a different underlying list type as Nodes must be unique. A Tree structure for example can determine the index of a Node with O(log N) performance for adds/removals/find index. If browsers support advanced features like `nth-child(2n+1)` I suspect they will not be using a structure that require renumbering all items or require a full search to determine the index. Yes, the problem will be to reconcile that with the existing API around pseudo-classes. It's obviously the case that a node will match an unlimited number of functional pseudo-classes like `nth-child()`, so we can't enumerate them like we do now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581307009 From jhendrikx at openjdk.org Thu Jan 9 21:54:50 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 9 Jan 2025 21:54:50 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: <7zARn2yVCvddJrFgpFmmP2QWBi6a2zjnrnKpcrpnnf4=.8f190276-7a72-44ed-b809-862ad5c6d249@github.com> On Thu, 9 Jan 2025 21:48:52 GMT, Michael Strau? wrote: > > Note that you may not have choice where to insert, as the order of children also determines their Z ordering. > > You can always prepare the required list in advance, and then `setAll` it. I'm unsure how that would prevent issues. It will then still require setting a pseudo class on all elements in the list, in addition to losing all other optimizations when the list is only shifted by a few elements... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581311590 From mstrauss at openjdk.org Thu Jan 9 21:54:50 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Jan 2025 21:54:50 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: <7zARn2yVCvddJrFgpFmmP2QWBi6a2zjnrnKpcrpnnf4=.8f190276-7a72-44ed-b809-862ad5c6d249@github.com> References: <7zARn2yVCvddJrFgpFmmP2QWBi6a2zjnrnKpcrpnnf4=.8f190276-7a72-44ed-b809-862ad5c6d249@github.com> Message-ID: On Thu, 9 Jan 2025 21:51:05 GMT, John Hendrikx wrote: > I'm unsure how that would prevent issues. It will then still require setting a pseudo class on all elements in the list, in addition to losing all other optimizations when the list is only shifted by a few elements... The performance hit is caused by the quadratic time complexity when you call `set(0, child)` in a loop. If you call `setAll(children)` instead, the time complexity is linear. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581313363 From jhendrikx at openjdk.org Thu Jan 9 22:10:51 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 9 Jan 2025 22:10:51 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v10] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:47:10 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > updated cssref I'm only pointing out a problem, which turns out indeed exists. I would personally err on the side of caution here as people do crazy things with FX. As each node now gets one or more extra pseudo classes, this also affects the memory usage. I know we've been very conservative with this in the past as well (like adding a field to `Node`). Anyway, the rest of the PR looks good now, and I've raised the concerns I wanted to raise. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581333875 From almatvee at openjdk.org Fri Jan 10 01:34:28 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 10 Jan 2025 01:34:28 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 Message-ID: - Updated GStreamer to 1.24.10 and Glib to 2.82.4. - Testing done on all platforms with all supported formats. - Removed gstdiscoverer.c. We do not use code from this file. - No other changes or bug fixes are done. ------------- Commit messages: - 8346228: Update GStreamer to 1.24.10 [v3] - 8346228: Update GStreamer to 1.24.10 [v2] - 8346228: Update GStreamer to 1.24.10 Changes: https://git.openjdk.org/jfx/pull/1670/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346228 Stats: 12196 lines in 105 files changed: 3855 ins; 7196 del; 1145 mod Patch: https://git.openjdk.org/jfx/pull/1670.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1670/head:pull/1670 PR: https://git.openjdk.org/jfx/pull/1670 From almatvee at openjdk.org Fri Jan 10 01:34:28 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 10 Jan 2025 01:34:28 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 01:16:52 GMT, Alexander Matveev wrote: > - Updated GStreamer to 1.24.10 and Glib to 2.82.4. > - Testing done on all platforms with all supported formats. > - Removed gstdiscoverer.c. We do not use code from this file. > - No other changes or bug fixes are done. 8346228: Update GStreamer to 1.24.10 [v3] - Fixed whitespace. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1670#issuecomment-2581559001 From mstrauss at openjdk.org Fri Jan 10 02:03:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 10 Jan 2025 02:03:47 GMT Subject: Integrated: 8345188: Support tree-structural pseudo-classes In-Reply-To: References: Message-ID: <0POMo1ovcudt022Cfs5XVsd5b8MuZaU1u_5Afd8gWyg=.d40d9467-9909-40b3-945b-974586983b65@github.com> On Thu, 28 Nov 2024 14:02:36 GMT, Michael Strau? wrote: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. This pull request has now been integrated. Changeset: 0f6b8c50 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/0f6b8c50f5ded5a1b9da9e2e1f3ff990e6122b5b Stats: 549 lines in 8 files changed: 510 ins; 15 del; 24 mod 8345188: Support tree-structural pseudo-classes Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1652 From petr.stechmuller at seznam.cz Fri Jan 10 09:03:26 2025 From: petr.stechmuller at seznam.cz (petr.stechmuller at seznam.cz) Date: Fri, 10 Jan 2025 10:03:26 +0100 (CET) Subject: Manage taskbar from JavaFX Message-ID: Hello openjfx-dev, First of all I want thank you all for an amazing work you are doing. I'm excited about new features comming to FX and in general I do enjoy to work with the framework. I would like to ask for help. I'm trying get more experience with new java FFM API. The best way how to learn new API is by using is in a project. My goal is to somehow have the ability to show on a taskbar progress of some long running task. As far as I know, there is no "native" support of this in JavaFX. There are some libraries like "https://github.com/Dansoftowner/FXTaskbarProgressBar" which serves the purpose, but only for Windows. And it is using the "old" JNI. After a short research, I found a simple library in go https://github.com/bibelin/taskbar. It got inspired by this library and tried to "convert" it to JavaFX. First I used jextract to get java bindings to native library calls: jextract --output target/generated-sources/jextract -t "taskbar_test.gen" -- include-function "XOpenDisplay" --include-function "XChangeProperty" -- include-function "XFlush" --include-function "XCloseDisplay" /usr/include/X 11/Xlib.h Then I created a simple application to simulate long running process where I try to update progress on taskbar by calling method "XChangeProperty" which I found in documentation of X11: https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html# XChangeProperty Unfortunately this does not work. The program does not crash, task is running on background, but no update on taskbar is happening. Here is the code I created: package taskbar_test; import com.sun.glass.ui.Window; import javafx.application.Application; import javafx.concurrent.Task; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.VBox; import javafx.stage.Stage; import taskbar_test.gen.Xlib_h; import java.lang.foreign.Arena; import java.lang.foreign.MemorySegment; import java.lang.foreign.ValueLayout; public class AppLinuxXlib extends Application { ??? @Override ??? public void start(Stage primaryStage) { ??????? Button startButton = new Button("Start Long Running Task"); ??????? startButton.setOnAction(event -> { ??????????? final long rawHandle = Window.getWindows().getFirst(). getRawHandle(); ??????????? System.out.println(rawHandle); ??????????? // Create a long-running task ??????????? Task longTask = new Task<>() { ??????????????? @Override ??????????????? protected Void call() throws Exception { ??????????????????? System.out.println("Started"); ??????????????????? try (var arena = Arena.ofConfined()) { ??????????????????????? var NET_WM_XAPP_PROGRESS = arena.allocateFrom("NET_ WM_XAPP_PROGRESS"); //??????????????????????? var NET_WM_XAPP_PROGRESS_PULSE = arena. allocateFrom("NET_WM_XAPP_PROGRESS_PULSE"); ??????????????????????? MemorySegment x11Session = Xlib_h.XOpenDisplay (MemorySegment.NULL); ??????????????????????? System.out.println(x11Session); ??????????????????????? // Prepare the progress data ??????????????????????? MemorySegment initData = arena.allocateFrom (ValueLayout.JAVA_INT, 0); ??????????????????????? Xlib_h.XChangeProperty(x11Session,?????????????????? ? // display ??????????????????????????????? MemorySegment.ofAddress(rawHandle).address() , // window ??????????????????????????????? NET_WM_XAPP_PROGRESS.address(),????????????? ? // property ??????????????????????????????? 6,?????????????????????????????????????????? ? // type ??????????????????????????????? 32,????????????????????????????????????????? ? // format ??????????????????????????????? 0,?????????????????????????????????????????? ? // mode PropModeReplace=0 ??????????????????????????????? initData,??????????????????????????????????? ? // data ??????????????????????????????? 1);????????????????????????????????????????? ? // nelements ??????????????????????? Xlib_h.XFlush(x11Session); ??????????????????????? System.out.println("Countdown started"); ??????????????????????? // Set the taskbar progress ??????????????????????? for (int i = 0; i <= 100; i+=20) { ??????????????????????????? // Simulate work ??????????????????????????? Thread.sleep(500); ??????????????????????????? System.out.println(i); ??????????????????????????? MemorySegment progressData = arena.allocateFrom (ValueLayout.JAVA_INT, i); ??????????????????????????? // Update taskbar progress ??????????????????????????? // https://www.x.org/releases/X11R7.7/doc/libX 11/libX11/libX11.html#XChangeProperty ??????????????????????????? Xlib_h.XChangeProperty(x11Session,?????????????? ????? // display ??????????????????????????????????? MemorySegment.ofAddress(rawHandle). address(), // window ??????????????????????????????????? NET_WM_XAPP_PROGRESS.address(),????????? ????? // property ??????????????????????????????????? 6,?????????????????????????????????????? ????? // type ??????????????????????????????????? 32,????????????????????????????????????? ????? // format ??????????????????????????????????? 0,?????????????????????????????????????? ????? // mode PropModeReplace=0 ??????????????????????????????????? progressData,??????????????????????????? ???? // data ??????????????????????????????????? 1);????????????????????????????????????? ????? // nelements ??????????????????????????? Xlib_h.XFlush(x11Session); ??????????????????????? } ??????????????????????? System.out.println("Finished"); ??????????????????????? Xlib_h.XCloseDisplay(x11Session); ??????????????????? } catch (Throwable ex) { ??????????????????????? ex.printStackTrace(); ??????????????????? } ??????????????????? return null; ??????????????? } ??????????? }; ??????????? // Start the task in a new thread ??????????? new Thread(longTask).start(); ??????? }); ??????? VBox vbox = new VBox(10, startButton); ??????? Scene scene = new Scene(vbox, 300, 200); ??????? primaryStage.setScene(scene); ??????? primaryStage.setTitle("Taskbar Progress Example Linux"); ??????? primaryStage.show(); ??? } ??? public static void main(String[] args) { ??????? launch(args); ??? } } Can someone show me what am I doing wrong and maybe point me to the correct direction with how to make the implementation work? Thank you very much. Best regards, Petr ?techm?ller -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jan 10 14:25:49 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Jan 2025 14:25:49 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 01:16:52 GMT, Alexander Matveev wrote: > - Updated GStreamer to 1.24.10 and Glib to 2.82.4. > - Testing done on all platforms with all supported formats. > - Removed gstdiscoverer.c. We do not use code from this file. > - No other changes or bug fixes are done. Reviewers: @kevinrushforth and either @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1670#issuecomment-2582825521 From duke at openjdk.org Fri Jan 10 15:24:46 2025 From: duke at openjdk.org (henrykdz) Date: Fri, 10 Jan 2025 15:24:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Hey Guys, i am just new here, pls anyone help with my observation: Bug Report: JavaFX TreeView - Incorrect Cell Index Update on Expand/Collapse Issue: When expanding or collapsing a TreeItem in a TreeView, an incorrect cell index is updated. Specifically, a cell index mirrored vertically around the center of the visible area is updated instead of the correct cell. This indicates a flaw in the cell index update logic or the visible cell list update mechanism. This issue is particularly noticeable when cells are styled using CSS, as the incorrect update results in a visual glitch or flicker. Even without CSS, the problem manifests as a subtle graphical irregularity due to the rapid update process. Steps to Reproduce: Create a TreeView with enough items to enable scrolling. Scroll to make a specific range of indices visible (e.g., indices 4 to 13). Apply distinct CSS styles to cells to make updates visually apparent. Expand or collapse a TreeItem within the visible range (e.g., index 5). Observe that the mirrored index (e.g., index 12) is updated instead of the correct index. Observed Behavior: When a TreeItem at index i is expanded/collapsed, the index updated is: Mirrored?Index = 2 ? Center ? ? Examples: Expanding/collapsing index 5 incorrectly updates index 12. Expanding/collapsing index 10 incorrectly updates index 3. Expected Behavior: Only the cell corresponding to the expanded/collapsed TreeItem should be updated. Impact: Visual inconsistencies and graphical glitches in the TreeView. Subtle flickering or graphical irregularities during expand/collapse actions, especially noticeable with styled cells. Suggested Cause: A miscalculation or incorrect implementation in the logic for updating cell indices or the visible cell list during expand/collapse operations. Environment: Observed in JavaFX versions 16 through 23. Present across different platforms and configurations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2582944486 From angorya at openjdk.org Fri Jan 10 15:44:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 15:44:49 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 15:19:48 GMT, henrykdz wrote: >> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java >> - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() >> - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > Hey Guys, i am just new here, pls anyone help with my observation: > Bug Report: JavaFX TreeView - Incorrect Cell Index Update on Expand/Collapse > Issue: > When expanding or collapsing a TreeItem in a TreeView, an incorrect cell index is updated. Specifically, a cell index mirrored vertically around the center of the visible area is updated instead of the correct cell. This indicates a flaw in the cell index update logic or the visible cell list update mechanism. > > This issue is particularly noticeable when cells are styled using CSS, as the incorrect update results in a visual glitch or flicker. Even without CSS, the problem manifests as a subtle graphical irregularity due to the rapid update process. > > Steps to Reproduce: > > Create a TreeView with enough items to enable scrolling. > Scroll to make a specific range of indices visible (e.g., indices 4 to 13). > Apply distinct CSS styles to cells to make updates visually apparent. > Expand or collapse a TreeItem within the visible range (e.g., index 5). > Observe that the mirrored index (e.g., index 12) is updated instead of the correct index. > Observed Behavior: > When a TreeItem at index i is expanded/collapsed, the index updated is: > > Mirrored?Index = 2 ? Center ? ? > > Examples: > Expanding/collapsing index 5 incorrectly updates index 12. > Expanding/collapsing index 10 incorrectly updates index 3. > Expected Behavior: > Only the cell corresponding to the expanded/collapsed TreeItem should be updated. > > Impact: > Visual inconsistencies and graphical glitches in the TreeView. > Subtle flickering or graphical irregularities during expand/collapse actions, especially noticeable with styled cells. > Suggested Cause: > A miscalculation or incorrect implementation in the logic for updating cell indices or the visible cell list during expand/collapse operations. > > Environment: > Observed in JavaFX versions 16 through 23. > Present across different platforms and configurations. @henrykdz : thank you for the bug report! I can help you to file a bug. Two questions: 1. is the issue you describe still present when tested with the changes in this PR? Or is it a separate issue? 2. can you create a simple SCCE (self-contained short example), see for instance https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/TreeView_RenderingFailure_8346824_8347357.java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2582991131 From angorya at openjdk.org Fri Jan 10 15:59:23 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 15:59:23 GMT Subject: RFR: 8347305: RichTextArea Follow-up Message-ID: The changes: - minor fixes in the behavior document (DELETE_WORD_PREVIOUS) - Default width of RTA is less than half the size of TextArea (176 vs 478 on my Windows 11 system). Earlier the height was also too small, but you already fixed that. The following is not an issue (works as designed): - When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). ------------- Commit messages: - pref width - DELETE_WORD_PREVIOUS Changes: https://git.openjdk.org/jfx/pull/1671/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1671&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347305 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1671.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1671/head:pull/1671 PR: https://git.openjdk.org/jfx/pull/1671 From duke at openjdk.org Fri Jan 10 16:03:46 2025 From: duke at openjdk.org (henrykdz) Date: Fri, 10 Jan 2025 16:03:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction https://github.com/user-attachments/assets/6a07c5f9-7ac3-4148-b1db-07957af06e7a > @henrykdz : thank you for the bug report! I can help you to file a bug. Two questions: > > 1. is the issue you describe still present when tested with the changes in this PR? Or is it a separate issue? > 2. can you create a simple SCCE (self-contained short example), see for instance https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/TreeView_RenderingFailure_8346824_8347357.java https://github.com/user-attachments/assets/b0d65fa0-0556-4687-a80b-1168866324f7 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2583064466 From kcr at openjdk.org Fri Jan 10 16:10:49 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Jan 2025 16:10:49 GMT Subject: RFR: 8347305: RichTextArea Follow-up In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 15:48:43 GMT, Andy Goryachev wrote: > The following is not an issue (works as designed): > > * When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). It might just be an issue with the demo, because I don't see it on a simple test program I wrote. Whether or not it works as designed, it looks ugly (and it's distracting as you navigate down the page with the keyboard). Here is a screen shot. ![Screenshot 2025-01-10 080204](https://github.com/user-attachments/assets/a18fea2c-6ee2-4b78-9408-77b9d2154831) Anyway, I don't mind addressing this later, and not part of this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1671#issuecomment-2583092975 From angorya at openjdk.org Fri Jan 10 16:16:52 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 16:16:52 GMT Subject: RFR: 8347305: RichTextArea Follow-up In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 16:07:38 GMT, Kevin Rushforth wrote: > It might just be an issue with the demo, I see "use content width" option enabled, this is not the right use case. When the RTA is constrained, the useContentWidth should be off. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1671#issuecomment-2583122821 From kcr at openjdk.org Fri Jan 10 16:19:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Jan 2025 16:19:40 GMT Subject: RFR: 8347305: RichTextArea Follow-up In-Reply-To: References: Message-ID: <1BbJChDukvRSvq3ScAUTACCh3VJ9w6r28_yk-Wwtg4I=.8b2ed72e-446f-43bb-871f-4b927454ae0d@github.com> On Fri, 10 Jan 2025 15:48:43 GMT, Andy Goryachev wrote: > The changes: > > - minor fixes in the behavior document (DELETE_WORD_PREVIOUS) > - Default width of RTA is less than half the size of TextArea (176 vs 478 on my Windows 11 system). Earlier the height was also too small, but you already fixed that. > > The following is not an issue (works as designed): > - When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). It looks like you missed capturing the bug for [this comment](https://github.com/openjdk/jfx/pull/1524#discussion_r1907907103). The second example in the RTA class docs doesn't compile. It needs to be updated to reflect an earlier change in the API: `addWithStyles` --> `addWithStyleNames` Can you either fix it as part of this PR or file a new bug? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1671#issuecomment-2583134759 From angorya at openjdk.org Fri Jan 10 16:24:05 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 16:24:05 GMT Subject: RFR: 8347305: RichTextArea Follow-up [v2] In-Reply-To: References: Message-ID: > The changes: > > - minor fixes in the behavior document (DELETE_WORD_PREVIOUS) > - Default width of RTA is less than half the size of TextArea (176 vs 478 on my Windows 11 system). Earlier the height was also too small, but you already fixed that. > > The following is not an issue (works as designed): > - When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: with style names ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1671/files - new: https://git.openjdk.org/jfx/pull/1671/files/694920a3..ec8cdf42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1671&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1671&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1671.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1671/head:pull/1671 PR: https://git.openjdk.org/jfx/pull/1671 From kcr at openjdk.org Fri Jan 10 18:05:39 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Jan 2025 18:05:39 GMT Subject: RFR: 8347305: RichTextArea Follow-up [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 16:24:05 GMT, Andy Goryachev wrote: >> The changes: >> >> - minor fixes in the behavior document (DELETE_WORD_PREVIOUS) >> - Default width of RTA is less than half the size of TextArea (176 vs 478 on my Windows 11 system). Earlier the height was also too small, but you already fixed that. >> - `addWithStyles` --> `addWithStyleNames` >> >> The following is not an issue (works as designed): >> - When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > with style names LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1671#pullrequestreview-2543127222 From duke at openjdk.org Fri Jan 10 18:09:51 2025 From: duke at openjdk.org (henrykdz) Date: Fri, 10 Jan 2025 18:09:51 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Did you recognized? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2583426699 From angorya at openjdk.org Fri Jan 10 18:35:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 18:35:49 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 18:06:48 GMT, henrykdz wrote: >> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java >> - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() >> - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > Did you recognized? @henrykdz : thank you for providing SCCE. I've created https://bugs.openjdk.org/browse/JDK-8347464 to track the new issue. The new issue is not related to this PR, so sorry @Maran23 for adding unrelated comments. In the future, it's probably better to file the bug via normal channel described in https://bugs.java.com/bugdatabase/faq or by sending a message to [openjfx-dev at openjdk.org](mailto:openjfx-dev at openjdk.org) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2583521101 From almatvee at openjdk.org Fri Jan 10 21:24:25 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 10 Jan 2025 21:24:25 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 [v2] In-Reply-To: References: Message-ID: <9IHaX9f4VVSPAPZEROSCLWI1ovt-atqZZXOVo4LQj-s=.593f6f2d-fded-45c3-9305-893e38818869@github.com> > - Updated GStreamer to 1.24.10 and Glib to 2.82.4. > - Testing done on all platforms with all supported formats. > - Removed gstdiscoverer.c. We do not use code from this file. > - No other changes or bug fixes are done. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8346228: Update GStreamer to 1.24.10 [v4] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1670/files - new: https://git.openjdk.org/jfx/pull/1670/files/219b0346..5399ec90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1670&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1670&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1670.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1670/head:pull/1670 PR: https://git.openjdk.org/jfx/pull/1670 From almatvee at openjdk.org Fri Jan 10 21:24:26 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 10 Jan 2025 21:24:26 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 01:16:52 GMT, Alexander Matveev wrote: > - Updated GStreamer to 1.24.10 and Glib to 2.82.4. > - Testing done on all platforms with all supported formats. > - Removed gstdiscoverer.c. We do not use code from this file. > - No other changes or bug fixes are done. 8346228: Update GStreamer to 1.24.10 [v4] - Fixed typo in glib MD file. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1670#issuecomment-2584260067 From angorya at openjdk.org Fri Jan 10 22:24:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 22:24:51 GMT Subject: RFR: 8347362: RichTextArea Demo Apps Build Integration Message-ID: Added ant build to the RichTextAreaDemo project. ## Building Build: run `ant` command in the project directory. ## Running Demos Use the following commands to run demos build in the previous section: Code Area Demo: `ant run-codearea-demo` Notebook Demo: `ant run-notebook-demo` Rich Editor Demo: `ant run-richeditor-demo` RichTextArea Tester: `ant run-richtextarea-demo` ------------- Commit messages: - build and run demos with ant Changes: https://git.openjdk.org/jfx/pull/1672/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1672&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347362 Stats: 132 lines in 2 files changed: 130 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1672.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/jfx/pull/1672 From kcr at openjdk.org Fri Jan 10 23:13:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Jan 2025 23:13:50 GMT Subject: RFR: 8347362: RichTextArea Demo Apps Build Script In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 21:09:01 GMT, Andy Goryachev wrote: > Added ant build to the RichTextAreaDemo project. > > ## Building > > Build: run `ant` command in the project directory. > > ## Running Demos > > Use the following commands to run demos build in the previous section: > > Code Area Demo: `ant run-codearea-demo` > > Notebook Demo: `ant run-notebook-demo` > > Rich Editor Demo: `ant run-richeditor-demo` > > RichTextArea Tester: `ant run-richtextarea-demo` This works for me, and looks good with one suggestion. The various "run" targets launch the demo in the background, which none of our other build scripts do. I think it should wait for the demo to complete; the user can put the "ant run..." in the background if they want to. As it is, it we couldn't put this into a script that runs a set of demos one after another, starting each one with the previous was closed (we have scripts like that that I use for sanity testing). apps/samples/RichTextAreaDemo/build.xml line 79: > 77: > 78: > 79: I would remove the `spawn="true"`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1672#pullrequestreview-2544204941 PR Review Comment: https://git.openjdk.org/jfx/pull/1672#discussion_r1911637535 From angorya at openjdk.org Fri Jan 10 23:17:31 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 23:17:31 GMT Subject: RFR: 8347362: RichTextArea Demo Apps Build Script [v2] In-Reply-To: References: Message-ID: > Added ant build to the RichTextAreaDemo project. > > ## Building > > Build: run `ant` command in the project directory. > > ## Running Demos > > Use the following commands to run demos build in the previous section: > > Code Area Demo: `ant run-codearea-demo` > > Notebook Demo: `ant run-notebook-demo` > > Rich Editor Demo: `ant run-richeditor-demo` > > RichTextArea Tester: `ant run-richtextarea-demo` Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: no spawn ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1672/files - new: https://git.openjdk.org/jfx/pull/1672/files/02e70f87..717e2c10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1672&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1672&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1672.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1672/head:pull/1672 PR: https://git.openjdk.org/jfx/pull/1672 From angorya at openjdk.org Fri Jan 10 23:17:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 10 Jan 2025 23:17:32 GMT Subject: RFR: 8347362: RichTextArea Demo Apps Build Script [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:04:43 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> no spawn > > apps/samples/RichTextAreaDemo/build.xml line 79: > >> 77: >> 78: >> 79: > > I would remove the `spawn="true"`. done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1672#discussion_r1911658476 From kcr at openjdk.org Fri Jan 10 23:22:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Jan 2025 23:22:44 GMT Subject: RFR: 8347362: RichTextArea Demo Apps Build Script [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:17:31 GMT, Andy Goryachev wrote: >> Added ant build to the RichTextAreaDemo project. >> >> ## Building >> >> Build: run `ant` command in the project directory. >> >> ## Running Demos >> >> Use the following commands to run demos build in the previous section: >> >> Code Area Demo: `ant run-codearea-demo` >> >> Notebook Demo: `ant run-notebook-demo` >> >> Rich Editor Demo: `ant run-richeditor-demo` >> >> RichTextArea Tester: `ant run-richtextarea-demo` > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > no spawn Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1672#pullrequestreview-2544243299 From sykora at openjdk.org Mon Jan 13 10:48:48 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Mon, 13 Jan 2025 10:48:48 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 [v2] In-Reply-To: <9IHaX9f4VVSPAPZEROSCLWI1ovt-atqZZXOVo4LQj-s=.593f6f2d-fded-45c3-9305-893e38818869@github.com> References: <9IHaX9f4VVSPAPZEROSCLWI1ovt-atqZZXOVo4LQj-s=.593f6f2d-fded-45c3-9305-893e38818869@github.com> Message-ID: On Fri, 10 Jan 2025 21:24:25 GMT, Alexander Matveev wrote: >> - Updated GStreamer to 1.24.10 and Glib to 2.82.4. >> - Testing done on all platforms with all supported formats. >> - Removed gstdiscoverer.c. We do not use code from this file. >> - No other changes or bug fixes are done. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8346228: Update GStreamer to 1.24.10 [v4] All builds went fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1670#pullrequestreview-2546276362 From kcr at openjdk.org Mon Jan 13 13:59:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 Jan 2025 13:59:58 GMT Subject: RFR: 8346228: Update GStreamer to 1.24.10 [v2] In-Reply-To: <9IHaX9f4VVSPAPZEROSCLWI1ovt-atqZZXOVo4LQj-s=.593f6f2d-fded-45c3-9305-893e38818869@github.com> References: <9IHaX9f4VVSPAPZEROSCLWI1ovt-atqZZXOVo4LQj-s=.593f6f2d-fded-45c3-9305-893e38818869@github.com> Message-ID: On Fri, 10 Jan 2025 21:24:25 GMT, Alexander Matveev wrote: >> - Updated GStreamer to 1.24.10 and Glib to 2.82.4. >> - Testing done on all platforms with all supported formats. >> - Removed gstdiscoverer.c. We do not use code from this file. >> - No other changes or bug fixes are done. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8346228: Update GStreamer to 1.24.10 [v4] Looks good. I sanity tested it on all platforms. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1670#pullrequestreview-2546686787 From angorya at openjdk.org Mon Jan 13 15:34:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 Jan 2025 15:34:50 GMT Subject: Integrated: 8347305: RichTextArea Follow-up In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 15:48:43 GMT, Andy Goryachev wrote: > The changes: > > - minor fixes in the behavior document (DELETE_WORD_PREVIOUS) > - Default width of RTA is less than half the size of TextArea (176 vs 478 on my Windows 11 system). Earlier the height was also too small, but you already fixed that. > - `addWithStyles` --> `addWithStyleNames` > > The following is not an issue (works as designed): > - When running the demos, the current line highlight overlaps and obscures focus outline on right side (verified on Windows and Linux). This pull request has now been integrated. Changeset: b7b4d6e4 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/b7b4d6e4c1acb598095ba9430d0bb2adaf5c417a Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8347305: RichTextArea Follow-up Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1671 From angorya at openjdk.org Mon Jan 13 15:36:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 Jan 2025 15:36:50 GMT Subject: Integrated: 8347362: RichTextArea Demo Apps Build Script In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 21:09:01 GMT, Andy Goryachev wrote: > Added ant build to the RichTextAreaDemo project. > > ## Building > > Build: run `ant` command in the project directory. > > ## Running Demos > > Use the following commands to run demos build in the previous section: > > Code Area Demo: `ant run-codearea-demo` > > Notebook Demo: `ant run-notebook-demo` > > Rich Editor Demo: `ant run-richeditor-demo` > > RichTextArea Tester: `ant run-richtextarea-demo` This pull request has now been integrated. Changeset: dcfe56bd Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/dcfe56bd87ab9160d90b4b0aa634ca0b41788283 Stats: 132 lines in 2 files changed: 130 ins; 1 del; 1 mod 8347362: RichTextArea Demo Apps Build Script Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1672 From kcr at openjdk.org Mon Jan 13 16:30:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 Jan 2025 16:30:21 GMT Subject: RFR: 8347598: Change JavaFX release version to 25 In-Reply-To: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> References: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> Message-ID: <6cNvg1Q4LZQvEg0BX8sRItkSUN-xJ5hjcC5l97Ri0YE=.ec98d075-4a25-40b9-9fa3-e89b2bae8cf7@github.com> On Mon, 13 Jan 2025 16:25:06 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 25. I will integrate this to master as part of forking the jfx24 stabilization branch, which is scheduled for Thursday, January 16, 2025 at 16:00 UTC. Reviewer: @arapte or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1673#issuecomment-2587586425 From kcr at openjdk.org Mon Jan 13 16:30:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 Jan 2025 16:30:21 GMT Subject: RFR: 8347598: Change JavaFX release version to 25 Message-ID: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> Bump the version number of JavaFX to 25. I will integrate this to master as part of forking the jfx24 stabilization branch, which is scheduled for Thursday, January 16, 2025 at 16:00 UTC. ------------- Commit messages: - 8347598: Change JavaFX release version to 25 Changes: https://git.openjdk.org/jfx/pull/1673/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1673&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347598 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1673.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1673/head:pull/1673 PR: https://git.openjdk.org/jfx/pull/1673 From angorya at openjdk.org Mon Jan 13 16:39:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 Jan 2025 16:39:42 GMT Subject: RFR: 8347598: Change JavaFX release version to 25 In-Reply-To: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> References: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> Message-ID: On Mon, 13 Jan 2025 16:25:06 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 25. I will integrate this to master as part of forking the jfx24 stabilization branch, which is scheduled for Thursday, January 16, 2025 at 16:00 UTC. `javadoc.title` and `javadoc.header` now follow the `@JAVADOC_VERSION@` variable, nice. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1673#pullrequestreview-2547193580 From michaelstrau2 at gmail.com Mon Jan 13 17:11:30 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 13 Jan 2025 18:11:30 +0100 Subject: Manage taskbar from JavaFX In-Reply-To: References: Message-ID: Hi Petr, the openjfx-dev mailing list is a place to discuss the direction and development of the JavaFX framework itself. If your question is not directly related to the JavaFX framework (which it doesn't seem to be), it's unlikely that you'll get much help here. You might have more luck on StackOverflow or Reddit. From jvos at openjdk.org Mon Jan 13 19:02:51 2025 From: jvos at openjdk.org (Johan Vos) Date: Mon, 13 Jan 2025 19:02:51 GMT Subject: RFR: 8347598: Change JavaFX release version to 25 In-Reply-To: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> References: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> Message-ID: On Mon, 13 Jan 2025 16:25:06 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 25. I will integrate this to master as part of forking the jfx24 stabilization branch, which is scheduled for Thursday, January 16, 2025 at 16:00 UTC. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1673#pullrequestreview-2547576100 From kcr at openjdk.org Mon Jan 13 19:09:25 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 Jan 2025 19:09:25 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 Message-ID: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Release notes for JavaFX 23.0.2. Notes to reviewers: I used the following filter to pick the issues: https://bugs.openjdk.org/issues/?filter=47027 The original filter, with the backport IDs, is here: https://bugs.openjdk.org/issues/?filter=47026 As usual, I excluded test bugs, cleanup bugs, etc. NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. ------------- Commit messages: - 8347616: Create release notes for JavaFX 23.0.2 Changes: https://git.openjdk.org/jfx23u/pull/35/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=35&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347616 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/35.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/35/head:pull/35 PR: https://git.openjdk.org/jfx23u/pull/35 From kcr at openjdk.org Mon Jan 13 19:44:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 Jan 2025 19:44:52 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 In-Reply-To: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: On Mon, 13 Jan 2025 19:02:33 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 23.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=47027 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=47026 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. Reviewers: @johanvos @abhinayagarwal ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/35#issuecomment-2588038552 From kcr at openjdk.org Tue Jan 14 00:23:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 Jan 2025 00:23:52 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v4] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 16:26:54 GMT, Martin Fox wrote: >> Input methods don?t work for text controls inside Popups. This PR fixes that. >> >> Some background: >> >> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. >> >> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. >> >> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. >> >> There are several reasons why Input Methods aren?t currently working for Popups. >> >> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. >> >> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. >> >> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. >> >> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. >> >> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha... > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Removed debug printlns, tidied up some code The code changes look good. I'll do some local testing as well as fire off a CI headful test run (which is more of a sanity test than anything, since IME won't be used). Tested locally on macOS 14.x and Windows 11. All good. > This PR also fixes JDK-8334586 Let's close JDK-8334586 as a duplicate of this bug (it's a specific case of the general problem fixed by this PR, so Dup seems better than adding it as an additional issue solved by this PR). ------------- PR Review: https://git.openjdk.org/jfx/pull/1634#pullrequestreview-2548216208 Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1634#pullrequestreview-2548279477 PR Comment: https://git.openjdk.org/jfx/pull/1634#issuecomment-2588466163 From almatvee at openjdk.org Tue Jan 14 03:58:44 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 14 Jan 2025 03:58:44 GMT Subject: Integrated: 8346228: Update GStreamer to 1.24.10 In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 01:16:52 GMT, Alexander Matveev wrote: > - Updated GStreamer to 1.24.10 and Glib to 2.82.4. > - Testing done on all platforms with all supported formats. > - Removed gstdiscoverer.c. We do not use code from this file. > - No other changes or bug fixes are done. This pull request has now been integrated. Changeset: 22035dec Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/22035dec470756e03d254aa12c088876ae20497d Stats: 12196 lines in 105 files changed: 3855 ins; 7196 del; 1145 mod 8346228: Update GStreamer to 1.24.10 8346229: Update Glib to 2.82.4 Reviewed-by: sykora, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1670 From duke at openjdk.org Tue Jan 14 07:28:48 2025 From: duke at openjdk.org (Abhinay Agarwal) Date: Tue, 14 Jan 2025 07:28:48 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 In-Reply-To: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: On Mon, 13 Jan 2025 19:02:33 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 23.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=47027 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=47026 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. Is https://bugs.openjdk.org/browse/JDK-8341686 not a part of the release notes as it is a "Task" and doesn't fall under "Bug" or "Enhancement"? ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/35#issuecomment-2589202665 From kcr at openjdk.org Tue Jan 14 13:23:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 Jan 2025 13:23:50 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 In-Reply-To: References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: On Tue, 14 Jan 2025 07:25:52 GMT, Abhinay Agarwal wrote: > Is https://bugs.openjdk.org/browse/JDK-8341686 not a part of the release notes as it is a "Task" and doesn't fall under "Bug" or "Enhancement"? Correct. ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/35#issuecomment-2589895232 From kcr at openjdk.org Tue Jan 14 15:49:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 Jan 2025 15:49:50 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Fri, 22 Nov 2024 22:14:12 GMT, Martin Fox wrote: >> I'll take a look at it after Thanksgiving. >> >> Somewhat related questions (sorry if totally unrelated): >> >> Q1. shouldn't the input method be tied to the `Scene.focusOwner` property somehow? >> Q2. given the fact that there could be only one active IM in the application, shouldn't there be a static `currentInputFocusOwner` property somewhere? > > @andy-goryachev-oracle I'll answer your questions in reverse order. > >> Q2. given the fact that there could be only one active IM in the application, shouldn't there be a static >> currentInputFocusOwner property somewhere? > > It's better to think that there's a separate IM associated with each operating system window but the OS only shows one at any time. That's the way the operating system API's work. > > There hasn't been any reason to track this inside JavaFX. Normally the OS tracks which Scene has focus and we track which Node is the focusOwner in that Scene and that's all the bookkeeping we need. Things only get complicated with PopupWindows. > >> Q1. shouldn't the input method be tied to the Scene.focusOwner property somehow? > > Normally we do connect the input method with the Scene.focusOwner. But when PopupWindows are open keyboard events from one peer window are distributed across multiple Scenes so there's more than one focusOwner we could connect the input method to. It's up to JavaFX to figure out which Scene's focusOwner is relevant. @beldenfox This is now ready for you to integrate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1634#issuecomment-2590300658 From angorya at openjdk.org Tue Jan 14 15:59:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 Jan 2025 15:59:19 GMT Subject: RFR: 8347715: RichTextArea Follow-up: Minor Bugs Message-ID: Found during writing the API tests: - setUseContentHeight/Width (true -> on) - remove unnecessary non-nullable limitation for caretBlinkProperty ------------- Commit messages: - 8347715: RichTextArea Follow-up: Minor Bugs Changes: https://git.openjdk.org/jfx/pull/1676/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1676&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347715 Stats: 24 lines in 2 files changed: 3 ins; 12 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1676.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1676/head:pull/1676 PR: https://git.openjdk.org/jfx/pull/1676 From kcr at openjdk.org Tue Jan 14 16:01:47 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 Jan 2025 16:01:47 GMT Subject: RFR: 8347715: RichTextArea Follow-up: Minor Bugs In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:41:38 GMT, Andy Goryachev wrote: > Found during writing the API tests: > > - setUseContentHeight/Width (true -> on) > - remove unnecessary non-nullable limitation for caretBlinkProperty The change to setUseContentWidth / Height is an obviously correct fix. I am not in favor of the change to caretBlink period. Returning null as a default is not how we do things for numeric values. See Tooltip::showDelay, for example. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 394: > 392: * > 393: * @return the caret blink period property > 394: * @defaultValue null I am not in favor of this change. From a user API perspective, the default should be 1000 ms, regardless of whether or not null should be also treated as valid, and treated as 1000 ms. Separately, I'm not sure I see the need for allowing null, but there might be a reason I'm missing. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 413: > 411: > 412: public final Duration getCaretBlinkPeriod() { > 413: return caretBlinkPeriod == null ? null : caretBlinkPeriod.get(); This just makes the API harder to use. Why push the burden to the application? ------------- PR Review: https://git.openjdk.org/jfx/pull/1676#pullrequestreview-2550174512 PR Review Comment: https://git.openjdk.org/jfx/pull/1676#discussion_r1915095668 PR Review Comment: https://git.openjdk.org/jfx/pull/1676#discussion_r1915097291 From angorya at openjdk.org Tue Jan 14 16:10:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 Jan 2025 16:10:00 GMT Subject: RFR: 8347715: RichTextArea Follow-up: Minor Bugs [v2] In-Reply-To: References: Message-ID: > Found during writing the API tests: > > - setUseContentHeight/Width (true -> on) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: revert nullable change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1676/files - new: https://git.openjdk.org/jfx/pull/1676/files/04bde3e4..c856986e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1676&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1676&range=00-01 Stats: 21 lines in 2 files changed: 12 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1676.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1676/head:pull/1676 PR: https://git.openjdk.org/jfx/pull/1676 From angorya at openjdk.org Tue Jan 14 16:10:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 Jan 2025 16:10:00 GMT Subject: RFR: 8347715: RichTextArea Follow-up: Minor Bugs [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:50:49 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> revert nullable change > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 413: > >> 411: >> 412: public final Duration getCaretBlinkPeriod() { >> 413: return caretBlinkPeriod == null ? null : caretBlinkPeriod.get(); > > This just makes the API harder to use. Why push the burden to the application? reverted. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1676#discussion_r1915130062 From kcr at openjdk.org Tue Jan 14 16:12:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 Jan 2025 16:12:46 GMT Subject: RFR: 8347715: RichTextArea Follow-up: Minor Bugs [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 16:10:00 GMT, Andy Goryachev wrote: >> Found during writing the API tests: >> >> - setUseContentHeight/Width (true -> on) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > revert nullable change LGTM. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1676#pullrequestreview-2550239752 From mfox at openjdk.org Tue Jan 14 17:30:52 2025 From: mfox at openjdk.org (Martin Fox) Date: Tue, 14 Jan 2025 17:30:52 GMT Subject: Integrated: 8288893: Popup and its subclasses cannot input text from InputMethod In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 17:57:30 GMT, Martin Fox wrote: > Input methods don?t work for text controls inside Popups. This PR fixes that. > > Some background: > > A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. > > Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. > > The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. > > There are several reasons why Input Methods aren?t currently working for Popups. > > - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. > > - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. > > - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. > > In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. > > This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the change. In this PR the InputMethodStateManage... This pull request has now been integrated. Changeset: 90ea0f07 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/90ea0f07b3a8df0d39e7e31222d08931201368a1 Stats: 280 lines in 4 files changed: 265 ins; 10 del; 5 mod 8288893: Popup and its subclasses cannot input text from InputMethod Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1634 From angorya at openjdk.org Tue Jan 14 21:26:48 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 Jan 2025 21:26:48 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction @henrykdz : could you please attach the video clip to https://bugs.openjdk.org/browse/JDK-8347464 ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2591129445 From angorya at openjdk.org Tue Jan 14 23:58:30 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 Jan 2025 23:58:30 GMT Subject: RFR: 8347752: Running RichTextArea demos via ant on JDK 24 prints warnings Message-ID: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> added --enable-native-access=javafx.graphics --sun-misc-unsafe-memory-access=allow flags to the command line which starts the demos. ------------- Commit messages: - 8347752: Running RichTextArea demos via ant on JDK 24 prints warnings Changes: https://git.openjdk.org/jfx/pull/1678/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1678&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347752 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1678.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1678/head:pull/1678 PR: https://git.openjdk.org/jfx/pull/1678 From mstrauss at openjdk.org Wed Jan 15 00:37:49 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 15 Jan 2025 00:37:49 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations Message-ID: Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. ------------- Commit messages: - allow sublists to be used for bulk operations - failing tests Changes: https://git.openjdk.org/jfx/pull/1679/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1679&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347753 Stats: 140 lines in 2 files changed: 89 ins; 5 del; 46 mod Patch: https://git.openjdk.org/jfx/pull/1679.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1679/head:pull/1679 PR: https://git.openjdk.org/jfx/pull/1679 From mstrauss at openjdk.org Wed Jan 15 00:55:24 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 15 Jan 2025 00:55:24 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v37] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. 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/extended-window - fix resizable states for GTK windows - add StageStyle.EXTENDED_UTILITY - fix system menu for non-resizeable extended window - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java - StyleableBooleanProperty -> BooleanProperty - Add HeaderBar.overlappingSystemInset property - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKScene.java # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java - Merge branch 'master' into feature/extended-window - macOS: double-click action + fullscreen toolbar - ... and 36 more: https://git.openjdk.org/jfx/compare/90ea0f07...cbb32165 ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=36 Stats: 5154 lines in 61 files changed: 4611 ins; 426 del; 117 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 lkostyra at openjdk.org Wed Jan 15 11:32:51 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 15 Jan 2025 11:32:51 GMT Subject: RFR: 8347752: Running RichTextArea demos via ant on JDK 24 prints warnings In-Reply-To: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> References: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> Message-ID: <3B5b3VNl07C_dWydIjhmoBuQvm-ncavcP6zej5hcHig=.2717076b-ae19-4a4e-a4a3-b8a67ca797af@github.com> On Tue, 14 Jan 2025 23:50:33 GMT, Andy Goryachev wrote: > added > > --enable-native-access=javafx.graphics --sun-misc-unsafe-memory-access=allow > > flags to the command line which starts the demos. Pretty straightforward fix and can confirm it clears the warnings. LGTM ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1678#pullrequestreview-2552305720 From kcr at openjdk.org Wed Jan 15 12:38:42 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 Jan 2025 12:38:42 GMT Subject: RFR: 8347752: Running RichTextArea demos via ant on JDK 24 prints warnings In-Reply-To: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> References: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> Message-ID: On Tue, 14 Jan 2025 23:50:33 GMT, Andy Goryachev wrote: > added > > --enable-native-access=javafx.graphics --sun-misc-unsafe-memory-access=allow > > flags to the command line which starts the demos. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1678#pullrequestreview-2552581021 From angorya at openjdk.org Wed Jan 15 15:29:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 Jan 2025 15:29:42 GMT Subject: Integrated: 8347752: Running RichTextArea demos via ant on JDK 24 prints warnings In-Reply-To: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> References: <9IABd9a3tvRYMPSmb0lgovOgsDtRal_X6mkRJOh2pwA=.e299f715-f5af-49c6-a1b1-f3a831f9eb07@github.com> Message-ID: On Tue, 14 Jan 2025 23:50:33 GMT, Andy Goryachev wrote: > added > > --enable-native-access=javafx.graphics --sun-misc-unsafe-memory-access=allow > > flags to the command line which starts the demos. This pull request has now been integrated. Changeset: c692192d Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/c692192d3587a5149673aade35b30f14d705afe7 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8347752: Running RichTextArea demos via ant on JDK 24 prints warnings Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1678 From angorya at openjdk.org Wed Jan 15 15:31:44 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 Jan 2025 15:31:44 GMT Subject: Integrated: 8347715: RichTextArea Follow-up: Minor Bugs In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:41:38 GMT, Andy Goryachev wrote: > Found during writing the API tests: > > - setUseContentHeight/Width (true -> on) This pull request has now been integrated. Changeset: a95151e1 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/a95151e14a7095f169724469885b1e79097fb7e0 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8347715: RichTextArea Follow-up: Minor Bugs Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1676 From angorya at openjdk.org Wed Jan 15 15:41:23 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 Jan 2025 15:41:23 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - in case of hitting min max - Merge branch 'master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - ... and 29 more: https://git.openjdk.org/jfx/compare/a95151e1...f365f3dd ------------- Changes: https://git.openjdk.org/jfx/pull/1156/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=05 Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From angorya at openjdk.org Wed Jan 15 15:41:24 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 Jan 2025 15:41:24 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v5] In-Reply-To: <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com> Message-ID: <3ZYwOq53ypAIV6GNSjeTboeyiXplWvT32Lq_OvGN-kk=.03c04db0-3c36-4514-bb94-9bf16fe9b81d@github.com> On Mon, 4 Nov 2024 17:21:57 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev 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 remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - ... and 28 more: https://git.openjdk.org/jfx/compare/5bf02be0...7c947083 keep-alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2593251016 From kevin.rushforth at oracle.com Wed Jan 15 19:17:36 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 15 Jan 2025 11:17:36 -0800 Subject: FINAL REMINDER: JavaFX 24 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 24] In-Reply-To: References: Message-ID: <1818d7bb-a5e2-4919-b32a-e0330020d414@oracle.com> As a reminder, JavaFX 24 RDP1 starts tomorrow, January 16th. I will fork the 'jfx24' branch at 16:00 UTC. -- Kevin On 12/19/2024 4:05 PM, Kevin Rushforth wrote: > As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 24 starts on > Thursday, January 16, 2025 at 16:00 UTC (08:00 US/Pacific time). Given > the upcoming holidays, that's a little over 2 working weeks from now. > > During rampdown of JavaFX 24, the "master" branch of the jfx repo will > be open for JavaFX 25 fixes. > > Please allow sufficient time for any feature that needs a CSR. New > features should be far enough along in the review process that you can > finalize the CSR no later than Thursday, January 9, or it is likely to > miss the window for this release, in which case it can be targeted for > JavaFX 25. > > We will follow the same process as in previous releases for getting > fixes into JavaFX 24 during rampdown. I'll send a message with > detailed information when we fork, but candidates for fixing during > RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc > bugs of any priority. Some small enhancements might be considered > during RDP1, but they require explicit approval; the bar will be high > for such requests. > > -- Kevin > > > On 10/25/2024 11:34 AM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 24: >> >> RDP1: Jan 16, 2025 (aka ?feature freeze?) >> RDP2: Feb 6, 2025 >> Freeze: Feb 27, 2025 >> GA: Mar 18, 2025 >> >> We plan to fork a jfx24 stabilization branch at RDP1. >> >> The start of RDP1, the start of RDP2, and the code freeze will be >> 16:00 UTC on the respective dates. >> >> This schedule moves the RDP1 and RDP2 start dates back one week to >> better avoid running into the holidays like we usually do. This will >> give one extra week before RDP1 starts and one less week during RDP2 >> (we historically have few fixes coming in during RDP2). We intend to >> use this as the new formula for computing the release schedule going >> forward. >> >> Please let Johan or me know if you have any questions. >> >> -- Kevin >> > From angorya at openjdk.org Thu Jan 16 00:10:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 00:10:50 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 00:32:37 GMT, Michael Strau? wrote: > Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. > > However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 391: > 389: > 390: /** > 391: * Returns the specified collection as an unmodifiable list that can safely be used in all bulk Do you think it might be easier to create a defensive copy **always**? In other words, can we guarantee that it is impossible for the user to create a convoluted code involving maybe two `VetoableListDecorators` where the second one loops back the changes to the first one, however ridiculous that might sound? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1917493626 From mstrauss at openjdk.org Thu Jan 16 00:33:46 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 16 Jan 2025 00:33:46 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 00:07:49 GMT, Andy Goryachev wrote: >> Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. >> >> However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. > > modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 391: > >> 389: >> 390: /** >> 391: * Returns the specified collection as an unmodifiable list that can safely be used in all bulk > > Do you think it might be easier to create a defensive copy **always**? > > In other words, can we guarantee that it is impossible for the user to create a convoluted code involving maybe two `VetoableListDecorators` where the second one loops back the changes to the first one, however ridiculous that might sound? The way I see it, the situation that erroneously triggers `ConcurrentModificationException` only happens when `VetoableListDecorator` accesses its own sublist: try { modCount++; boolean ret = list.addAll(index, c); // --> c is its own sublist ... Since `modCount` is modified first, and the sublist refers back to the same modified `modCount`, the exception occurs. It can't occur when we are dealing with another list (or a sublist of another list), since in this case there is no self-referential conflict. The way `ArrayList` circumvents this problem is by incrementing `modCount` only after the operation is done, not before it has started; it doesn't create a defensive copy. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1917507388 From duke at openjdk.org Thu Jan 16 05:15:51 2025 From: duke at openjdk.org (Abhinay Agarwal) Date: Thu, 16 Jan 2025 05:15:51 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 In-Reply-To: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: On Mon, 13 Jan 2025 19:02:33 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 23.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=47027 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=47026 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/35#pullrequestreview-2554814053 From jvos at openjdk.org Thu Jan 16 07:20:52 2025 From: jvos at openjdk.org (Johan Vos) Date: Thu, 16 Jan 2025 07:20:52 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewVirtualizationTest.java line 177: > 175: tableView.getColumns().addFirst(tableColumn); > 176: > 177: // Needs a double pulse so that the viewport breadth is correctly calculated. This worries me a bit (the double pulse happens on a few places in the new tests). I would expect the platform to deal with is, so when a test requires 2 explicit pulse requests, it sounds like an issue. Why can't this be done with a single request? (and then waiting until the pulse and pending runnables on the FX Thread have finished)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1917861575 From mhanl at openjdk.org Thu Jan 16 08:26:46 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 08:26:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> On Thu, 16 Jan 2025 07:18:07 GMT, Johan Vos wrote: >> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java >> - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() >> - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewVirtualizationTest.java line 177: > >> 175: tableView.getColumns().addFirst(tableColumn); >> 176: >> 177: // Needs a double pulse so that the viewport breadth is correctly calculated. > > This worries me a bit (the double pulse happens on a few places in the new tests). I would expect the platform to deal with is, so when a test requires 2 explicit pulse requests, it sounds like an issue. > Why can't this be done with a single request? (and then waiting until the pulse and pending runnables on the FX Thread have finished)? Unfortunately I don't think there is any other way. The `VirtualFlow` needs two pulses (in real life applications) as the first time, the layout is not yet correct for some cases (e.g. for `No ScrollBar` -> `ScrollBar`). I even used some watchpoints to confirm this behavior. You can see the same thing in the `VirtualFlowTest.setUp` method, which initializes the flow and does two `pulse` calls after. So I think this is a premature problem, which probably can be fixed, but more refactorings/optimzations are needed (some of which I want to file a PR when I have more time). Maybe at some point we can completely eliminate this problem, but I don't think I can do that here in this PR (unless you have an idea, which is very much welcome!) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1917939496 From jpereda at openjdk.org Thu Jan 16 11:17:54 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 16 Jan 2025 11:17:54 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction I tested the PR, and it improves the scrolling performance in some cases, without noticeable side effects. I left some comments. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 108: > 106: }); > 107: } else { > 108: DoubleProperty fixedCellSizeProperty = tableView.fixedCellSizeProperty(); Minor: Since you are modifying this part of the code, the method `setupTreeTableViewListeners` should be renamed to `setupTableViewListeners` (I see this is already done in your other PR #1645, but it wouldn't hurt doing it here too) ------------- PR Review: https://git.openjdk.org/jfx/pull/1644#pullrequestreview-2553639094 PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1917186526 From jpereda at openjdk.org Thu Jan 16 11:17:55 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 16 Jan 2025 11:17:55 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 221: > 219: /** {@inheritDoc} */ > 220: @Override protected void layoutChildren(double x, double y, double w, double h) { > 221: Node disclosureNode = getDisclosureNode(); I take these changes (related to disclosure node) are not really related to the initial issue of this PR, and I wonder if [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) should not be part of this PR. Do the added tests verify these changes and if the issue is solved with them? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1917224008 From jpereda at openjdk.org Thu Jan 16 11:17:56 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 16 Jan 2025 11:17:56 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> References: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> Message-ID: On Thu, 16 Jan 2025 08:24:26 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewVirtualizationTest.java line 177: >> >>> 175: tableView.getColumns().addFirst(tableColumn); >>> 176: >>> 177: // Needs a double pulse so that the viewport breadth is correctly calculated. >> >> This worries me a bit (the double pulse happens on a few places in the new tests). I would expect the platform to deal with is, so when a test requires 2 explicit pulse requests, it sounds like an issue. >> Why can't this be done with a single request? (and then waiting until the pulse and pending runnables on the FX Thread have finished)? > > Unfortunately I don't think there is any other way. The `VirtualFlow` needs two pulses (in real life applications) as the first time, the layout is not yet correct for some cases (e.g. for `No ScrollBar` -> `ScrollBar`). I even used some watchpoints to confirm this behavior. > > You can see the same thing in the `VirtualFlowTest.setUp` method, which initializes the flow and does two `pulse` calls after. So I think this is a premature problem, which probably can be fixed, but more refactorings/optimzations are needed (some of which I want to file a PR when I have more time). > Maybe at some point we can completely eliminate this problem, but I don't think I can do that here in this PR (unless you have an idea, which is very much welcome!) Maybe the name `pulse` in the test you point out is misleading, since it actually calls `flow.layout()`, and two layout passes is not the same as two pulses. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918271233 From mhanl at openjdk.org Thu Jan 16 12:15:48 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 12:15:48 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: <2hWF_GdPBiTs8bFuqo1zljmmP2ztRvU5_o82PUXM1ok=.62603990-a849-41b2-b445-9de0691a9669@github.com> On Wed, 15 Jan 2025 18:50:58 GMT, Jose Pereda wrote: >> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization >> >> # Conflicts: >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java >> # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java >> - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() >> - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 108: > >> 106: }); >> 107: } else { >> 108: DoubleProperty fixedCellSizeProperty = tableView.fixedCellSizeProperty(); > > Minor: Since you are modifying this part of the code, the method `setupTreeTableViewListeners` should be renamed to `setupTableViewListeners` > (I see this is already done in your other PR #1645, but it wouldn't hurt doing it here too) Sure, will change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918347783 From mhanl at openjdk.org Thu Jan 16 12:15:49 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 12:15:49 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> Message-ID: On Thu, 16 Jan 2025 11:12:25 GMT, Jose Pereda wrote: >> Unfortunately I don't think there is any other way. The `VirtualFlow` needs two pulses (in real life applications) as the first time, the layout is not yet correct for some cases (e.g. for `No ScrollBar` -> `ScrollBar`). I even used some watchpoints to confirm this behavior. >> >> You can see the same thing in the `VirtualFlowTest.setUp` method, which initializes the flow and does two `pulse` calls after. So I think this is a premature problem, which probably can be fixed, but more refactorings/optimzations are needed (some of which I want to file a PR when I have more time). >> Maybe at some point we can completely eliminate this problem, but I don't think I can do that here in this PR (unless you have an idea, which is very much welcome!) > > Maybe the name `pulse` in the test you point out is misleading, since it actually calls `flow.layout()`, and two layout passes is not the same as two pulses. That is right, but the `pulse` call will call `layout`, which will call `layoutChildren` (when needed). I could also just call `layout` directly, but want to keep it the same way as the actual Application would behave. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918345247 From mhanl at openjdk.org Thu Jan 16 12:23:44 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 12:23:44 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v5] In-Reply-To: References: Message-ID: > This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. > > In order to do that, there are multiple things needed: > - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there > - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) > - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) > - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns > - As before, the `TableRow` adds or removes cells that are visible or not. > Note that this is only done when a fixed cell size is set. > The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later > - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: > - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells > Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself > - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-8276326](https://bugs.openjdk.org... Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8185887: Rename method to fit domain ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1644/files - new: https://git.openjdk.org/jfx/pull/1644/files/5a089858..7958273d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1644&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1644&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1644.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1644/head:pull/1644 PR: https://git.openjdk.org/jfx/pull/1644 From mhanl at openjdk.org Thu Jan 16 12:23:46 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 12:23:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 19:22:50 GMT, Jose Pereda wrote: >> Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 221: > >> 219: /** {@inheritDoc} */ >> 220: @Override protected void layoutChildren(double x, double y, double w, double h) { >> 221: Node disclosureNode = getDisclosureNode(); > > I take these changes (related to disclosure node) are not really related to the initial issue of this PR, and I wonder if [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) should not be part of this PR. Do the added tests verify these changes and if the issue is solved with them? This is more likely an 'accidential' fix. I changed this code because the code in the super class changed (e.g. `updateCells` and `updateChildren`). So while I see your point, if possible I would not try to cherrypick this out (if even possible) and keep it in here. Good point, I will check if I can write a test for it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918362810 From mhanl at openjdk.org Thu Jan 16 12:28:46 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 12:28:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 12:18:03 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 221: >> >>> 219: /** {@inheritDoc} */ >>> 220: @Override protected void layoutChildren(double x, double y, double w, double h) { >>> 221: Node disclosureNode = getDisclosureNode(); >> >> I take these changes (related to disclosure node) are not really related to the initial issue of this PR, and I wonder if [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) should not be part of this PR. Do the added tests verify these changes and if the issue is solved with them? > > This is more likely an 'accidential' fix. I changed this code because the code in the super class changed (e.g. `updateCells` and `updateChildren`). So while I see your point, if possible I would not try to cherrypick this out (if even possible) and keep it in here. > Good point, I will check if I can write a test for it. EDIT: The issue is about the `TreeView` specifically, so this code is not related to the issue. The fix is in the `VirtualFlow`, which I did for the tables, which also fixes the issue for the `TreeView`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918385437 From lkostyra at openjdk.org Thu Jan 16 12:53:03 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 16 Jan 2025 12:53:03 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v33] In-Reply-To: <2hnd8cohA6wC2jORmNbIt833ALLLcNZRi8ejB2skAno=.dfd7251c-f64f-4d0a-9d55-aa9f44bd86a0@github.com> References: <2hnd8cohA6wC2jORmNbIt833ALLLcNZRi8ejB2skAno=.dfd7251c-f64f-4d0a-9d55-aa9f44bd86a0@github.com> Message-ID: On Sun, 15 Dec 2024 22:11:30 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with three additional commits since the last revision: > > - Better solution for fcitx > - Revert "Fixes for fcitx" > > This reverts commit d8b38ea8f1379f9783d9186e462b0652ae7fd98b. > - Revert "Fixes for fcitx" > > This reverts commit 6cd1d32a51149df2cbe36f0b348a464173422201. Holiday season went in the way of wrapping this up last year, but I finally got a chance to come back to it and finish the review. Code-review-wise looks good. I also run the tests on my Ubuntu 24.04 and did not notice any abnormalities. @kevinrushforth also wanted to take a look at this after me. ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1080#pullrequestreview-2555932036 From kcr at openjdk.org Thu Jan 16 13:08:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 13:08:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v30] In-Reply-To: References: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> Message-ID: On Wed, 4 Dec 2024 20:07:57 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - Revert "Set IBUS_ENABLE_SYNC_MODE=1" >> >> This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. > > Done (merged master) @tsayao Can you merge in the latest master? You will need to resolve a merge conflict when doing so. I mainly want to review the native code changes, which I can do in parallel. I'll also fire off a CI headful test run, which does need to wait for the merge conflict resolution. This is going to miss the RDP1 deadline for jfx24, but might be a candidate for getting into jfx24 during RDP1 if done soon (it would need a late enhancement request). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2595588284 From tsayao at openjdk.org Thu Jan 16 13:47:29 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 16 Jan 2025 13:47:29 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v34] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) 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 120 commits: - Merge branch 'master' into new_ime # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp - Better solution for fcitx - Revert "Fixes for fcitx" This reverts commit d8b38ea8f1379f9783d9186e462b0652ae7fd98b. - Revert "Fixes for fcitx" This reverts commit 6cd1d32a51149df2cbe36f0b348a464173422201. - Fixes for fcitx - Fixes for fcitx - Merge branch 'master' into new_ime - Set IBUS_ENABLE_SYNC_MODE=1 - Revert "Set IBUS_ENABLE_SYNC_MODE=1" This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. - Set IBUS_ENABLE_SYNC_MODE=1 - ... and 110 more: https://git.openjdk.org/jfx/compare/a95151e1...da8c7b30 ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=33 Stats: 454 lines in 7 files changed: 68 ins; 267 del; 119 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Thu Jan 16 13:55:53 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 16 Jan 2025 13:55:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v30] In-Reply-To: References: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> Message-ID: On Thu, 16 Jan 2025 13:05:39 GMT, Kevin Rushforth wrote: >> Done (merged master) > > @tsayao Can you merge in the latest master? You will need to resolve a merge conflict when doing so. > > I mainly want to review the native code changes, which I can do in parallel. I'll also fire off a CI headful test run, which does need to wait for the merge conflict resolution. > > This is going to miss the RDP1 deadline for jfx24, but might be a candidate for getting into jfx24 during RDP1 if done soon (it would need a late enhancement request). @kevinrushforth Done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2595752817 From kcr at openjdk.org Thu Jan 16 14:09:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 14:09:52 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v34] In-Reply-To: References: Message-ID: <8A7jsGG45h3yv2LyiVLuE2wwazxNU8fET3HUAkjMVkU=.42b51beb-4d5d-4336-a61d-1e70aba30d50@github.com> On Thu, 16 Jan 2025 13:47:29 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > 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 120 commits: > > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Better solution for fcitx > - Revert "Fixes for fcitx" > > This reverts commit d8b38ea8f1379f9783d9186e462b0652ae7fd98b. > - Revert "Fixes for fcitx" > > This reverts commit 6cd1d32a51149df2cbe36f0b348a464173422201. > - Fixes for fcitx > - Fixes for fcitx > - Merge branch 'master' into new_ime > - Set IBUS_ENABLE_SYNC_MODE=1 > - Revert "Set IBUS_ENABLE_SYNC_MODE=1" > > This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. > - Set IBUS_ENABLE_SYNC_MODE=1 > - ... and 110 more: https://git.openjdk.org/jfx/compare/a95151e1...da8c7b30 Can you double-check the merge? Your merge lost these lines which is probably not intended. + + // Set ibus to sync mode + setenv("IBUS_ENABLE_SYNC_MODE", "1", 1); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2595816225 From tsayao at openjdk.org Thu Jan 16 14:32:14 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 16 Jan 2025 14:32:14 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v35] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Restore unintended change from merging master ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/da8c7b30..756d19ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=34 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=33-34 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Thu Jan 16 14:32:15 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 16 Jan 2025 14:32:15 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v34] In-Reply-To: References: Message-ID: <2Zm7r715OtXhwJOsC27bqPu_6CZOpEO4tSr8MmzXHeY=.04ad0ddf-a69b-43c3-b8e0-79fe84fedd80@github.com> On Thu, 16 Jan 2025 13:47:29 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > 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 120 commits: > > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Better solution for fcitx > - Revert "Fixes for fcitx" > > This reverts commit d8b38ea8f1379f9783d9186e462b0652ae7fd98b. > - Revert "Fixes for fcitx" > > This reverts commit 6cd1d32a51149df2cbe36f0b348a464173422201. > - Fixes for fcitx > - Fixes for fcitx > - Merge branch 'master' into new_ime > - Set IBUS_ENABLE_SYNC_MODE=1 > - Revert "Set IBUS_ENABLE_SYNC_MODE=1" > > This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. > - Set IBUS_ENABLE_SYNC_MODE=1 > - ... and 110 more: https://git.openjdk.org/jfx/compare/a95151e1...da8c7b30 Sorry about that. Fixed it ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2595879942 From kcr at openjdk.org Thu Jan 16 15:11:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 15:11:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v35] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 14:32:14 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Restore unintended change from merging master This looks good. Nice work! And we do have time (a little less than one hour) to get this into jfx24 if you want to. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1080#pullrequestreview-2556449526 From kcr at openjdk.org Thu Jan 16 15:23:04 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 15:23:04 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v30] In-Reply-To: References: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> Message-ID: On Wed, 4 Dec 2024 17:16:39 GMT, Lukasz Kostyra wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - Revert "Set IBUS_ENABLE_SYNC_MODE=1" >> >> This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. > > I think this is almost ready, it's been on my backlog for a while and I'd like to give it one more look and some final testing. > > @tsayao can you merge latest master? Since the merge was trivial, and I verified that no substantive changes to what @lukostyra reviewed and tested, I will lower the number of (re)reviews required to 1. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2596005264 From kcr at openjdk.org Thu Jan 16 15:23:05 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 15:23:05 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v34] In-Reply-To: <2Zm7r715OtXhwJOsC27bqPu_6CZOpEO4tSr8MmzXHeY=.04ad0ddf-a69b-43c3-b8e0-79fe84fedd80@github.com> References: <2Zm7r715OtXhwJOsC27bqPu_6CZOpEO4tSr8MmzXHeY=.04ad0ddf-a69b-43c3-b8e0-79fe84fedd80@github.com> Message-ID: <4t5QhDCZx-YN0C4uqMKxf2lyaPOlrPy2Ea9EbnkSLZQ=.9026c7ea-d702-4c3b-b85a-9994b30d38a9@github.com> On Thu, 16 Jan 2025 14:29:31 GMT, Thiago Milczarek Sayao wrote: >> 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 120 commits: >> >> - Merge branch 'master' into new_ime >> >> # Conflicts: >> # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp >> - Better solution for fcitx >> - Revert "Fixes for fcitx" >> >> This reverts commit d8b38ea8f1379f9783d9186e462b0652ae7fd98b. >> - Revert "Fixes for fcitx" >> >> This reverts commit 6cd1d32a51149df2cbe36f0b348a464173422201. >> - Fixes for fcitx >> - Fixes for fcitx >> - Merge branch 'master' into new_ime >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - Revert "Set IBUS_ENABLE_SYNC_MODE=1" >> >> This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - ... and 110 more: https://git.openjdk.org/jfx/compare/a95151e1...da8c7b30 > > Sorry about that. Fixed it @tsayao This is now ready for you to integrate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2596010120 From tsayao at openjdk.org Thu Jan 16 15:31:55 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 16 Jan 2025 15:31:55 GMT Subject: Integrated: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) This pull request has now been integrated. Changeset: 069db877 Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/069db877e1c6471a108316701c3136b01cc8f18e Stats: 457 lines in 7 files changed: 71 ins; 267 del; 119 mod 8305418: [Linux] Replace obsolete XIM as Input Method Editor Reviewed-by: kcr, mfox, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1080 From duke at openjdk.org Thu Jan 16 15:41:53 2025 From: duke at openjdk.org (Glavo) Date: Thu, 16 Jan 2025 15:41:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v35] In-Reply-To: References: Message-ID: <72QMAyQvyu3g3ToMjBz-WnPuVgPlPaYGX4YNx2bR2l0=.c3b6d00f-3d36-4859-b12f-28e20a609332@github.com> On Thu, 16 Jan 2025 14:32:14 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Restore unintended change from merging master This is awesome! Is there a plan to backport this PR to OpenJFX 17? This PR is very important for users in East Asia, so we hope it will be part of OpenJFX 24 and backported to OpenJFX 17/21. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2596054110 From angorya at openjdk.org Thu Jan 16 15:49:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 15:49:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> Message-ID: <7e2LH5nFRRMLhKm5REFzv6hf88Hk9NjW1Ky2iAnH3RA=.23fbd8bc-7b2b-414a-95b6-84ff87282bd0@github.com> On Thu, 16 Jan 2025 12:11:37 GMT, Marius Hanl wrote: >> Maybe the name `pulse` in the test you point out is misleading, since it actually calls `flow.layout()`, and two layout passes is not the same as two pulses. > > That is right, but the `pulse` call will call `layout`, which will call `layoutChildren` (when needed). I could also just call `layout` directly, but want to keep it the same way as the actual Application would behave. Relying on two pulses may cause flicker (I had a similar issue with the RichTextArea). The solution is to re-compute the layout in layoutChildren() when needed (i.e. when scroll bar status changes). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918790333 From mhanl at openjdk.org Thu Jan 16 16:04:17 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 16:04:17 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v6] In-Reply-To: References: Message-ID: > This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. > > In order to do that, there are multiple things needed: > - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there > - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) > - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) > - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns > - As before, the `TableRow` adds or removes cells that are visible or not. > Note that this is only done when a fixed cell size is set. > The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later > - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: > - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells > Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself > - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-8276326](https://bugs.openjdk.org... Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - 8185887: Test for the TreeView graphic disappearance problem (JDK-8346824) - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization - 8185887: Rename method to fit domain - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction ------------- Changes: https://git.openjdk.org/jfx/pull/1644/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1644&range=05 Stats: 1425 lines in 15 files changed: 1245 ins; 142 del; 38 mod Patch: https://git.openjdk.org/jfx/pull/1644.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1644/head:pull/1644 PR: https://git.openjdk.org/jfx/pull/1644 From mhanl at openjdk.org Thu Jan 16 16:04:17 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 16:04:17 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: <_apK_hmquJzmKXarpD6MwFQE8Bte2eXoBBJKqz01ha8=.2dcd3c70-de14-438d-8059-af7c28f059c0@github.com> On Thu, 16 Jan 2025 12:26:19 GMT, Marius Hanl wrote: >> This is more likely an 'accidential' fix. I changed this code because the code in the super class changed (e.g. `updateCells` and `updateChildren`). So while I see your point, if possible I would not try to cherrypick this out (if even possible) and keep it in here. >> Good point, I will check if I can write a test for it. > > EDIT: The issue is about the `TreeView` specifically, so this code is not related to the issue (it is in `TreeTableRowSkin`). > The fix is in the `VirtualFlow`, which I did for the table virtualization (issues), but that also fixes the issue for the `TreeView` as well. EDIT2: I wrote a test, that fails before and succeeds after for that specific problem! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1918811739 From kcr at openjdk.org Thu Jan 16 16:04:55 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 16:04:55 GMT Subject: Integrated: 8347598: Change JavaFX release version to 25 In-Reply-To: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> References: <4tgOHz5_vZCWzectLzCmQ1Zjp-nYIJsiOXHhjOqfR1s=.0788d1f0-f5ec-43d6-8361-a729194d299e@github.com> Message-ID: On Mon, 13 Jan 2025 16:25:06 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 25. I will integrate this to master as part of forking the jfx24 stabilization branch, which is scheduled for Thursday, January 16, 2025 at 16:00 UTC. This pull request has now been integrated. Changeset: d07d408f Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/d07d408fa79e25a02b0d5e2f9aeb3990a7136077 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8347598: Change JavaFX release version to 25 Reviewed-by: angorya, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1673 From kevin.rushforth at oracle.com Thu Jan 16 16:14:29 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 16 Jan 2025 08:14:29 -0800 Subject: JavaFX 24 is in Rampdown Phase One (RDP1) Message-ID: JavaFX 24 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx24 branch [2] for stabilizing the JavaFX 24 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for jfx25. Almost all fixes will be integrated to master for 25, even those intended to be fixed in 24. - The jfx24 branch of the jfx repo is now open for integrating fixes for jfx24 that meet the RDP1 criteria as outlined below. As with the previous release, in this release we will integrate almost all stabilization changes via backports from the master branch [3]. ? * Almost all fixes intended for the jfx24 stabilization branch will also be applicable to the master branch. Integrate such a change into the master branch first. Then, after you have obtained any required approvals, backport it to the stabilization branch using the Skara `/backport` command or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash.? (The JDK Developers? Guide contains more information on working with backports [4].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx24 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx24. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx24 branch. The master branch is open for all jfx25 fixes, including enhancements. As a reminder, we use a single openjdk/jfx GitHub repo with stabilization branches [5] rather than a separate stabilization repo. The jfx24 branch is used to stabilize the upcoming jfx24 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx24 to ensure that it doesn't contain any commits from master after the jfx24 fork date. What that means is that if you intend a PR to be for jfx24, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 25 as of today). This is usually what we want. A backport PR should be targeted to `jfx24` if, and only if, it is intended for JavaFX 24 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx24`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 25. Reviewers also need to be extra careful when reviewing PRs targeted to jfx24 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. This should be less of a problem for this release, since almost all PRs for jfx24 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. We will use the same rules for RDP1 that the JDK uses [6], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 24 release. As an obvious choice, derived from the JBS fix version, we will use "jfx24-enhancement-request", "jfx24-enhancement-yes", "jfx24-enhancement-no" and "jfx24-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx24 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should only go into master for jfx25, since we do not want to risk anything that would destabilize the jfx24 release without a compelling reason. Also, we have only 3 weeks until RDP2 of jfx24 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for jfx24 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050209.html [2] https://github.com/openjdk/jfx/tree/jfx24 [3] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [4] https://openjdk.org/guide/#working-with-backports-in-jbs [5] https://github.com/openjdk/jfx/branches/all [6] http://openjdk.org/jeps/3 From angorya at openjdk.org Thu Jan 16 16:59:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 16:59:42 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 00:31:16 GMT, Michael Strau? wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 391: >> >>> 389: >>> 390: /** >>> 391: * Returns the specified collection as an unmodifiable list that can safely be used in all bulk >> >> Do you think it might be easier to create a defensive copy **always**? >> >> In other words, can we guarantee that it is impossible for the user to create a convoluted code involving maybe two `VetoableListDecorators` where the second one loops back the changes to the first one, however ridiculous that might sound? > > The way I see it, the situation that erroneously triggers `ConcurrentModificationException` only happens when `VetoableListDecorator` accesses its own sublist: > > try { > modCount++; > boolean ret = list.addAll(index, c); // --> c is its own sublist > ... > > > Since `modCount` is modified first, and the sublist refers back to the same modified `modCount`, the exception occurs. It can't occur when we are dealing with another list (or a sublist of another list), since in this case there is no self-referential conflict. > > The way `ArrayList` circumvents this problem is by incrementing `modCount` only after the operation is done, not before it has started; it doesn't create a defensive copy. Thank you for clarification! I'll try to come up with a test (and I think even if I succeed, it does not mean that your solution is not good, since the caller can always create a defensive copy themselves). BTW, what were you doing to trigger this bug? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1918896531 From kcr at openjdk.org Thu Jan 16 17:17:44 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 Jan 2025 17:17:44 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v35] In-Reply-To: <72QMAyQvyu3g3ToMjBz-WnPuVgPlPaYGX4YNx2bR2l0=.c3b6d00f-3d36-4859-b12f-28e20a609332@github.com> References: <72QMAyQvyu3g3ToMjBz-WnPuVgPlPaYGX4YNx2bR2l0=.c3b6d00f-3d36-4859-b12f-28e20a609332@github.com> Message-ID: <1U8g8HGip5IKFdhftOLq_xDU2SzDtTbr53y6dxq4jlg=.0d23327e-03a8-43f9-8968-8b7cd8ded834@github.com> On Thu, 16 Jan 2025 15:37:56 GMT, Glavo wrote: > Is there a plan to backport this PR to OpenJFX 17? This PR is very important for users in East Asia, so we hope it will be part of OpenJFX 24 and backported to OpenJFX 17/21. It did make JavaFX 24. @johanvos will need to answer the question of whether to backport this to 21 or 17. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2596259254 From mstrauss at openjdk.org Thu Jan 16 17:26:07 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 16 Jan 2025 17:26:07 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 16:57:11 GMT, Andy Goryachev wrote: > BTW, what were you doing to trigger this bug? This happened when I was writing some tests for the other `VetoableListDecorator` PRs... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1918931247 From angorya at openjdk.org Thu Jan 16 18:29:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 18:29:50 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 00:32:37 GMT, Michael Strau? wrote: > Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. > > However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. The scenario I was referring to is impossible, I think. One possible alternative is to create the defensive copy each time, this will save one extra pointer every time an iterator or a sublist gets created (these objects might be long lived). The code in this PR creates a copy in many (most?) cases anyway, and in my opinion, the memory is more precious resource that CPU cycles (i.e. using extra memory costs many more CPU cycles in garbage collection etc.), so please consider that. + some minor suggestions modules/javafx.base/src/test/java/test/javafx/collections/VetoableObservableListTest.java line 212: > 210: list.addAll(list.subList(0, 2)); > 211: assertSingleCall(new String[] {"foo", "bar"}, new int[] {4, 4}); > 212: } suggestion: also check that the list contains the newly added elements? (here and in added tests that involve subList?) ------------- PR Review: https://git.openjdk.org/jfx/pull/1679#pullrequestreview-2556899713 PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1918996891 From angorya at openjdk.org Thu Jan 16 19:22:56 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 19:22:56 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v15] 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: <1_FLEjI1dLmJBVwpSvS9M_zcxcXqYl0nTgZW0kKSCng=.bd43c4e6-2c4d-42e6-b336-0815e8b9a3cd@github.com> > 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 24 > */ > 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 > > > This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: > > > /** > * Returns the shape for the strike-through in local coordinates. > * > * @param start the beginning character index for the range > * @param end the end character index (non-inclusive) for the range > * @return an array of {@code PathElement} which can be used to create a {@code Shape} > * @since 24 > */ > public final PathElement[] strikeThroughShape(int start, int end) > > > > > ## WARNING > > 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) ). > > > > ## 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 38 commits: - Merge branch 'master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge branch 'master' into ag.text.layout.api - segments - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - coordinates - note - text layout test - ... and 28 more: https://git.openjdk.org/jfx/compare/d07d408f...7d656dfb ------------- Changes: https://git.openjdk.org/jfx/pull/1596/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=14 Stats: 1514 lines in 14 files changed: 1443 ins; 21 del; 50 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 Jan 16 19:34:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 19:34:06 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v16] 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 > > > This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: > > > /** > * Returns the shape for the strike-through in local coordinates. > * > * @param start the beginning character index for the range > * @param end the end character index (non-inclusive) for the range > * @return an array of {@code PathElement} which can be used to create a {@code Shape} > * @since 25 > */ > public final PathElement[] strikeThroughShape(int start, int end) > > > > > ## WARNING > > 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) ). > > > > ## 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: 25 25 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1596/files - new: https://git.openjdk.org/jfx/pull/1596/files/7d656dfb..0ab58905 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=14-15 Stats: 22 lines in 14 files changed: 0 ins; 0 del; 22 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 Jan 16 19:53:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 19:53:49 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 19:22:50 GMT, Jose Pereda wrote: >> Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 221: > >> 219: /** {@inheritDoc} */ >> 220: @Override protected void layoutChildren(double x, double y, double w, double h) { >> 221: Node disclosureNode = getDisclosureNode(); > > I take these changes (related to disclosure node) are not really related to the initial issue of this PR, and I wonder if [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) should not be part of this PR. Do the added tests verify these changes and if the issue is solved with them? I second @jperedadnr concern about combining separate issues into one PR. Small focused PRs will get tested, reviewed, and integrated almost always faster than the big complicated ones. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1919120797 From angorya at openjdk.org Thu Jan 16 21:00:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 21:00:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v6] In-Reply-To: References: Message-ID: <4WGqrrfzSlFZfFIsJCWkhy7rp2bv-6LQXO4M3px7s58=.3fa2e560-9936-41fb-8e71-52a7ba2596f8@github.com> On Thu, 16 Jan 2025 16:04:17 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - 8185887: Test for the TreeView graphic disappearance problem (JDK-8346824) > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > - 8185887: Rename method to fit domain > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Can attest to the fact that two pulses are indeed needed when testing with the monkey tester (unconstrained resize policy, columns with "all constraints", 10 rows; resize to the point where both scrollbars are visible but very close to where the SB are not needed, then increase the height slowly). The good news is that I could not get it to flicker (at least on macOS, with 1:1 scale). I see SB disappears, then another ("two pulses"). Visually, it's the same behavior as with the master branch. The not-so-good news is that there is a configuration when the HSB remains, but once you click on it it disappears (might be hard to reproduce). In both this PR and with the master branch, the HSB remains even though it's not needed: ![Screenshot 2025-01-16 at 12 50 25](https://github.com/user-attachments/assets/ccc7a0ca-cc09-4204-aad2-96873204aeef) Nevertheless, I think the behavior is acceptable as the user can easily resize and most importantly there is no continuous flicker. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2596863832 From mhanl at openjdk.org Thu Jan 16 22:40:43 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 22:40:43 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v6] In-Reply-To: <4WGqrrfzSlFZfFIsJCWkhy7rp2bv-6LQXO4M3px7s58=.3fa2e560-9936-41fb-8e71-52a7ba2596f8@github.com> References: <4WGqrrfzSlFZfFIsJCWkhy7rp2bv-6LQXO4M3px7s58=.3fa2e560-9936-41fb-8e71-52a7ba2596f8@github.com> Message-ID: <-PQzbhDJKMOh87t_EC_0zwjd8CqTVNOZQjJXWm5QR94=.03c8cd31-5b95-4ce8-8d66-fa9db7768d9d@github.com> On Thu, 16 Jan 2025 20:50:47 GMT, Andy Goryachev wrote: > The not-so-good news is that there is a configuration when the HSB remains, but once you click on it it disappears (might be hard to reproduce). In both this PR and with the master branch, the HSB remains even though it's not needed: When I debugged the double pulse, I found out that the viewport breadth changed a little bit between the first and the second call. Which might also change the HSB. My guess is that this issue and the double pulse are related, I already thought about this when I found this out first when doing this PR. So yes, worth investigating at one point. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2597048352 From mhanl at openjdk.org Thu Jan 16 22:40:45 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 22:40:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 19:51:29 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 221: >> >>> 219: /** {@inheritDoc} */ >>> 220: @Override protected void layoutChildren(double x, double y, double w, double h) { >>> 221: Node disclosureNode = getDisclosureNode(); >> >> I take these changes (related to disclosure node) are not really related to the initial issue of this PR, and I wonder if [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) should not be part of this PR. Do the added tests verify these changes and if the issue is solved with them? > > I second @jperedadnr concern about combining separate issues into one PR. Small focused PRs will get tested, reviewed, and integrated almost always faster than the big complicated ones. Completely agree, but in this case, the fix for [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) is also the same for [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) - that is the `VirtualFlow` changes. It is not really possible to separate those issues. What I could try is to cherrypick the changes from the `VirtualFlow`, leaving out the virtualization optimizations. Although this was not the original point here. The reason those are together is that they are very closely related. Fixing the virtualization without the `VirtualFlow` will still break applications and tests because you can somewhat randomly get empty cells. Fixing the `VirtualFlow` first might work, but if you scroll enough you will get empty cells because of broken virtualization. So this PR got bigger in order to have a working virtualization and also scrolling behavior with no empty cells. If it really helps, I can split them up, as mentioned above. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1919325356 From angorya at openjdk.org Thu Jan 16 22:40:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 22:40:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 22:34:35 GMT, Marius Hanl wrote: >> I second @jperedadnr concern about combining separate issues into one PR. Small focused PRs will get tested, reviewed, and integrated almost always faster than the big complicated ones. > > Completely agree, but in this case, the fix for [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) is also the same for [JDK-8346824](https://bugs.openjdk.org/browse/JDK-8346824) - that is the `VirtualFlow` changes. > It is not really possible to separate those issues. > What I could try is to cherrypick the changes from the `VirtualFlow`, leaving out the virtualization optimizations. Although this was not the original point here. > > The reason those are together is that they are very closely related. Fixing the virtualization without the `VirtualFlow` will still break applications and tests because you can somewhat randomly get empty cells. > > Fixing the `VirtualFlow` first might work, but if you scroll enough you will get empty cells because of broken virtualization. > So this PR got bigger in order to have a working virtualization and also scrolling behavior with no empty cells. > If it really helps, I can split them up, as mentioned above. probably not worth it at this point, I think. We just need to be extra careful during the review to consider all the scenarios involved. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1919330155 From mhanl at openjdk.org Thu Jan 16 22:43:46 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 Jan 2025 22:43:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: <7e2LH5nFRRMLhKm5REFzv6hf88Hk9NjW1Ky2iAnH3RA=.23fbd8bc-7b2b-414a-95b6-84ff87282bd0@github.com> References: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> <7e2LH5nFRRMLhKm5REFzv6hf88Hk9NjW1Ky2iAnH3RA=.23fbd8bc-7b2b-414a-95b6-84ff87282bd0@github.com> Message-ID: On Thu, 16 Jan 2025 15:47:04 GMT, Andy Goryachev wrote: >> That is right, but the `pulse` call will call `layout`, which will call `layoutChildren` (when needed). I could also just call `layout` directly, but want to keep it the same way as the actual Application would behave. > > Relying on two pulses may cause flicker (I had a similar issue with the RichTextArea). > > The solution is to re-compute the layout in layoutChildren() when needed (i.e. when scroll bar status changes). Good to know, we should document your solution in more detail (and with the concrete fix -> code snippet from the RTA) together with the HSB bug as a new ticket probably? Then we may already have a potential solution with code, and of course a ticket that tracks the bug, if we do not have already (I think I saw a similar bug already, but not 100% sure). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1919332413 From angorya at openjdk.org Thu Jan 16 22:49:41 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 Jan 2025 22:49:41 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> <7e2LH5nFRRMLhKm5REFzv6hf88Hk9NjW1Ky2iAnH3RA=.23fbd8bc-7b2b-414a-95b6-84ff87282bd0@github.com> Message-ID: <1sk478f0y-HVwf4-BXBP9XQZrdvk4xhW9t5XK0rj7Q8=.8ba1c358-7cd2-4e94-8f0d-253e31227afd@github.com> On Thu, 16 Jan 2025 22:41:07 GMT, Marius Hanl wrote: >> Relying on two pulses may cause flicker (I had a similar issue with the RichTextArea). >> >> The solution is to re-compute the layout in layoutChildren() when needed (i.e. when scroll bar status changes). > > Good to know, we should document your solution in more detail (and with the concrete fix -> code snippet from the RTA) together with the HSB bug as a new ticket probably? Then we may already have a potential solution with code, and of course a ticket that tracks the bug, if we do not have already (I think I saw a similar bug already, but not 100% sure). VFlow LL1529-1555 // scroll bars boolean vsbVisible = useContentHeight ? false : (topCellIndex() > 0) ? true : (arrangementHeight + contentPaddingTop + contentPaddingBottom) > viewPortHeight; if (vsbVisible != vscroll.isVisible()) { vscroll.setVisible(vsbVisible); // do another layout pass with the scrollbar updated layoutCells(); return; } if (vsbVisible) { width -= vsbWidth; } boolean hsbVisible = (wrap || useContentWidth) ? false : (unwrappedWidth + contentPaddingLeft + contentPaddingRight) > viewPortWidth; if (hscroll.isVisible() != hsbVisible) { hscroll.setVisible(hsbVisible); // do another layout pass with the scrollbar updated layoutCells(); return; } https://github.com/andy-goryachev-oracle/jfx/blob/d07d408fa79e25a02b0d5e2f9aeb3990a7136077/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L1529 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1919336541 From duke at openjdk.org Fri Jan 17 07:56:53 2025 From: duke at openjdk.org (8Mi_Yile) Date: Fri, 17 Jan 2025 07:56:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v35] In-Reply-To: References: Message-ID: <4D3EvszK7VjHmVmBwYlouX72hdiVu60orDt4Ku7sx5Y=.ab680025-d1c7-4016-9122-2da44acdf6cc@github.com> On Thu, 16 Jan 2025 14:32:14 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Restore unintended change from merging master oh yes it's merged ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2597635481 From jvos at openjdk.org Fri Jan 17 08:37:53 2025 From: jvos at openjdk.org (Johan Vos) Date: Fri, 17 Jan 2025 08:37:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v35] In-Reply-To: <72QMAyQvyu3g3ToMjBz-WnPuVgPlPaYGX4YNx2bR2l0=.c3b6d00f-3d36-4859-b12f-28e20a609332@github.com> References: <72QMAyQvyu3g3ToMjBz-WnPuVgPlPaYGX4YNx2bR2l0=.c3b6d00f-3d36-4859-b12f-28e20a609332@github.com> Message-ID: On Thu, 16 Jan 2025 15:37:56 GMT, Glavo wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore unintended change from merging master > > This is awesome! > > Is there a plan to backport this PR to OpenJFX 17? This PR is very important for users in East Asia, so we hope it will be part of OpenJFX 24 and backported to OpenJFX 17/21. @Glavo I understand the importance, so I'm +1 on backporting this. However, we need to take 2 things into account: 1. there are merge conflicts between this PR and the head of jfx17u 2. jfx17u is typically used on older linux systems, so we need to make sure that the PR does not depend on anything that is only available in more recent linux systems ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2597700262 From mhanl at openjdk.org Fri Jan 17 08:56:43 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 17 Jan 2025 08:56:43 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: <1sk478f0y-HVwf4-BXBP9XQZrdvk4xhW9t5XK0rj7Q8=.8ba1c358-7cd2-4e94-8f0d-253e31227afd@github.com> References: <4HxmyKkU1i4j_WuJSymUzkjANEyAj6r1KOQf1U1JSsw=.8f2d7ea6-1fde-405f-8668-fdc951fc31a9@github.com> <7e2LH5nFRRMLhKm5REFzv6hf88Hk9NjW1Ky2iAnH3RA=.23fbd8bc-7b2b-414a-95b6-84ff87282bd0@github.com> <1sk478f0y-HVwf4-BXBP9XQZrdvk4xhW9t5XK0rj7Q8=.8ba1c358-7cd2-4e94-8f0d-253e31227afd@github.com> Message-ID: On Thu, 16 Jan 2025 22:46:39 GMT, Andy Goryachev wrote: >> Good to know, we should document your solution in more detail (and with the concrete fix -> code snippet from the RTA) together with the HSB bug as a new ticket probably? Then we may already have a potential solution with code, and of course a ticket that tracks the bug, if we do not have already (I think I saw a similar bug already, but not 100% sure). > > VFlow LL1529-1555 > > > // scroll bars > boolean vsbVisible = useContentHeight ? > false : > (topCellIndex() > 0) ? > true : > (arrangementHeight + contentPaddingTop + contentPaddingBottom) > viewPortHeight; > > if (vsbVisible != vscroll.isVisible()) { > vscroll.setVisible(vsbVisible); > // do another layout pass with the scrollbar updated > layoutCells(); > return; > } > if (vsbVisible) { > width -= vsbWidth; > } > > boolean hsbVisible = (wrap || useContentWidth) ? > false : > (unwrappedWidth + contentPaddingLeft + contentPaddingRight) > viewPortWidth; > > if (hscroll.isVisible() != hsbVisible) { > hscroll.setVisible(hsbVisible); > // do another layout pass with the scrollbar updated > layoutCells(); > return; > } > > > > https://github.com/andy-goryachev-oracle/jfx/blob/d07d408fa79e25a02b0d5e2f9aeb3990a7136077/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L1529 Thanks. That makes sense IMO. Can probably also be applied to the `VirtualFlow`. Just need to be careful that we never can run in a stack overflow ofc. :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1919766327 From duke at openjdk.org Fri Jan 17 09:04:48 2025 From: duke at openjdk.org (Dr. Stefan Pfeiffer) Date: Fri, 17 Jan 2025 09:04:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v37] In-Reply-To: References: Message-ID: <-jYtcQC9oRZF7sFUuLtyCsV-1GRklLkKZlzVFWDnB2g=.ad86c0b8-e934-4969-b8e2-fafa827ba47d@github.com> On Wed, 15 Jan 2025 00:55:24 GMT, Michael Strau? wrote: >> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. > > 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/extended-window > - fix resizable states for GTK windows > - add StageStyle.EXTENDED_UTILITY > - fix system menu for non-resizeable extended window > - Merge branch 'master' into feature/extended-window > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java > - StyleableBooleanProperty -> BooleanProperty > - Add HeaderBar.overlappingSystemInset property > - Merge branch 'master' into feature/extended-window > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKScene.java > # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java > - Merge branch 'master' into feature/extended-window > - macOS: double-click action + fullscreen toolbar > - ... and 36 more: https://git.openjdk.org/jfx/compare/90ea0f07...cbb32165 I hope the work to get this PR finalized gets continued. This would greatly benefit a project i am working on right now and which needs to resort to hacky "transparent stage and emulate all the OS window behaviour in JavaFX" which fails in so many edge cases. Thumbs up for the work! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2592889297 From angorya at openjdk.org Fri Jan 17 16:17:47 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 Jan 2025 16:17:47 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v6] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 16:04:17 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - 8185887: Test for the TreeView graphic disappearance problem (JDK-8346824) > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > - 8185887: Rename method to fit domain > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction The changes and testing LGTM. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1644#pullrequestreview-2559407290 From angorya at openjdk.org Fri Jan 17 23:48:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 Jan 2025 23:48:45 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v16] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Thu, 16 Jan 2025 19:34:06 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 >> >> >> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: >> >> >> /** >> * Returns the shape for the strike-through in local coordinates. >> * >> * @param start the beginning character index for the range >> * @param end the end character index (non-inclusive) for the range >> * @return an array of {@code PathElement} which can be used to create a {@code Shape} >> * @since 25 >> */ >> public final PathElement[] strikeThroughShape(int start, int end) >> >> >> >> >> ## WARNING >> >> 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) ). >> >> >> >> ## 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: > > 25 25 keep-alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2599381333 From pascal.gruen at gmail.com Sat Jan 18 15:12:35 2025 From: pascal.gruen at gmail.com (Pascal) Date: Sat, 18 Jan 2025 16:12:35 +0100 Subject: MacOS: Title bar flickering when animation is playing Message-ID: Hello all, I have noticed a weird flickering behaviour on MacOS when playing animations and having set an effect on the background (both needed to be true during my experimentation). It looks like JavaFX is drawing on the lower lines of the title bar that are managed by the OS and during animation playing, JavaFX "wins", overwriting the OS painting. Once the animation is finished, the OS painting takes over again, resulting in a flicker effect whenever an animation starts or stops. Unfortunately, I cannot take a screenshot or screen recording, as the flickering doesn't happen when screen recording is active. Somehow, the painting process is different then. I tested different resolutions and it looks to me that the flickering happens independently of resolution and HiDPI setting. It would be nice if someone could open a bug for this. Below is the code to reproduce the behaviour (hover over the button to see the flickering). public class FlickerDemo extends Application { @Override public void start(Stage primaryStage) { Button button = new Button("Button"); Transition transition = new Transition() { { setCycleDuration(Duration.millis(500)); } @Override protected void interpolate(double frac) { button.setOpacity(Math.min(1, frac + 0.5)); } }; button.setOnMouseEntered(_ -> { transition.setRate(1.0); transition.play(); }); button.setOnMouseExited(_ -> { transition.setRate(-1.0); transition.play(); }); StackPane root = new StackPane(button); root.setBackground(new Background(new BackgroundFill(Color.WHITE, null, null))); root.setEffect(new InnerShadow()); Scene scene = new Scene(root, 800, 600); primaryStage.setScene(scene); primaryStage.show(); } } Thanks a lot! Pascal From duke at openjdk.org Sun Jan 19 12:48:44 2025 From: duke at openjdk.org (henrykdz) Date: Sun, 19 Jan 2025 12:48:44 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: <8FrcBbK5c_p84xKlf1AJZZ9zDJWk-eUOrpr0sWCI5h8=.32357335-166b-41c9-a41a-dbeee98ac291@github.com> On Tue, 14 Jan 2025 21:23:59 GMT, Andy Goryachev wrote: > @henrykdz : could you please attach the video clip to https://bugs.openjdk.org/browse/JDK-8347464 ? I've deleted it from here, not knowing it would cause this, sorry. I guess I can't connect to the old URL again? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2600844816 From kcr at openjdk.org Tue Jan 21 15:02:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:02:46 GMT Subject: RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 Message-ID: <5B0nx8rySIYd2CkdYDDyrvYKm_Z9sSO1C2TqnfFyNmQ=.83ac5ed8-7e04-408c-b9b5-fcfc0526ad4a@github.com> Clean merge of January CPU content into `jfx:jfx24`. Reviewer: @johanvos ------------- Commit messages: - Merge branch 'jfx24-cpu-2501' into merge-jfx24-cpu-2501 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8335714: Enhance playing MP3s - ... and 1 more: https://git.openjdk.org/jfx/compare/069db877...fcd0b6ed The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/1681/files Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1681.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1681/head:pull/1681 PR: https://git.openjdk.org/jfx/pull/1681 From kcr at openjdk.org Tue Jan 21 15:02:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:02:50 GMT Subject: RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 Message-ID: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Clean merge of January CPU content into `jfx:master`. Reviewer: @johanvos ------------- Commit messages: - Merge branch 'jfx25-cpu-2501' into merge-jfx25-cpu-2501 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8335714: Enhance playing MP3s - ... and 1 more: https://git.openjdk.org/jfx/compare/d07d408f...f6262cd9 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/1680/files Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1680.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1680/head:pull/1680 PR: https://git.openjdk.org/jfx/pull/1680 From kcr at openjdk.org Tue Jan 21 15:05:29 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:05:29 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 [v2] In-Reply-To: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: <7WEOxCatIlc4hhWV2C67Fvl4TJXaRGuGotPK3zKe5GI=.8ba1b5a7-5cb2-4271-bd66-f2bfc986b662@github.com> > Release notes for JavaFX 23.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=47027 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=47026 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Add security content ------------- Changes: - all: https://git.openjdk.org/jfx23u/pull/35/files - new: https://git.openjdk.org/jfx23u/pull/35/files/61842b2c..fed176b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx23u&pr=35&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx23u&pr=35&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx23u/pull/35.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/35/head:pull/35 PR: https://git.openjdk.org/jfx23u/pull/35 From kcr at openjdk.org Tue Jan 21 15:05:30 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:05:30 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 In-Reply-To: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: On Mon, 13 Jan 2025 19:02:33 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 23.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=47027 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=47026 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. @johanvos I just pushed the security content for this release. Please review and also approve for inclusion into jfx23u. ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/35#issuecomment-2604975648 From kcr at openjdk.org Tue Jan 21 15:07:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:07:43 GMT Subject: [jfx23u] RFR: Merge 397d3c3548a584927c334bc214e216fff2317f5b In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 15:00:07 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into `jfx23u:master`. > > Reviewer: @johanvos @johanvos I'll add the 23.0.2 tags shortly after I integrate this PR. ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/36#issuecomment-2604983305 From kcr at openjdk.org Tue Jan 21 15:07:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:07:43 GMT Subject: [jfx23u] RFR: Merge 397d3c3548a584927c334bc214e216fff2317f5b Message-ID: Clean merge of January CPU content into `jfx23u:master`. Reviewer: @johanvos ------------- Commit messages: - Merge - Merge - Merge - Merge - Merge - Merge - 8335714: Enhance playing MP3s - 8335715: Improve Direct Show support - Merge - 8336631: Update JavaFX release version for Jan 2025 CPU The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx23u/pull/36/files Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jfx23u/pull/36.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/36/head:pull/36 PR: https://git.openjdk.org/jfx23u/pull/36 From jvos at openjdk.org Tue Jan 21 15:13:46 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:13:46 GMT Subject: [jfx23u] RFR: Merge 397d3c3548a584927c334bc214e216fff2317f5b In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 15:00:07 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into `jfx23u:master`. > > Reviewer: @johanvos Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/36#pullrequestreview-2564927855 From jvos at openjdk.org Tue Jan 21 15:13:43 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:13:43 GMT Subject: RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 In-Reply-To: <5B0nx8rySIYd2CkdYDDyrvYKm_Z9sSO1C2TqnfFyNmQ=.83ac5ed8-7e04-408c-b9b5-fcfc0526ad4a@github.com> References: <5B0nx8rySIYd2CkdYDDyrvYKm_Z9sSO1C2TqnfFyNmQ=.83ac5ed8-7e04-408c-b9b5-fcfc0526ad4a@github.com> Message-ID: On Tue, 21 Jan 2025 14:59:04 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into `jfx:jfx24`. > > Reviewer: @johanvos content looks ok ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1681#pullrequestreview-2564926374 From kcr at openjdk.org Tue Jan 21 15:19:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:19:51 GMT Subject: Integrated: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 In-Reply-To: <5B0nx8rySIYd2CkdYDDyrvYKm_Z9sSO1C2TqnfFyNmQ=.83ac5ed8-7e04-408c-b9b5-fcfc0526ad4a@github.com> References: <5B0nx8rySIYd2CkdYDDyrvYKm_Z9sSO1C2TqnfFyNmQ=.83ac5ed8-7e04-408c-b9b5-fcfc0526ad4a@github.com> Message-ID: On Tue, 21 Jan 2025 14:59:04 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into `jfx:jfx24`. > > Reviewer: @johanvos This pull request has now been integrated. Changeset: f2f5639c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f2f5639c243dada1a25f661dbf84d37d908e16e3 Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/1681 From kcr at openjdk.org Tue Jan 21 15:20:27 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:20:27 GMT Subject: [jfx23u] RFR: Merge 397d3c3548a584927c334bc214e216fff2317f5b [v2] In-Reply-To: References: Message-ID: > Clean merge of January CPU content into `jfx23u:master`. > > Reviewer: @johanvos Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jfx23u/pull/36/files - new: https://git.openjdk.org/jfx23u/pull/36/files/397d3c35..397d3c35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx23u&pr=36&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx23u&pr=36&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/36.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/36/head:pull/36 PR: https://git.openjdk.org/jfx23u/pull/36 From kcr at openjdk.org Tue Jan 21 15:20:27 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:20:27 GMT Subject: [jfx23u] Integrated: Merge 397d3c3548a584927c334bc214e216fff2317f5b In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 15:00:07 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into `jfx23u:master`. > > Reviewer: @johanvos This pull request has now been integrated. Changeset: aa2fcda7 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/aa2fcda70b18f6bc5ec05c38b77fa161cc51751b Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx23u/pull/36 From kcr at openjdk.org Tue Jan 21 15:35:48 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:35:48 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 [v2] In-Reply-To: <7WEOxCatIlc4hhWV2C67Fvl4TJXaRGuGotPK3zKe5GI=.8ba1b5a7-5cb2-4271-bd66-f2bfc986b662@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> <7WEOxCatIlc4hhWV2C67Fvl4TJXaRGuGotPK3zKe5GI=.8ba1b5a7-5cb2-4271-bd66-f2bfc986b662@github.com> Message-ID: On Tue, 21 Jan 2025 15:05:29 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 23.0.2. >> >> Notes to reviewers: >> >> I used the following filter to pick the issues: >> >> https://bugs.openjdk.org/issues/?filter=47027 >> >> The original filter, with the backport IDs, is here: >> >> https://bugs.openjdk.org/issues/?filter=47026 >> >> As usual, I excluded test bugs, cleanup bugs, etc. >> >> NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add security content @johanvos Thanks for the maintainer approval. Can you also review/approve the PR itself? ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/35#issuecomment-2605058213 From jvos at openjdk.org Tue Jan 21 15:36:51 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:36:51 GMT Subject: [jfx17u] Integrated: Merge 3093c30cdb37f862d7855dd766125f871717e3b3 Message-ID: 2025-jan cpu content for jfx17u Reviewer: @kevinrushforth ------------- Commit messages: - Merge branch 'master' into cpu-25-01 - Merge branch 'master' into cpu-25-01 - 8335715: Improve Direct Show support - [PATCH] 8335714: Enhance playing MP3s The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx17u/pull/222/files Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jfx17u/pull/222.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/222/head:pull/222 PR: https://git.openjdk.org/jfx17u/pull/222 From jvos at openjdk.org Tue Jan 21 15:36:52 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:36:52 GMT Subject: [jfx17u] Integrated: Merge 3093c30cdb37f862d7855dd766125f871717e3b3 In-Reply-To: References: Message-ID: <6Kp_0tNtS4_Ry9WjwTpIialxVWxx0ijWTn8uUcd-rME=.82f4a788-9ee3-4c6c-9e76-e111399017e5@github.com> On Tue, 21 Jan 2025 15:12:10 GMT, Johan Vos wrote: > 2025-jan cpu content for jfx17u > Reviewer: @kevinrushforth This pull request has now been integrated. Changeset: 53cc2693 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/53cc2693e8a7a779383001928955e65fbd33eca2 Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Merge Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx17u/pull/222 From kcr at openjdk.org Tue Jan 21 15:36:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:36:52 GMT Subject: [jfx17u] Integrated: Merge 3093c30cdb37f862d7855dd766125f871717e3b3 In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 15:12:10 GMT, Johan Vos wrote: > 2025-jan cpu content for jfx17u > Reviewer: @kevinrushforth The content looks good. You'll need to change the title of your merge request to one of the following: `Merge 8def0626d411b8cada4a11cd44da386251c0dd43` -- if you want the two merge commits in this branch to be merged (in addition to the Skara-generated merge commit) `Merge 3093c30cdb37f862d7855dd766125f871717e3b3` -- if you do not want the two merge commits in this branch to be merged (you will thus only see the Skara-generated merge commit). Btw, one of the two commits has commit message with an unwanted `[PATCH]` prefix, but it isn't worth worrying about. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx17u/pull/222#pullrequestreview-2564974058 From jvos at openjdk.org Tue Jan 21 15:45:48 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:45:48 GMT Subject: [jfx21u] Integrated: Merge 69f4bd3cf86f3dead821352850de205594a368e2 Message-ID: 2025-jan cpu content for jfx21u Reviewer: @kevinrushforth ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx21u/pull/86/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/86.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/86/head:pull/86 PR: https://git.openjdk.org/jfx21u/pull/86 From kcr at openjdk.org Tue Jan 21 15:45:48 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:45:48 GMT Subject: [jfx21u] Integrated: Merge 69f4bd3cf86f3dead821352850de205594a368e2 In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 15:15:11 GMT, Johan Vos wrote: > 2025-jan cpu content for jfx21u > Reviewer: @kevinrushforth The content looks good. You'll need to change the title of your merge request to one of the following: `Merge 69f4bd3cf86f3dead821352850de205594a368e2` -- if you want the two merge commits in this branch to be merged (in addition to the Skara-generated merge commit) `Merge 08cbe0a5ff47645e84a78d23e5c34eaa83bde66d` -- if you do not want the two merge commits in this branch to be merged (you will thus only see the Skara-generated merge commit). As with the jfx17u PR, one of the two commits has commit message with an unwanted `[PATCH]` prefix, but it isn't worth worrying about. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx21u/pull/86#pullrequestreview-2564989618 From jvos at openjdk.org Tue Jan 21 15:45:49 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:45:49 GMT Subject: [jfx21u] Integrated: Merge 69f4bd3cf86f3dead821352850de205594a368e2 In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 15:15:11 GMT, Johan Vos wrote: > 2025-jan cpu content for jfx21u > Reviewer: @kevinrushforth This pull request has now been integrated. Changeset: 5ad44274 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/5ad442749972f73caf4aa320106d9a25e866addc Stats: 87 lines in 3 files changed: 77 ins; 1 del; 9 mod Merge Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx21u/pull/86 From jvos at openjdk.org Tue Jan 21 15:46:48 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:46:48 GMT Subject: RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 In-Reply-To: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: On Tue, 21 Jan 2025 14:59:01 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into `jfx:master`. > > Reviewer: @johanvos Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1680#pullrequestreview-2565025178 From kcr at openjdk.org Tue Jan 21 15:53:34 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:53:34 GMT Subject: [jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2] In-Reply-To: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: > Clean merge of January CPU content into ~~jfx:master~~ `jfx:jfx24`. > > Reviewer: @johanvos Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'jfx25-cpu-2501' into merge-jfx25-cpu-2501 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8335714: Enhance playing MP3s Reviewed-by: arapte, kcr, mschoene, rhalade - ... and 1 more: https://git.openjdk.org/jfx/compare/ea4c7d2b...f6262cd9 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1680/files - new: https://git.openjdk.org/jfx/pull/1680/files/f6262cd9..f6262cd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1680&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1680&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1680.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1680/head:pull/1680 PR: https://git.openjdk.org/jfx/pull/1680 From jvos at openjdk.org Tue Jan 21 15:53:35 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 15:53:35 GMT Subject: [jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2] In-Reply-To: References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: <14XQ3o6WB2luL033IMW-KwDoRHHCf-tpCY-ZXcMwhaE=.a0b7e352-0947-4e6a-882f-a3e9918a8107@github.com> On Tue, 21 Jan 2025 15:50:52 GMT, Kevin Rushforth wrote: >> Clean merge of January CPU content into ~~jfx:master~~ `jfx:jfx24`. >> >> Reviewer: @johanvos > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'jfx25-cpu-2501' into merge-jfx25-cpu-2501 > - Merge > - Merge > - Merge > - Merge > - Merge > - Merge > - Merge > - Merge > - 8335714: Enhance playing MP3s > > Reviewed-by: arapte, kcr, mschoene, rhalade > - ... and 1 more: https://git.openjdk.org/jfx/compare/ea4c7d2b...f6262cd9 Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1680#pullrequestreview-2565040550 From kcr at openjdk.org Tue Jan 21 15:53:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 15:53:37 GMT Subject: [jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2] In-Reply-To: References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: On Tue, 21 Jan 2025 15:44:23 GMT, Johan Vos wrote: >> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'jfx25-cpu-2501' into merge-jfx25-cpu-2501 >> - Merge >> - Merge >> - Merge >> - Merge >> - Merge >> - Merge >> - Merge >> - Merge >> - 8335714: Enhance playing MP3s >> >> Reviewed-by: arapte, kcr, mschoene, rhalade >> - ... and 1 more: https://git.openjdk.org/jfx/compare/ea4c7d2b...f6262cd9 > > Marked as reviewed by jvos (Reviewer). @johanvos I messed up the target branch of #1681 -- that one should have been targeted to `jfx24` and this one to `master`. Fortunately, the source branches were identical, so I will change this one to `jfx24` (since I integrated the other to `master` already). Skara will require a re-review from you once I change the target branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1680#issuecomment-2605096640 From angorya at openjdk.org Tue Jan 21 15:59:43 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 21 Jan 2025 15:59:43 GMT Subject: [jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2] In-Reply-To: References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: On Tue, 21 Jan 2025 15:48:31 GMT, Kevin Rushforth wrote: > I messed up the target branch please also force push the master branch. (I guess this merge was the reason github greeted me with the label "11 commits behind" message this morning) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1680#issuecomment-2605119463 From jvos at openjdk.org Tue Jan 21 16:03:45 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 16:03:45 GMT Subject: [jfx23u] RFR: 8347616: Create release notes for JavaFX 23.0.2 [v2] In-Reply-To: <7WEOxCatIlc4hhWV2C67Fvl4TJXaRGuGotPK3zKe5GI=.8ba1b5a7-5cb2-4271-bd66-f2bfc986b662@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> <7WEOxCatIlc4hhWV2C67Fvl4TJXaRGuGotPK3zKe5GI=.8ba1b5a7-5cb2-4271-bd66-f2bfc986b662@github.com> Message-ID: On Tue, 21 Jan 2025 15:05:29 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 23.0.2. >> >> Notes to reviewers: >> >> I used the following filter to pick the issues: >> >> https://bugs.openjdk.org/issues/?filter=47027 >> >> The original filter, with the backport IDs, is here: >> >> https://bugs.openjdk.org/issues/?filter=47026 >> >> As usual, I excluded test bugs, cleanup bugs, etc. >> >> NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add security content Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/35#pullrequestreview-2565073279 From kcr at openjdk.org Tue Jan 21 16:14:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 16:14:43 GMT Subject: [jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2] In-Reply-To: References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: On Tue, 21 Jan 2025 15:57:12 GMT, Andy Goryachev wrote: > > I messed up the target branch > > please also force push the master branch. No. This PR has been intentionally retargeted to `jfx24` branch. It now has nothing to do with `master`. > (I guess this merge was the reason github greeted me with the label "11 commits behind" message this morning) The merge of #1681 into master was the reason. Intentionally so. To add a little more explanation: as happens every January and July, any CPU content must be merged into both to `master` and to the then-current stabilization branch (`jfx24` for this January 2025 CPU release). My only mistake is that I targeted both PRs to `master` when one of them should have been to `jfx24`. Since the source branches were 100% identical, the mistake was easiest to fix by retargeting this one to `jfx24`, which I did. I'll integrate this PR to jfx24 after everything else related to the CPU is finished. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1680#issuecomment-2605161568 From kcr at openjdk.org Tue Jan 21 16:21:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 16:21:53 GMT Subject: [jfx23u] Integrated: 8347616: Create release notes for JavaFX 23.0.2 In-Reply-To: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> References: <63u9PQE6qQkqavfOHzwdVbfoJI72CEm68PjtWwS3nmI=.69eabe02-ac14-4f7a-bb79-a54d149d9494@github.com> Message-ID: On Mon, 13 Jan 2025 19:02:33 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 23.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=47027 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=47026 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2025-01-21, I will add any security bugs and ask for a re-review. This pull request has now been integrated. Changeset: 14dbee52 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/14dbee52c3870a2fd289ec96ecd0b27ad147ea3e Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod 8347616: Create release notes for JavaFX 23.0.2 Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx23u/pull/35 From kcr at openjdk.org Tue Jan 21 17:20:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 17:20:51 GMT Subject: [jfx24] Integrated: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 In-Reply-To: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: On Tue, 21 Jan 2025 14:59:01 GMT, Kevin Rushforth wrote: > Clean merge of January CPU content into ~~jfx:master~~ `jfx:jfx24`. > > Reviewer: @johanvos This pull request has now been integrated. Changeset: 0759447b Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0759447bbcc4adf23ef920e962f0beced9961431 Stats: 90 lines in 6 files changed: 77 ins; 1 del; 12 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/1680 From jvos at openjdk.org Tue Jan 21 17:23:52 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 17:23:52 GMT Subject: [jfx17u] RFR: Merge 509b8695024b6d1e26bbb0360a41365bf19ac3e9 Message-ID: The patch for dshowwrapper for 17u requires one different line compared to the one for 21u. I accidentally pushed the wrong branch first. This PR fixes that. ------------- Commit messages: - fix windows compiling issue The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx17u/pull/223/files Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/223.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/223/head:pull/223 PR: https://git.openjdk.org/jfx17u/pull/223 From jvos at openjdk.org Tue Jan 21 17:32:21 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 17:32:21 GMT Subject: [jfx17u] RFR: Merge 509b8695024b6d1e26bbb0360a41365bf19ac3e9 [v2] In-Reply-To: References: Message-ID: > The patch for dshowwrapper for 17u requires one different line compared to the one for 21u. I accidentally pushed the wrong branch first. This PR fixes that. Johan Vos 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. ------------- Changes: - all: https://git.openjdk.org/jfx17u/pull/223/files - new: https://git.openjdk.org/jfx17u/pull/223/files/509b8695..509b8695 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx17u&pr=223&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx17u&pr=223&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/223.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/223/head:pull/223 PR: https://git.openjdk.org/jfx17u/pull/223 From kcr at openjdk.org Tue Jan 21 17:32:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 Jan 2025 17:32:21 GMT Subject: [jfx17u] RFR: Merge 509b8695024b6d1e26bbb0360a41365bf19ac3e9 [v2] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 17:28:53 GMT, Johan Vos wrote: >> The patch for dshowwrapper for 17u requires one different line compared to the one for 21u. I accidentally pushed the wrong branch first. This PR fixes that. > > Johan Vos 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. LGTM, including the PR title. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx17u/pull/223#pullrequestreview-2565289165 From jvos at openjdk.org Tue Jan 21 17:32:22 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jan 2025 17:32:22 GMT Subject: [jfx17u] Integrated: Merge 509b8695024b6d1e26bbb0360a41365bf19ac3e9 In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 17:19:28 GMT, Johan Vos wrote: > The patch for dshowwrapper for 17u requires one different line compared to the one for 21u. I accidentally pushed the wrong branch first. This PR fixes that. This pull request has now been integrated. Changeset: d95ee3b8 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/d95ee3b84acf4c726fc2426be225797eba0f3540 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Merge Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx17u/pull/223 From andy.goryachev at oracle.com Tue Jan 21 19:03:37 2025 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 21 Jan 2025 19:03:37 +0000 Subject: MacOS: Title bar flickering when animation is playing In-Reply-To: References: Message-ID: Dear Pascal: I cannot see the flicker (macOS 15.1.1 M1, using the laptop retina monitor with scale=2 or the external monitor at scale=1), running the latest JFX master branch. Actually, I don't see much change except for the button - the inner shadow of the window background looks unchanged. Could it be something that was fixed? Or due to x86 driver in your mac? Or may be external monitor connection? I can help with creating a JBS ticket once I can reproduce it. Cheers, -andy From: openjfx-dev on behalf of Pascal Date: Saturday, January 18, 2025 at 07:14 To: openjfx-dev at openjdk.org Subject: MacOS: Title bar flickering when animation is playing Hello all, I have noticed a weird flickering behaviour on MacOS when playing animations and having set an effect on the background (both needed to be true during my experimentation). It looks like JavaFX is drawing on the lower lines of the title bar that are managed by the OS and during animation playing, JavaFX "wins", overwriting the OS painting. Once the animation is finished, the OS painting takes over again, resulting in a flicker effect whenever an animation starts or stops. Unfortunately, I cannot take a screenshot or screen recording, as the flickering doesn't happen when screen recording is active. Somehow, the painting process is different then. I tested different resolutions and it looks to me that the flickering happens independently of resolution and HiDPI setting. It would be nice if someone could open a bug for this. Below is the code to reproduce the behaviour (hover over the button to see the flickering). public class FlickerDemo extends Application { @Override public void start(Stage primaryStage) { Button button = new Button("Button"); Transition transition = new Transition() { { setCycleDuration(Duration.millis(500)); } @Override protected void interpolate(double frac) { button.setOpacity(Math.min(1, frac + 0.5)); } }; button.setOnMouseEntered(_ -> { transition.setRate(1.0); transition.play(); }); button.setOnMouseExited(_ -> { transition.setRate(-1.0); transition.play(); }); StackPane root = new StackPane(button); root.setBackground(new Background(new BackgroundFill(Color.WHITE, null, null))); root.setEffect(new InnerShadow()); Scene scene = new Scene(root, 800, 600); primaryStage.setScene(scene); primaryStage.show(); } } Thanks a lot! Pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 21 19:08:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 21 Jan 2025 19:08:50 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: <8FrcBbK5c_p84xKlf1AJZZ9zDJWk-eUOrpr0sWCI5h8=.32357335-166b-41c9-a41a-dbeee98ac291@github.com> References: <8FrcBbK5c_p84xKlf1AJZZ9zDJWk-eUOrpr0sWCI5h8=.32357335-166b-41c9-a41a-dbeee98ac291@github.com> Message-ID: On Sun, 19 Jan 2025 12:43:51 GMT, henrykdz wrote: > The only thing I can do is reupload it somewhere. If the video is small enough it can be added to the ticket. Alternatively, you could attach two frame grabs - one with and one without the problem. Otherwise no one can see what you were talking about once the link is gone. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2605528101 From kcr at openjdk.org Wed Jan 22 14:04:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 14:04:13 GMT Subject: [jfx24] Integrated: 8348287: Version number mistakenly updated to 25 in jfx24 branch Message-ID: Revert the change from 24 to 25 in the jfx24 branch, which was the result of a bad merge for yesterday's CPU fixes. Reviewer: @arapte ------------- Commit messages: - 8348287: Version number mistakenly updated to 25 in jfx24 branch Changes: https://git.openjdk.org/jfx/pull/1682/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1682&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348287 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1682.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1682/head:pull/1682 PR: https://git.openjdk.org/jfx/pull/1682 From arapte at openjdk.org Wed Jan 22 14:04:13 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 22 Jan 2025 14:04:13 GMT Subject: [jfx24] Integrated: 8348287: Version number mistakenly updated to 25 in jfx24 branch In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 13:53:53 GMT, Kevin Rushforth wrote: > Revert the change from 24 to 25 in the jfx24 branch, which was the result of a bad merge for yesterday's CPU fixes. > > Reviewer: @arapte LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1682#pullrequestreview-2567287300 From kcr at openjdk.org Wed Jan 22 14:04:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 14:04:13 GMT Subject: [jfx24] Integrated: 8348287: Version number mistakenly updated to 25 in jfx24 branch In-Reply-To: References: Message-ID: <-nMNSE4CQktm61cACYX_9mU2Ayu_Kbv23gXO47dnVl8=.31d13591-8816-4550-8e1e-bce4a17a53d3@github.com> On Wed, 22 Jan 2025 13:53:53 GMT, Kevin Rushforth wrote: > Revert the change from 24 to 25 in the jfx24 branch, which was the result of a bad merge for yesterday's CPU fixes. > > Reviewer: @arapte Since this is a P1 stopper for any builds, I will forgo the 24 hour waiting period. As soon as approved, I will integrate into the jfx24 branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1682#issuecomment-2607313918 From kcr at openjdk.org Wed Jan 22 14:04:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 14:04:13 GMT Subject: [jfx24] Integrated: 8348287: Version number mistakenly updated to 25 in jfx24 branch In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 13:53:53 GMT, Kevin Rushforth wrote: > Revert the change from 24 to 25 in the jfx24 branch, which was the result of a bad merge for yesterday's CPU fixes. > > Reviewer: @arapte This pull request has now been integrated. Changeset: 87c3488a Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/87c3488a15b361ca343b6a324b9e4a995ce0baec Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8348287: Version number mistakenly updated to 25 in jfx24 branch Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1682 From kcr at openjdk.org Wed Jan 22 17:05:47 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 17:05:47 GMT Subject: [jfx24u] RFR: 8347600: Change JavaFX release version to 24.0.1 in jfx24u Message-ID: Updates for the beginning of the 24.0.1 release. ------------- Commit messages: - 8347600: Change JavaFX release version to 24.0.1 in jfx24u Changes: https://git.openjdk.org/jfx24u/pull/1/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=1&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347600 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx24u/pull/1.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/1/head:pull/1 PR: https://git.openjdk.org/jfx24u/pull/1 From jvos at openjdk.org Wed Jan 22 17:05:48 2025 From: jvos at openjdk.org (Johan Vos) Date: Wed, 22 Jan 2025 17:05:48 GMT Subject: [jfx24u] RFR: 8347600: Change JavaFX release version to 24.0.1 in jfx24u In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:25:59 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 24.0.1 release. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx24u/pull/1#pullrequestreview-2567788711 From kcr at openjdk.org Wed Jan 22 17:05:49 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 17:05:49 GMT Subject: [jfx24u] RFR: 8347600: Change JavaFX release version to 24.0.1 in jfx24u In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:25:59 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 24.0.1 release. Reviewers: @johanvos or @arapte ------------- PR Comment: https://git.openjdk.org/jfx24u/pull/1#issuecomment-2607705039 From kcr at openjdk.org Wed Jan 22 17:30:05 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 17:30:05 GMT Subject: [jfx24u] Integrated: 8347600: Change JavaFX release version to 24.0.1 in jfx24u In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:25:59 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 24.0.1 release. This pull request has now been integrated. Changeset: 54729669 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx24u/commit/5472966986efe17d0565b6c5c18dc51cfa783fcb Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8347600: Change JavaFX release version to 24.0.1 in jfx24u Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx24u/pull/1 From kcr at openjdk.org Wed Jan 22 19:01:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 19:01:58 GMT Subject: [jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2] In-Reply-To: References: <5RtSXYj2gF4Q6f55FSixG_XR-7WTPA8XGbAKOxpbl_M=.2b2166b4-9513-473e-9a91-c2ad1e26a269@github.com> Message-ID: <_3fzjXi7Rin3oQWWKFrP_Nw4eyOnIcIdLSikyBRkq2Y=.e027253d-26e7-496c-ae2f-36049ed8765b@github.com> On Tue, 21 Jan 2025 15:53:34 GMT, Kevin Rushforth wrote: >> Clean merge of January CPU content into ~~jfx:master~~ `jfx:jfx24`. >> >> Reviewer: @johanvos > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'jfx25-cpu-2501' into merge-jfx25-cpu-2501 > - Merge > - Merge > - Merge > - Merge > - Merge > - Merge > - Merge > - Merge > - 8335714: Enhance playing MP3s > > Reviewed-by: arapte, kcr, mschoene, rhalade > - ... and 1 more: https://git.openjdk.org/jfx/compare/6a70eab6...f6262cd9 To follow-up on this, for future reference, I made a mistake in this PR, which I didn't catch until earlier this morning while forking the (soon-to-be-open) `jfx24u` repo from the `jfx:jfx24 branch` > To add a little more explanation: as happens every January and July, any CPU content must be merged into both to master and to the then-current stabilization branch (jfx24 for this January 2025 CPU release). My only mistake is that I targeted both PRs to master when one of them should have been to jfx24. So far, this is accurate, and would have been completely fixable without further problems, but... > Since the source branches were 100% identical Stop right there, Kevin! While it is true that I created the PR branches from a pair of 100% identical internal branches (the exact same HEAD hash, which is reflected in the PR title), I merged in the intended target branches before creating the PR, meaning I merged `master` into `merge-jfx25-cpu-2501`; consequently, `merge-jfx25-cpu-2501`, which is the source branch for this PR, has one additional commit -- the version bump from jfx24 to jfx25 -- relative the `merge-jfx24-cpu-2501` branch, which was originally intended for `jfx24`. NOTE: The result of the extra commit (the unintended version bump) is visible in the diffs, which I didn't look at carefully enough before deciding to take the following shortcut: > the mistake was easiest to fix by retargeting this one to jfx24, which I did. I'll integrate this PR to jfx24 after everything else related to the CPU is finished. No. The mistake would have been easiest to fix by _not_ taking this shortcut. Better would have been to close this PR and create a new one from the right branch. I remedied the problem earlier today with PR #1682 to revert the version bump in the `jfx24` branch. All good now, but I'll repeat my own advice from my [JavaFX 24 RDP1 message](https://mail.openjdk.org/pipermail/openjfx-dev/2025-January/051749.html), at least for my own benefit: "...be extra careful when reviewing PRs targeted to jfx24 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed." ------------- PR Comment: https://git.openjdk.org/jfx/pull/1680#issuecomment-2608034310 From kcr at openjdk.org Wed Jan 22 19:12:00 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 19:12:00 GMT Subject: [jfx24u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Message-ID: This is a copy of the jfx23u README and CONTRIBUTING docs, changing 23 to 24. ------------- Commit messages: - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Changes: https://git.openjdk.org/jfx24u/pull/2/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=2&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304008 Stats: 269 lines in 2 files changed: 1 ins; 256 del; 12 mod Patch: https://git.openjdk.org/jfx24u/pull/2.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/2/head:pull/2 PR: https://git.openjdk.org/jfx24u/pull/2 From jvos at openjdk.org Wed Jan 22 19:12:00 2025 From: jvos at openjdk.org (Johan Vos) Date: Wed, 22 Jan 2025 19:12:00 GMT Subject: [jfx24u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:34:58 GMT, Kevin Rushforth wrote: > This is a copy of the jfx23u README and CONTRIBUTING docs, changing 23 to 24. I confirm this is a PR mentioning OpenJFX 24, targeting jfx24u so all good :) ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx24u/pull/2#pullrequestreview-2567945501 From kcr at openjdk.org Wed Jan 22 19:12:01 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 19:12:01 GMT Subject: [jfx24u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:34:58 GMT, Kevin Rushforth wrote: > This is a copy of the jfx23u README and CONTRIBUTING docs, changing 23 to 24. Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx24u/pull/2#issuecomment-2607864655 From kevin.rushforth at oracle.com Wed Jan 22 19:21:47 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 Jan 2025 11:21:47 -0800 Subject: jfx23u open for JavaFX 23.0.1 backports Message-ID: <0b38ea5a-f72b-493c-b24a-d696080888cc@oracle.com> All, The jfx24u repo [1] is now open for JavaFX 24.0.1 backports (the April 2025 CPU release), with approval from one of the project leads. The general criteria is that we want to backport fixes for regressions introduced in JavaFX 24, third-party library updates, and a limited number of other important bug fixes. In most cases we'd like to see the fix "bake" in the mainline for a while before being backported to jfx24u. NOTE: Only those fixes that will NOT be backported to the jfx24 [2] stabilization branch are candidates for backporting to jfx24u. A backport intended for the JavaFX 24 code line will go into either the jfx24 branch or the jfx24u repo, not both. We use a similar procedure for making the request and noting the approval as is used by the JDK updates releases -- by using JBS labels to request a backport and indicate approval or rejection. Here is the procedure: 1. If you are not sure whether something is a good candidate for backporting, ask on the mailing list or in the PR you want to backport. 2. Create the backport PR for jfx24u, either manually or using the "/backport" command. You can use Skara's "/approval" command to request approval. Skara will not mark a jfx24u PR as ready until approved. Let Johan or me know if you have any questions. Thanks. -- Kevin [1] https://github.com/openjdk/jfx24u [2] https://github.com/openjdk/jfx/tree/jfx24 From kevin.rushforth at oracle.com Wed Jan 22 19:23:33 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 Jan 2025 11:23:33 -0800 Subject: jfx24u open for JavaFX 24.0.1 backports Message-ID: <7a87704c-af45-4850-ab0a-50dcadf4beb7@oracle.com> [resend with correct subject] All, The jfx24u repo [1] is now open for JavaFX 24.0.1 backports (the April 2025 CPU release), with approval from one of the project leads. The general criteria is that we want to backport fixes for regressions introduced in JavaFX 24, third-party library updates, and a limited number of other important bug fixes. In most cases we'd like to see the fix "bake" in the mainline for a while before being backported to jfx24u. NOTE: Only those fixes that will NOT be backported to the jfx24 [2] stabilization branch are candidates for backporting to jfx24u. A backport intended for the JavaFX 24 code line will go into either the jfx24 branch or the jfx24u repo, not both. We use a similar procedure for making the request and noting the approval as is used by the JDK updates releases -- by using JBS labels to request a backport and indicate approval or rejection. Here is the procedure: 1. If you are not sure whether something is a good candidate for backporting, ask on the mailing list or in the PR you want to backport. 2. Create the backport PR for jfx24u, either manually or using the "/backport" command. You can use Skara's "/approval" command to request approval. Skara will not mark a jfx24u PR as ready until approved. Let Johan or me know if you have any questions. Thanks. -- Kevin [1] https://github.com/openjdk/jfx24u [2] https://github.com/openjdk/jfx/tree/jfx24 From kcr at openjdk.org Wed Jan 22 19:25:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 Jan 2025 19:25:53 GMT Subject: [jfx24u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: <1kKKlchADzVewdyRItXmJYgdphxnpw9G6G2BAjCooEE=.58dbe675-48b8-4658-bf52-fd8422459f0a@github.com> On Wed, 22 Jan 2025 17:34:58 GMT, Kevin Rushforth wrote: > This is a copy of the jfx23u README and CONTRIBUTING docs, changing 23 to 24. This pull request has now been integrated. Changeset: 1f628a9d Author: Kevin Rushforth URL: https://git.openjdk.org/jfx24u/commit/1f628a9d3f87f673e97486961d6b9cad3e267ce2 Stats: 269 lines in 2 files changed: 1 ins; 256 del; 12 mod 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Reviewed-by: jvos Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6 ------------- PR: https://git.openjdk.org/jfx24u/pull/2 From jvos at openjdk.org Wed Jan 22 20:03:52 2025 From: jvos at openjdk.org (Johan Vos) Date: Wed, 22 Jan 2025 20:03:52 GMT Subject: [jfx17u] RFR: 8348318: Change JavaFX release version to 17.0.15 in jfx17u Message-ID: <_dwHiFb2TEBBj0MRASxQjkXypelA2vu0ek1G36rsxZs=.d57f21f2-003b-499b-94dc-8cbfc9dca4cd@github.com> Bump version to 17.0.15 ------------- Commit messages: - Bump version to 17.0.15 Changes: https://git.openjdk.org/jfx17u/pull/224/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348318 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/224.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/224/head:pull/224 PR: https://git.openjdk.org/jfx17u/pull/224 From jvos at openjdk.org Wed Jan 22 20:06:05 2025 From: jvos at openjdk.org (Johan Vos) Date: Wed, 22 Jan 2025 20:06:05 GMT Subject: [jfx21u] RFR: 8348319: Change JavaFX release version to 21.0.7 in jfx21u Message-ID: Bump version to 21.0.7 ------------- Commit messages: - Bump version to 21.0.7 Changes: https://git.openjdk.org/jfx21u/pull/87/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=87&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348319 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/87.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/87/head:pull/87 PR: https://git.openjdk.org/jfx21u/pull/87 From ambarish.rapte at oracle.com Thu Jan 23 05:13:10 2025 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 23 Jan 2025 05:13:10 +0000 Subject: JavaFX Metal: First EA build available for Testing Message-ID: Hello openjfx-dev, The first Early Access(EA) build of JavaFX with the macOS Metal rendering pipeline is now available at: https://jdk.java.net/javafxmetal Please test this bundle and share your feedback by: - emailing jfx-dev at openjdk.java.net or - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com This is the first EA release and some work is still in progress, so you may encounter issues. Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Metal EA page[https://jdk.java.net/javafxmetal]. Before reporting a new bug, please review the existing issues to avoid duplicates. Important Notes: 1. This is a macOS-specific feature, so only two macOS-specific bundles are provided. 2. The default rendering pipeline is set to Metal. Using other pipelines (e.g., -Dprism.order=es2 or -Dprism.order=sw) will result in error. 3. It is recommended to use JDK 24 or later. 4. Optionally, enable Metal validations while testing, e.g.: export METAL_DEVICE_WRAPPER_TYPE=1, export METAL_SHADER_VALIDATION=1 5. Must disable all the active Metal validations when testing for performance, e.g.: export METAL_DEVICE_WRAPPER_TYPE=0, export METAL_SHADER_VALIDATION=0 6. Issue behavior may vary across different hardware. So, please provide detailed information, such as the output of "java -Dprism.verbose=true", when reporting or discussing issues. 7. Refer: Run HelloWorld using JavaFX SDK[https://openjfx.io/openjfx-docs/#install-javafx] We look forward to your feedback. Regards, Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Fri Jan 24 15:17:52 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 24 Jan 2025 15:17:52 GMT Subject: RFR: 8170720: VetoableListDecorator: Indexes to remove are not aggregated In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 01:56:10 GMT, Michael Strau? wrote: > `VetoableListDecorator` does not correctly report removed indices. Instead of reporting ranges like `[0, 3)`, it always reports a pairwise list of single removals like `[0, 1, 1, 2, 2, 3)`. > > The reason is a off-by-one error, and the fix is simple. LGTM, fix is trivial and tests all work as intended ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1675#pullrequestreview-2572930281 From pascal.gruen at gmail.com Fri Jan 24 18:59:26 2025 From: pascal.gruen at gmail.com (Pascal) Date: Fri, 24 Jan 2025 19:59:26 +0100 Subject: MacOS: Title bar flickering when animation is playing In-Reply-To: References: Message-ID: Hello Andy, I tried to reproduce the issue with the latest JavaFX build, but accidentally downloaded an older one, openjfx-24-ea+19. With this, the flickering is still happening. However, today I noticed my mistake and downloaded the latest, openjfx-24-ea+25, and with that version I cannot reproduce the error anymore, the flickering is gone. So it looks like it's already fixed, everything is fine. Thanks for your help! Best regards, Pascal Am Di., 21. Jan. 2025 um 20:03 Uhr schrieb Andy Goryachev : > > Dear Pascal: > > > > I cannot see the flicker (macOS 15.1.1 M1, using the laptop retina monitor with scale=2 or the external monitor at scale=1), running the latest JFX master branch. > > Actually, I don't see much change except for the button - the inner shadow of the window background looks unchanged. > > > > Could it be something that was fixed? Or due to x86 driver in your mac? Or may be external monitor connection? > > > > I can help with creating a JBS ticket once I can reproduce it. > > > > Cheers, > > -andy > > > > > > From: openjfx-dev on behalf of Pascal > Date: Saturday, January 18, 2025 at 07:14 > To: openjfx-dev at openjdk.org > Subject: MacOS: Title bar flickering when animation is playing > > Hello all, > > I have noticed a weird flickering behaviour on MacOS when playing > animations and having set an effect on the background (both needed to > be true during my experimentation). > > It looks like JavaFX is drawing on the lower lines of the title bar > that are managed by the OS and during animation playing, JavaFX > "wins", overwriting the OS painting. Once the animation is finished, > the OS painting takes over again, resulting in a flicker effect > whenever an animation starts or stops. > > Unfortunately, I cannot take a screenshot or screen recording, as the > flickering doesn't happen when screen recording is active. Somehow, > the painting process is different then. > > I tested different resolutions and it looks to me that the flickering > happens independently of resolution and HiDPI setting. > > It would be nice if someone could open a bug for this. > > Below is the code to reproduce the behaviour (hover over the button to > see the flickering). > > > public class FlickerDemo extends Application { > @Override > public void start(Stage primaryStage) { > Button button = new Button("Button"); > > Transition transition = new Transition() { > { > setCycleDuration(Duration.millis(500)); > } > > @Override > protected void interpolate(double frac) { > button.setOpacity(Math.min(1, frac + 0.5)); > } > }; > > button.setOnMouseEntered(_ -> { > transition.setRate(1.0); > transition.play(); > }); > > button.setOnMouseExited(_ -> { > transition.setRate(-1.0); > transition.play(); > }); > > StackPane root = new StackPane(button); > root.setBackground(new Background(new > BackgroundFill(Color.WHITE, null, null))); > root.setEffect(new InnerShadow()); > > Scene scene = new Scene(root, 800, 600); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > > > Thanks a lot! > > Pascal From andy.goryachev at oracle.com Fri Jan 24 19:01:38 2025 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 24 Jan 2025 19:01:38 +0000 Subject: [External] : Re: MacOS: Title bar flickering when animation is playing In-Reply-To: References: Message-ID: That's great, thank you Pascal! -andy From: Pascal Date: Friday, January 24, 2025 at 11:00 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: MacOS: Title bar flickering when animation is playing Hello Andy, I tried to reproduce the issue with the latest JavaFX build, but accidentally downloaded an older one, openjfx-24-ea+19. With this, the flickering is still happening. However, today I noticed my mistake and downloaded the latest, openjfx-24-ea+25, and with that version I cannot reproduce the error anymore, the flickering is gone. So it looks like it's already fixed, everything is fine. Thanks for your help! Best regards, Pascal Am Di., 21. Jan. 2025 um 20:03 Uhr schrieb Andy Goryachev : > > Dear Pascal: > > > > I cannot see the flicker (macOS 15.1.1 M1, using the laptop retina monitor with scale=2 or the external monitor at scale=1), running the latest JFX master branch. > > Actually, I don't see much change except for the button - the inner shadow of the window background looks unchanged. > > > > Could it be something that was fixed? Or due to x86 driver in your mac? Or may be external monitor connection? > > > > I can help with creating a JBS ticket once I can reproduce it. > > > > Cheers, > > -andy > > > > > > From: openjfx-dev on behalf of Pascal > Date: Saturday, January 18, 2025 at 07:14 > To: openjfx-dev at openjdk.org > Subject: MacOS: Title bar flickering when animation is playing > > Hello all, > > I have noticed a weird flickering behaviour on MacOS when playing > animations and having set an effect on the background (both needed to > be true during my experimentation). > > It looks like JavaFX is drawing on the lower lines of the title bar > that are managed by the OS and during animation playing, JavaFX > "wins", overwriting the OS painting. Once the animation is finished, > the OS painting takes over again, resulting in a flicker effect > whenever an animation starts or stops. > > Unfortunately, I cannot take a screenshot or screen recording, as the > flickering doesn't happen when screen recording is active. Somehow, > the painting process is different then. > > I tested different resolutions and it looks to me that the flickering > happens independently of resolution and HiDPI setting. > > It would be nice if someone could open a bug for this. > > Below is the code to reproduce the behaviour (hover over the button to > see the flickering). > > > public class FlickerDemo extends Application { > @Override > public void start(Stage primaryStage) { > Button button = new Button("Button"); > > Transition transition = new Transition() { > { > setCycleDuration(Duration.millis(500)); > } > > @Override > protected void interpolate(double frac) { > button.setOpacity(Math.min(1, frac + 0.5)); > } > }; > > button.setOnMouseEntered(_ -> { > transition.setRate(1.0); > transition.play(); > }); > > button.setOnMouseExited(_ -> { > transition.setRate(-1.0); > transition.play(); > }); > > StackPane root = new StackPane(button); > root.setBackground(new Background(new > BackgroundFill(Color.WHITE, null, null))); > root.setEffect(new InnerShadow()); > > Scene scene = new Scene(root, 800, 600); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > > > Thanks a lot! > > Pascal -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jan 24 19:44:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 Jan 2025 19:44:59 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: On Wed, 15 Jan 2025 15:41:23 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - ... and 29 more: https://git.openjdk.org/jfx/compare/a95151e1...f365f3dd I reread the discussion on this, and have a few thoughts. 1. [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753) is a pretty noticeable bug when dealing with non-integer render scales (especially 125%) in the default snap-to-pixel case. 2. I agree with @hjohn and @mstr2 that the existing `TableView` resize-on-mouse-drag algorithm is flawed. The way that successive delta values are accumulated, which leads to different results for slow vs fast mouse moves, highlights this problem (SMALL_DELTA is a partial workaround, but it's only needed in the first place because the algorithm is flawed). I haven't looked closely enough to see whether it would be possible to fix this without public API changes, but I can imagine that it might not be. Either way it would be a large effort to fix the algorithm with a lot of testing needed. Long term, it might be the right thing to do, but it's out of scope for this bug fix. Given that rewriting the algorithm is out of scope here, the question becomes whether this bug is worth the effort to fix (I think it is) and whether this particular change is sound, given the existing algorithm. The main thing I would want to ensure is that we don't regress in the case of an integer screen scale. My testing of it so far looks good, but I want to review the code changes to satisfy myself that the risk of regression is small. I'm still a bit skeptical of the need for the (not-public) snapInnerSpace method, but I'll take a closer look. We'll need to testing with snap-to-pixel disabled as well (I spotted what I think is a bug in that case, but that was just something I happened to notice -- I still have not done a thorough review of the code). If we are going to get this in, doing so early in the jfx25 release would be good so it gets more testing time. modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 104: > 102: if (c.isSnapToPixel()) { > 103: double min = c.snapSizeX(col.getMinWidth()); > 104: double max = RegionHelper.snapInnerSpaceX(c, col.getMaxWidth()); I'm still not convinced that min and max should be snapped differently (floor vs ceiling). modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 118: > 116: } > 117: // can set width directly because all constraints have been checked > 118: col.setWidth(width); The constraints have been checked only in the default snap-to-pixel case. This will bypass clamping if snap-to-pixel is false. I recommend moving the `setWidth` call into the if statement, and calling `doSetWidth` in an `else` block. ------------- PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-2573442011 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1929153111 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1929153564 From kcr at openjdk.org Fri Jan 24 21:40:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 Jan 2025 21:40:53 GMT Subject: RFR: 8170720: VetoableListDecorator: Indexes to remove are not aggregated In-Reply-To: References: Message-ID: <7MGlN9NNyAzL9AoqQu3irYWDyoDasJIayZomaqBUzVE=.d5a342fa-fb82-4f70-afdd-c2837cd49601@github.com> On Tue, 14 Jan 2025 01:56:10 GMT, Michael Strau? wrote: > `VetoableListDecorator` does not correctly report removed indices. Instead of reporting ranges like `[0, 3)`, it always reports a pairwise list of single removals like `[0, 1, 1, 2, 2, 3)`. > > The reason is a off-by-one error, and the fix is simple. Looks good. I confirm that the added tests fail without and pass with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1675#pullrequestreview-2573623814 From mstrauss at openjdk.org Fri Jan 24 23:01:53 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 24 Jan 2025 23:01:53 GMT Subject: Integrated: 8170720: VetoableListDecorator: Indexes to remove are not aggregated In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 01:56:10 GMT, Michael Strau? wrote: > `VetoableListDecorator` does not correctly report removed indices. Instead of reporting ranges like `[0, 3)`, it always reports a pairwise list of single removals like `[0, 1, 1, 2, 2, 3)`. > > The reason is a off-by-one error, and the fix is simple. This pull request has now been integrated. Changeset: a1765747 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/a176574744978156edf8f83d8c0b2f994b36cd1c Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod 8170720: VetoableListDecorator: Indexes to remove are not aggregated Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1675 From angorya at openjdk.org Sat Jan 25 00:10:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Sat, 25 Jan 2025 00:10:59 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: On Fri, 24 Jan 2025 19:38:24 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 39 commits: >> >> - Merge branch 'master' into 8299753.resize >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - in case of hitting min max >> - Merge branch 'master' into 8299753.resize >> - Merge branch 'master' into 8299753.resize >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - Merge branch 'master' into 8299753.resize >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - Merge remote-tracking branch 'origin/master' into 8299753.resize >> - ... and 29 more: https://git.openjdk.org/jfx/compare/a95151e1...f365f3dd > > modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 104: > >> 102: if (c.isSnapToPixel()) { >> 103: double min = c.snapSizeX(col.getMinWidth()); >> 104: double max = RegionHelper.snapInnerSpaceX(c, col.getMaxWidth()); > > I'm still not convinced that min and max should be snapped differently (floor vs ceiling). we will violate the max constraint if we snap to a larger value. so for the max constraint, we should `snapInnerSpace()` which calls the private (?) `Region.snapPortionX()`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1929390436 From kcr at openjdk.org Sat Jan 25 00:39:55 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 25 Jan 2025 00:39:55 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: On Sat, 25 Jan 2025 00:07:55 GMT, Andy Goryachev wrote: > we will violate the max constraint if we snap to a larger value. Well, it's inherently an over-constrained problem. Conceptually, though, this does not violate the constraint. When snap-to-pixel is enabled, all values, including min and max values are snapped to a pixel that can be almost 1 pixel larger or smaller than it's given value. Within that tolerance, we are honoring the min and max values. It isn't required that we always ceil the min value and floor the max value (not to mention that doing that is what causes the odd min > max). So I don't buy this argument. Is there some other reason to do it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1929410320 From nlisker at openjdk.org Sat Jan 25 07:04:41 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:04:41 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: References: Message-ID: > A small refactoring of the Dimension classes. > > * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. > * `com.sun.javafx.geom.Dimension2D` became a record. > * `javafx.geometry.Dimension2D`: fields became `final`. > > I'm not sure we need the implementation class at all considering we are free to use the public one. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1653/files - new: https://git.openjdk.org/jfx/pull/1653/files/e1ce604a..2a72347f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1653&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1653&range=00-01 Stats: 98 lines in 8 files changed: 53 ins; 37 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1653.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1653/head:pull/1653 PR: https://git.openjdk.org/jfx/pull/1653 From nlisker at openjdk.org Sat Jan 25 07:04:41 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:04:41 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 14:34:08 GMT, Alexander Zvegintsev wrote: >> Thanks @azvegint. If the `int`-based dimensions are coupled with `com.sun.javafx.geom.Rectangle` (and from the code, that's the only place they are used at), would you object to making `Dimension` an inner class of `Rectangle`? The `float`-based dimensions are used in other 2D shapes, so are more general purpose. > >> would you object to making Dimension an inner class of Rectangle? > > I am fine with it. @azvegint Please confirm that the change is acceptable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2613817033 From nlisker at openjdk.org Sat Jan 25 07:04:42 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:04:42 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 19:45:47 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2D.java line 31: >> >>> 29: * A 2D dimension object that contains a width and a height. >>> 30: */ >>> 31: public record Dimension2D(float width, float height) {} >> >> I wish this class was named differently to signify it's based on float... > > Most of the classes in this package are based on floats. As this is an internal class, adding a comment seems sufficient. I changed the names of the non-public classes to indicate the types they use, it's just easier to see at a glance. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1929490331 From nlisker at openjdk.org Sat Jan 25 07:08:53 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:08:53 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 19:13:20 GMT, Andy Goryachev wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 372: > >> 370: affectedScreenBounds >> 371: .stream() >> 372: .map(rectangle -> new Dimension2D(rectangle.width, rectangle.height)) > > the largest positive integer that can be stored in a float exactly is ~16M. we are fine here. Yes, I don't think we need all of them, but I was asked to keep the types. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1929490995 From nlisker at openjdk.org Sat Jan 25 07:22:33 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:22:33 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: > A batch of typo and grammar fixes that were found by the spellchecker. > > Integration can wait until RDP 1/2. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1642/files - new: https://git.openjdk.org/jfx/pull/1642/files/403bcfae..60d4ba92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1642&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1642&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1642.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1642/head:pull/1642 PR: https://git.openjdk.org/jfx/pull/1642 From nlisker at openjdk.org Sat Jan 25 07:28:32 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:28:32 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: > A batch of typo and grammar fixes that were found by the spellchecker. > > Integration can wait until RDP 1/2. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Revert "Addressed review comment" This reverts commit 60d4ba92b997be9937f0984761b278b21de816e7. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1642/files - new: https://git.openjdk.org/jfx/pull/1642/files/60d4ba92..6a715137 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1642&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1642&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1642.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1642/head:pull/1642 PR: https://git.openjdk.org/jfx/pull/1642 From nlisker at openjdk.org Sat Jan 25 07:28:32 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:28:32 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 13:09:35 GMT, Michael Strau? wrote: > cssref.html L2038: ` apples when the mnemonic affordance (typically an underscore)` Didn't notice that this was fixed in a bigger patch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2613823400 From nlisker at openjdk.org Sat Jan 25 07:28:32 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 Jan 2025 07:28:32 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 07:22:33 GMT, Nir Lisker wrote: >> A batch of typo and grammar fixes that were found by the spellchecker. >> >> Integration can wait until RDP 1/2. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment I think that this week is a good time to integrate this. The copyright year script should be run after this too. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2613823803 From kcr at openjdk.org Sat Jan 25 13:47:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 25 Jan 2025 13:47:50 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 07:24:49 GMT, Nir Lisker wrote: > I think that this week is a good time to integrate this. The copyright year script should be run after this too. That sounds good. @arapte Can you file a JBS task to update the copyright years (some time during RDP2)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2613970678 From jpereda at openjdk.org Sun Jan 26 12:06:54 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 26 Jan 2025 12:06:54 GMT Subject: [jfx21u] RFR: 8348319: Change JavaFX release version to 21.0.7 in jfx21u In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 20:01:43 GMT, Johan Vos wrote: > Bump version to 21.0.7 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/87#pullrequestreview-2574225665 From jpereda at openjdk.org Sun Jan 26 12:07:53 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 26 Jan 2025 12:07:53 GMT Subject: [jfx17u] RFR: 8348318: Change JavaFX release version to 17.0.15 in jfx17u In-Reply-To: <_dwHiFb2TEBBj0MRASxQjkXypelA2vu0ek1G36rsxZs=.d57f21f2-003b-499b-94dc-8cbfc9dca4cd@github.com> References: <_dwHiFb2TEBBj0MRASxQjkXypelA2vu0ek1G36rsxZs=.d57f21f2-003b-499b-94dc-8cbfc9dca4cd@github.com> Message-ID: On Wed, 22 Jan 2025 19:58:09 GMT, Johan Vos wrote: > Bump version to 17.0.15 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/224#pullrequestreview-2574226702 From mstrauss at openjdk.org Mon Jan 27 06:43:35 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 06:43:35 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v38] In-Reply-To: References: Message-ID: <1FPsQwIKOlPHyo4bO0QjQhj_hlVJSX5g6gW2SgkBFa4=.aed476e9-0cb9-433c-aa17-962db1868c52@github.com> > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. 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: - added custom header buttons - Merge branch 'master' into feature/extended-window - Refactoring, added HeaderBar.leadingSystemPadding/trailingSystemPadding - Merge branch 'master' into feature/extended-window - fix resizable states for GTK windows - add StageStyle.EXTENDED_UTILITY - fix system menu for non-resizeable extended window - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java - StyleableBooleanProperty -> BooleanProperty - Add HeaderBar.overlappingSystemInset property - ... and 39 more: https://git.openjdk.org/jfx/compare/a1765747...49a81d32 ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=37 Stats: 5975 lines in 67 files changed: 4864 ins; 426 del; 685 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 Mon Jan 27 06:49:13 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 06:49:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v39] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix line endings ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/49a81d32..356a78ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=38 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=37-38 Stats: 531 lines in 1 file changed: 0 ins; 0 del; 531 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 Mon Jan 27 06:57:36 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 06:57:36 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v40] In-Reply-To: References: Message-ID: <2M57N_3xHa53qywd5tbjfXVXV5vB5fZe6BGuFAeXIVI=.05f97f35-0f9f-40b7-8613-e8fee925047c@github.com> > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: update javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/356a78ef..fcec7c8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=39 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=38-39 Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 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 angorya at openjdk.org Mon Jan 27 15:44:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 15:44:59 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: On Sat, 25 Jan 2025 00:37:28 GMT, Kevin Rushforth wrote: >> we will violate the max constraint if we snap to a larger value. >> >> so for the max constraint, we should `snapInnerSpace()` which calls the private (?) `Region.snapPortionX()`. > >> we will violate the max constraint if we snap to a larger value. > > Well, it's inherently an over-constrained problem. Conceptually, though, this does not violate the constraint. When snap-to-pixel is enabled, all values, including min and max values are snapped to a pixel that can be almost 1 pixel larger or smaller than it's given value. Within that tolerance, we are honoring the min and max values. > > It isn't required that we always ceil the min value and floor the max value (not to mention that doing that is what causes the odd min > max). > > So I don't buy this argument. Is there some other reason to do it? no other reason. are you suggesting to simply `round()`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1930740267 From angorya at openjdk.org Mon Jan 27 15:55:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 15:55:59 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: On Wed, 15 Jan 2025 15:41:23 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - ... and 29 more: https://git.openjdk.org/jfx/compare/a95151e1...f365f3dd this PR currently does not build ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2616134991 From angorya at openjdk.org Mon Jan 27 16:38:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 16:38:57 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 07:04:41 GMT, Nir Lisker wrote: >> A small refactoring of the Dimension classes. >> >> * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. >> * `com.sun.javafx.geom.Dimension2D` became a record. >> * `javafx.geometry.Dimension2D`: fields became `final`. >> >> I'm not sure we need the implementation class at all considering we are free to use the public one. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2Df.java line 34: > 32: * @see javafx.geometry.Dimension2D Dimension2D - doubles > 33: */ > 34: public record Dimension2Df(float width, float height) {} is this class really needed? Looks like it's only referenced from `Arc2D::setArc()` and `RectanglularShape::setFrame()`, as far as I can tell these two methods are never called. Should all three be removed? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1930831658 From nlisker at openjdk.org Mon Jan 27 16:59:05 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 27 Jan 2025 16:59:05 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: References: Message-ID: <7Y-oiaXpQCh80fGSLSaqaLSetNhz5JNVAavGOQt59LE=.02d3fc78-0012-440e-a90a-946abcc970ac@github.com> On Mon, 27 Jan 2025 16:36:28 GMT, Andy Goryachev wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2Df.java line 34: > >> 32: * @see javafx.geometry.Dimension2D Dimension2D - doubles >> 33: */ >> 34: public record Dimension2Df(float width, float height) {} > > is this class really needed? > > Looks like it's only referenced from `Arc2D::setArc()` and `RectanglularShape::setFrame()`, as far as I can tell these two methods are never called. > > Should all three be removed? I'm not familiar with these methods, but I did wonder why we need extra implementations in the initial comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1930861843 From angorya at openjdk.org Mon Jan 27 17:31:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 17:31:59 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: <7Y-oiaXpQCh80fGSLSaqaLSetNhz5JNVAavGOQt59LE=.02d3fc78-0012-440e-a90a-946abcc970ac@github.com> References: <7Y-oiaXpQCh80fGSLSaqaLSetNhz5JNVAavGOQt59LE=.02d3fc78-0012-440e-a90a-946abcc970ac@github.com> Message-ID: On Mon, 27 Jan 2025 16:56:21 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2Df.java line 34: >> >>> 32: * @see javafx.geometry.Dimension2D Dimension2D - doubles >>> 33: */ >>> 34: public record Dimension2Df(float width, float height) {} >> >> is this class really needed? >> >> Looks like it's only referenced from `Arc2D::setArc()` and `RectanglularShape::setFrame()`, as far as I can tell these two methods are never called. >> >> Should all three be removed? > > I'm not familiar with these methods, but I did wonder why we need extra implementations in the initial comment. looks like dead code left over from the original implementation. I removed the class along with the two methods and jfx builds (**you need to merge the latest master though**) and runs (i.e. shows arcs and rectangles) just fine. Eclipse IDE also has no issues. I think we can remove these. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1930914516 From nlisker at openjdk.org Mon Jan 27 17:40:54 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 27 Jan 2025 17:40:54 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes [v2] In-Reply-To: References: <7Y-oiaXpQCh80fGSLSaqaLSetNhz5JNVAavGOQt59LE=.02d3fc78-0012-440e-a90a-946abcc970ac@github.com> Message-ID: <1VDUfoya-5BbzxwY-Z0bFAq3_L5YIO4kHskPLFKVynA=.fcc7a6a4-6d4c-4775-b20d-11928d129cb1@github.com> On Mon, 27 Jan 2025 17:28:14 GMT, Andy Goryachev wrote: >> I'm not familiar with these methods, but I did wonder why we need extra implementations in the initial comment. > > looks like dead code left over from the original implementation. > > I removed the class along with the two methods and jfx builds (**you need to merge the latest master though**) and runs (i.e. shows arcs and rectangles) just fine. Eclipse IDE also has no issues. I think we can remove these. I don't mind removing them in this PR if others agree. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1930941813 From angorya at openjdk.org Mon Jan 27 17:54:27 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 17:54:27 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout Message-ID: Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts). The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel). The default font size has changed from 10 to 12 to make it closer to win/linux. This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests. Existing tests have been adjusted/reworked mainly due to default font size change. ------------- Commit messages: - cleanup - better test - cleanup - more magic - magic numbers - more - add exports - stub fonts - glyph run - truncated - ... and 7 more: https://git.openjdk.org/jfx/compare/f2f5639c...a4a3ebb3 Changes: https://git.openjdk.org/jfx/pull/1667/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342565 Stats: 1168 lines in 35 files changed: 692 ins; 270 del; 206 mod Patch: https://git.openjdk.org/jfx/pull/1667.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667 PR: https://git.openjdk.org/jfx/pull/1667 From mstrauss at openjdk.org Mon Jan 27 18:34:30 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 18:34:30 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2] In-Reply-To: References: Message-ID: > Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. > > However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - update tests - update tests - check list content in tests - Merge branch 'master' into fixes/vetoable-list-decorator-sublist - allow sublists to be used for bulk operations - failing tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1679/files - new: https://git.openjdk.org/jfx/pull/1679/files/5ba5a110..81917761 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1679&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1679&range=00-01 Stats: 13067 lines in 126 files changed: 4301 ins; 7476 del; 1290 mod Patch: https://git.openjdk.org/jfx/pull/1679.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1679/head:pull/1679 PR: https://git.openjdk.org/jfx/pull/1679 From mstrauss at openjdk.org Mon Jan 27 18:38:53 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 18:38:53 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 18:26:37 GMT, Andy Goryachev wrote: > One possible alternative is to create the defensive copy each time, this will save one extra pointer every time an iterator or a sublist gets created (these objects might be long lived). The code in this PR creates a copy in many (most?) cases anyway, and in my opinion, the memory is more precious resource that CPU cycles (i.e. using extra memory costs many more CPU cycles in garbage collection etc.), so please consider that. I don't quite understand what you mean. Can you elaborate? In particular, what does "save one extra pointer" mean? > modules/javafx.base/src/test/java/test/javafx/collections/VetoableObservableListTest.java line 212: > >> 210: list.addAll(list.subList(0, 2)); >> 211: assertSingleCall(new String[] {"foo", "bar"}, new int[] {4, 4}); >> 212: } > > suggestion: also check that the list contains the newly added elements? > (here and in added tests that involve subList?) I've added checks for the list content in all modified tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1679#issuecomment-2616596847 PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1931014326 From mstrauss at openjdk.org Mon Jan 27 18:49:52 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 18:49:52 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 14:34:08 GMT, Alexander Zvegintsev wrote: >> Thanks @azvegint. If the `int`-based dimensions are coupled with `com.sun.javafx.geom.Rectangle` (and from the code, that's the only place they are used at), would you object to making `Dimension` an inner class of `Rectangle`? The `float`-based dimensions are used in other 2D shapes, so are more general purpose. > >> would you object to making Dimension an inner class of Rectangle? > > I am fine with it. > Thanks @azvegint. If the `int`-based dimensions are coupled with `com.sun.javafx.geom.Rectangle` (and from the code, that's the only place they are used at), would you object to making `Dimension` an inner class of `Rectangle`? The `float`-based dimensions are used in other 2D shapes, so are more general purpose. In my opinion, inner classes are justified when the implementations are coupled, or when one thing only makes sense in the context of another thing. That doesn't seem to be the case here: `Dimension` is neither used in `Rectangle`, nor are their implementations coupled. What this suggests to me is that either `Dimension` should remain its own top-level class, or if it is not useful there, be moved to where it _is_ used instead. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2616623029 From angorya at openjdk.org Mon Jan 27 18:49:56 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 18:49:56 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 18:34:30 GMT, Michael Strau? wrote: >> Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. >> >> However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - update tests > - update tests > - check list content in tests > - Merge branch 'master' into fixes/vetoable-list-decorator-sublist > - allow sublists to be used for bulk operations > - failing tests > Can you elaborate? > what does "save one extra pointer" mean? What I mean is simply get rid of the extra pointer like `VetoableListIteratorDecorator.parent` and the related logic, and simply create a copy of List/Collection each time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1679#issuecomment-2616624138 From mstrauss at openjdk.org Mon Jan 27 18:57:50 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 18:57:50 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 18:47:41 GMT, Andy Goryachev wrote: > > Can you elaborate? > > what does "save one extra pointer" mean? > > What I mean is simply get rid of the extra pointer like `VetoableListIteratorDecorator.parent` and the related logic, and simply create a copy of List/Collection each time. Okay, I see. We can't do that, because a sublist is specified to be a live view onto the source list. After all, `list.subList(0, 3).clear()` is valid code, and the result is that three elements are removed from the source list. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1679#issuecomment-2616640977 From angorya at openjdk.org Mon Jan 27 19:05:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 19:05:54 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 18:34:30 GMT, Michael Strau? wrote: >> Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation. >> >> However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - update tests > - update tests > - check list content in tests > - Merge branch 'master' into fixes/vetoable-list-decorator-sublist > - allow sublists to be used for bulk operations > - failing tests lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1679#pullrequestreview-2576318426 From angorya at openjdk.org Mon Jan 27 19:05:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 19:05:55 GMT Subject: RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2] In-Reply-To: References: Message-ID: <-wYWJG0T0J2KwJSC9RigEUi7EQNK7-GLdjrSGqcoB28=.9430d529-c895-4f0f-a8f8-af816b7b8045@github.com> On Mon, 27 Jan 2025 18:55:11 GMT, Michael Strau? wrote: > We can't do that, because a sublist is specified to be a live view onto the source list. good point, thanks for pointing this out. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1679#issuecomment-2616657340 From jvos at openjdk.org Mon Jan 27 19:50:55 2025 From: jvos at openjdk.org (Johan Vos) Date: Mon, 27 Jan 2025 19:50:55 GMT Subject: [jfx17u] Integrated: 8348318: Change JavaFX release version to 17.0.15 in jfx17u In-Reply-To: <_dwHiFb2TEBBj0MRASxQjkXypelA2vu0ek1G36rsxZs=.d57f21f2-003b-499b-94dc-8cbfc9dca4cd@github.com> References: <_dwHiFb2TEBBj0MRASxQjkXypelA2vu0ek1G36rsxZs=.d57f21f2-003b-499b-94dc-8cbfc9dca4cd@github.com> Message-ID: <-xjNlkT1q4PoxGGaiG7gn9W4Sd1NsMZa1xT2vv8r4Iw=.b138a431-dfb0-422c-91d3-cc181be7955c@github.com> On Wed, 22 Jan 2025 19:58:09 GMT, Johan Vos wrote: > Bump version to 17.0.15 This pull request has now been integrated. Changeset: 9c234e4c Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/9c234e4c31932b1f3ddb84122ba892db22e0bb92 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8348318: Change JavaFX release version to 17.0.15 in jfx17u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx17u/pull/224 From angorya at openjdk.org Mon Jan 27 20:22:30 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 20:22:30 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v7] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: - review comments - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - in case of hitting min max - Merge branch 'master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - ... and 31 more: https://git.openjdk.org/jfx/compare/a1765747...5464d7ee ------------- Changes: https://git.openjdk.org/jfx/pull/1156/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=06 Stats: 1176 lines in 8 files changed: 155 ins; 929 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From angorya at openjdk.org Mon Jan 27 20:22:30 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 20:22:30 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: On Wed, 15 Jan 2025 15:41:23 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - ... and 29 more: https://git.openjdk.org/jfx/compare/a95151e1...f365f3dd changed to `snapSizeX()` and `doSetWidth` in `else`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2616804369 From jvos at openjdk.org Mon Jan 27 20:33:54 2025 From: jvos at openjdk.org (Johan Vos) Date: Mon, 27 Jan 2025 20:33:54 GMT Subject: [jfx21u] Integrated: 8348319: Change JavaFX release version to 21.0.7 in jfx21u In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 20:01:43 GMT, Johan Vos wrote: > Bump version to 21.0.7 This pull request has now been integrated. Changeset: 10bafe7d Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/10bafe7dd8b7bf5fea05c1dcb2760694537ccd47 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8348319: Change JavaFX release version to 21.0.7 in jfx21u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx21u/pull/87 From kcr at openjdk.org Mon Jan 27 21:19:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 27 Jan 2025 21:19:52 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 22:23:11 GMT, Andy Goryachev wrote: > Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts). The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel). The default font size has changed from 10 to 12 to make it closer to win/linux. > > This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests. > > Existing tests have been adjusted/reworked mainly due to default font size change. > This pull request has been inactive for more than 4 weeks ... This seems like a Skara bug to me. This PR was just taken out of Draft and has several recent commits pushed to it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2616910459 From angorya at openjdk.org Mon Jan 27 21:19:52 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 27 Jan 2025 21:19:52 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout In-Reply-To: References: Message-ID: <5bf2zBoipjKmfOjVo9wXmtug09SqkHJsLzFMHP3K-N8=.730fb919-45db-4f1b-b5a2-ef1753abc745@github.com> On Mon, 27 Jan 2025 21:15:44 GMT, Kevin Rushforth wrote: > This pull request has been inactive for more than 4 weeks I doubt that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2616913729 From kcr at openjdk.org Mon Jan 27 22:25:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 27 Jan 2025 22:25:52 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout In-Reply-To: References: Message-ID: <0wCgAjJ5Ah8X7IdcWomvYWnTPEUVCDKN1WMWxlw7-Sw=.78b7da2e-9aa6-4bab-a489-eaa1a9e24e21@github.com> On Fri, 20 Dec 2024 22:23:11 GMT, Andy Goryachev wrote: > Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts). The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel). The default font size has changed from 10 to 12 to make it closer to win/linux. > > This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests. > > Existing tests have been adjusted/reworked mainly due to default font size change. Since this touches product code (in a minor way), I'd like two reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2617022602 From mstrauss at openjdk.org Mon Jan 27 22:57:37 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 22:57:37 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v41] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: hide default window buttons on macOS ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/fcec7c8a..2ab12947 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=40 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=39-40 Stats: 16 lines in 3 files changed: 9 ins; 0 del; 7 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 Mon Jan 27 23:26:58 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 23:26:58 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v41] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:57:37 GMT, Michael Strau? wrote: >> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > hide default window buttons on macOS Some people have suggested that they not only need to customize the title bar, but also the window buttons. This is now possible with the latest version of this feature. The API is now designed with an on-ramp to customization: 1. Choosing the `StageStyle.EXTENDED` or `StageStyle.EXTENDED_UTILITY` gets you the custom title bar area with platform-default window buttons. 2. Setting `Stage.initDefaultHeaderButtons(false)` opts out of the platform-default window buttons, which then need to be provided by the application. A custom window button is just a regular JavaFX button that can be placed anywhere in the scene graph. It needs to be marked with `HeaderBarBase.setHeaderButtonType(Node, HeaderButtonType)` to enable integrations with the platform window manager, where `HeaderButtonType` is `MINIMIZE`, `MAXIMIZE`, or `CLOSE`. Applications are still required to provide their own click handlers to programmatically trigger the actions associated with window buttons, i.e. call appropriate stage methods like `Stage.setIconified(boolean)`, `Stage.setMaximized(boolean)` or `Stage.close()`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2617118769 From mstrauss at openjdk.org Mon Jan 27 23:41:57 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 27 Jan 2025 23:41:57 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v41] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:57:37 GMT, Michael Strau? wrote: >> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > hide default window buttons on macOS Another change is the option to use multiple header bars, which now cooperate gracefully. This enables application developers to create advanced layouts, for example having two header bars in a `SplitPane`, where each `HeaderBar` has a different background. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2617139790 From angorya at openjdk.org Tue Jan 28 00:02:27 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 00:02:27 GMT Subject: RFR: 8348736: RichTextArea Follow-up 2 Message-ID: Fixes minor issues uncovered while writing API tests #1677: - StyledTextModel::clamp L559 is incorrect at the end of paragraph - CodeArea.getText() adds extra newline at the end This change should be back-ported to jfx24. ------------- Commit messages: - newlines - check - cleanup - clamp - get text Changes: https://git.openjdk.org/jfx/pull/1684/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1684&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348736 Stats: 214 lines in 7 files changed: 151 ins; 51 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1684.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1684/head:pull/1684 PR: https://git.openjdk.org/jfx/pull/1684 From kcr at openjdk.org Tue Jan 28 00:39:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 00:39:50 GMT Subject: RFR: 8348736: RichTextArea Follow-up 2 In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:10:18 GMT, Andy Goryachev wrote: > Fixes minor issues uncovered while writing API tests #1677: > > - StyledTextModel::clamp L559 is incorrect at the end of paragraph > - CodeArea.getText() adds extra newline at the end > > This change should be back-ported to jfx24. I'll review this. We need one other review, too. I'd rather see a more specific bug title if you can come up with something meaningful. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1684#issuecomment-2617265681 From duke at openjdk.org Tue Jan 28 02:50:54 2025 From: duke at openjdk.org (duke) Date: Tue, 28 Jan 2025 02:50:54 GMT Subject: Withdrawn: 8345348: CSS Media Queries In-Reply-To: References: Message-ID: <4m3VwTjqou6suhFBsKTrpafm-Zn1SiVroMhU71Yv6VA=.cb9f279d-4242-46b5-9bc4-bf841869ada5@github.com> On Mon, 2 Dec 2024 16:19:46 GMT, Michael Strau? wrote: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1655 From mstrauss at openjdk.org Tue Jan 28 05:17:41 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jan 2025 05:17:41 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v42] In-Reply-To: References: Message-ID: <0vsDsOGokNqgpU5Fd5be4MqLrnbU9NvE05rJOLoSlxM=.0dcd576b-ea0c-4f55-8535-15446ca4d66b@github.com> > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - add samples in MonkeyTester - typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/2ab12947..e874d21a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=41 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=40-41 Stats: 202 lines in 3 files changed: 200 ins; 0 del; 2 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 Jan 28 05:21:41 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jan 2025 05:21:41 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v43] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: small MonkeyTester refactor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/e874d21a..3efd7827 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=42 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=41-42 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 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 Jan 28 12:40:29 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 12:40:29 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 Message-ID: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). ------------- Commit messages: - 8348744: Application window not always activated on macOS 15 Changes: https://git.openjdk.org/jfx/pull/1685/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1685&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348744 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1685.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1685/head:pull/1685 PR: https://git.openjdk.org/jfx/pull/1685 From kcr at openjdk.org Tue Jan 28 12:40:29 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 12:40:29 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 12:35:13 GMT, Kevin Rushforth wrote: > The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. > > The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. > > Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. > > I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). Reviewers: @andy-goryachev-oracle @jperedadnr ------------- PR Comment: https://git.openjdk.org/jfx/pull/1685#issuecomment-2618885751 From crschnick at xpipe.io Tue Jan 28 14:37:57 2025 From: crschnick at xpipe.io (Christopher Schnick) Date: Tue, 28 Jan 2025 15:37:57 +0100 Subject: JavaFX Metal: First EA build available for Testing In-Reply-To: References: Message-ID: <473a4a52-e1b5-4f67-8587-d707500d002f@xpipe.io> I tested this build with our application on macOS 15.2 ARM and it worked perfectly fine. There were a few small color differences looking at it, but I see in the tracker that is already a known issue. Our application doesn't use any advanced rendering features where performance is critical, so I can't say anything about the performance difference. For the normal basic user interface, it felt the same as before. Best Christopher Schnick On 23/01/2025 06:13, Ambarish Rapte wrote: > > Hello openjfx-dev, > > The first Early Access(EA) build of JavaFX with the macOS Metal > rendering pipeline is now available > at:https://jdk.java.net/javafxmetal > > Please test this bundle and share your feedback by: > > - emailingjfx-dev at openjdk.java.net or > > - reporting issues via JBS[https://bugs.openjdk.org/ > ] or athttps://bugreport.java.com > > > This is the first EA release and some work is still in progress, so > you may encounter issues. > > Known issues and pending tasks are captured on JBS and can be accessed > using the filter provided on the Metal EA > page[https://jdk.java.net/javafxmetal ]. > > Before reporting a new bug, please review the existing issues to avoid > duplicates. > > Important Notes: > > 1. This is a macOS-specific feature, so only two macOS-specific > bundles are provided. > > 2. The default rendering pipeline is set to Metal. Using other > pipelines (e.g., -Dprism.order=es2 or -Dprism.order=sw) will result in > error. > > 3. It is recommended to use JDK 24 or later. > > 4. Optionally, enable Metal validations while testing, e.g.: export > METAL_DEVICE_WRAPPER_TYPE=1, export METAL_SHADER_VALIDATION=1 > > 5. Must disable all the active Metal validations when testing for > performance, e.g.: export METAL_DEVICE_WRAPPER_TYPE=0, export > METAL_SHADER_VALIDATION=0 > > 6. Issue behavior may vary across different hardware. So, please > provide detailed information, such as the output of "java > -Dprism.verbose=true", when reporting or discussing issues. > > 7. Refer: Run HelloWorld using JavaFX > SDK[https://openjfx.io/openjfx-docs/#install-javafx > ] > > We look forward to your feedback. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 28 15:59:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 15:59:58 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 12:35:13 GMT, Kevin Rushforth wrote: > The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. > > The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. > > Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. > > I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). works as expected (test app stage gets focused even when the terminal window running the test script loses focus) on macOS 15.1.1 M1, running the following script: #! /bin/bash set -x sleep 5 gradle --continue --info -PBUILD_TOOLS_DOWNLOAD_SCRIPT=../build-tools.gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests CSSRoundingTest modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 286: > 284: LOG("-> need to active application"); > 285: dispatch_async(dispatch_get_main_queue(), ^{ > 286: [NSApp activateIgnoringOtherApps:YES]; should we add a comment about possible removal of this API in newer platforms? (I would suggest also include the JBS reference so the context can be obtained by the person who will be fixing this code in the future). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1685#pullrequestreview-2578656328 PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932396827 From kcr at openjdk.org Tue Jan 28 16:14:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 16:14:52 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 15:35:07 GMT, Andy Goryachev wrote: >> The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. >> >> The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. >> >> Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. >> >> I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). > > modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 286: > >> 284: LOG("-> need to active application"); >> 285: dispatch_async(dispatch_get_main_queue(), ^{ >> 286: [NSApp activateIgnoringOtherApps:YES]; > > should we add a comment about possible removal of this API in newer platforms? > (I would suggest also include the JBS reference so the context can be obtained by the person who will be fixing this code in the future). I don't want to do either of these in this PR. My comment in the PR Description about possible API removal is independent of this bug and something I just happened to notice -- plus it's speculative on my part. I will file a follow-on place-holder bug for this, but there isn't anything actionable at this point. Also, I don't like the practice of putting bug IDs in for fixed bugs except in unusual cases (this isn't one of them). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932460818 From kcr at openjdk.org Tue Jan 28 16:28:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 16:28:53 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 16:12:14 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 286: >> >>> 284: LOG("-> need to active application"); >>> 285: dispatch_async(dispatch_get_main_queue(), ^{ >>> 286: [NSApp activateIgnoringOtherApps:YES]; >> >> should we add a comment about possible removal of this API in newer platforms? >> (I would suggest also include the JBS reference so the context can be obtained by the person who will be fixing this code in the future). > > I don't want to do either of these in this PR. My comment in the PR Description about possible API removal is independent of this bug and something I just happened to notice -- plus it's speculative on my part. I will file a follow-on place-holder bug for this, but there isn't anything actionable at this point. Also, I don't like the practice of putting bug IDs in for fixed bugs except in unusual cases (this isn't one of them). I filed [JDK-8348878](https://bugs.openjdk.org/browse/JDK-8348878) to track our use of the deprecated `[NSApp activateIgnoringOtherApps]` method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932485436 From angorya at openjdk.org Tue Jan 28 16:34:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 16:34:00 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 16:26:20 GMT, Kevin Rushforth wrote: >> I don't want to do either of these in this PR. My comment in the PR Description about possible API removal is independent of this bug and something I just happened to notice -- plus it's speculative on my part. I will file a follow-on place-holder bug for this, but there isn't anything actionable at this point. Also, I don't like the practice of putting bug IDs in for fixed bugs except in unusual cases (this isn't one of them). > > I filed [JDK-8348878](https://bugs.openjdk.org/browse/JDK-8348878) to track our use of the deprecated `[NSApp activateIgnoringOtherApps]` method. Yes, one can typically rely on git history to make connection to the original PR/JBS. The problem is that a merge might make this information not (easily) accessible. And yes, the comments are subject to the usual decay, when they lose the relevance (or stop being applicable), but at least one can easily find the original issue and related discussion. Just my two yen. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932498231 From angorya at openjdk.org Tue Jan 28 16:36:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 16:36:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v41] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 23:39:26 GMT, Michael Strau? wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> hide default window buttons on macOS > > Another change is the option to use multiple header bars, which now cooperate gracefully. This enables application developers to create advanced layouts, for example having two header bars in a `SplitPane`, where each `HeaderBar` has a different background. @mstr2 there is still active development going on - should this PR be sent back to Draft? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2619503726 From angorya at openjdk.org Tue Jan 28 16:42:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 16:42:00 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v43] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 05:21:41 GMT, Michael Strau? wrote: >> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small MonkeyTester refactor Minor comment about the Monkey Tester (it's more of a limitation due to our test sprint process). There is a more recent repo https://github.com/andy-goryachev-oracle/MonkeyTest which has a dedicated Stage page which allows for limited configuration, have you tried it?. I see that your code does a bit more, so I'll incorporate your changes into the standalone repo regardless. The jfx MT will get a refresh once our test sprint starts (March?) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2619517941 From jpereda at openjdk.org Tue Jan 28 17:26:53 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 28 Jan 2025 17:26:53 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 12:35:13 GMT, Kevin Rushforth wrote: > The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. > > The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. > > Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. > > I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). Marked as reviewed by jpereda (Reviewer). modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 286: > 284: LOG("-> need to active application"); > 285: dispatch_async(dispatch_get_main_queue(), ^{ > 286: [NSApp activateIgnoringOtherApps:YES]; I see that the CanvasTest mentioned in the JBS issue passes now with this fix, and fails with `[NSApp activate];` I'm not sure why `[NSApp activateIgnoringOtherApps:YES];` works but `[NSApp activate];` doesn't, given that the former is deprecated, as you already mentioned, and the latter is what Apple precisely [recommends](https://developer.apple.com/documentation/appkit/nsapplication/activate(ignoringotherapps:)?language=objc) to use instead. In any case, probably something for https://bugs.openjdk.org/browse/JDK-8348878. ------------- PR Review: https://git.openjdk.org/jfx/pull/1685#pullrequestreview-2578962367 PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932581424 From angorya at openjdk.org Tue Jan 28 17:29:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 17:29:53 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 17:23:50 GMT, Jose Pereda wrote: >> The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. >> >> The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. >> >> Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. >> >> I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). > > modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 286: > >> 284: LOG("-> need to active application"); >> 285: dispatch_async(dispatch_get_main_queue(), ^{ >> 286: [NSApp activateIgnoringOtherApps:YES]; > > I see that the CanvasTest mentioned in the JBS issue passes now with this fix, and fails with `[NSApp activate];` > > I'm not sure why `[NSApp activateIgnoringOtherApps:YES];` works but `[NSApp activate];` doesn't, given that the former is deprecated, as you already mentioned, and the latter is what Apple precisely [recommends](https://developer.apple.com/documentation/appkit/nsapplication/activate(ignoringotherapps:)?language=objc) to use instead. > In any case, probably something for https://bugs.openjdk.org/browse/JDK-8348878. @jperedadnr can you add this comment to https://bugs.openjdk.org/browse/JDK-8348878 please? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932586525 From jpereda at openjdk.org Tue Jan 28 17:34:58 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 28 Jan 2025 17:34:58 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 17:27:17 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 286: >> >>> 284: LOG("-> need to active application"); >>> 285: dispatch_async(dispatch_get_main_queue(), ^{ >>> 286: [NSApp activateIgnoringOtherApps:YES]; >> >> I see that the CanvasTest mentioned in the JBS issue passes now with this fix, and fails with `[NSApp activate];` >> >> I'm not sure why `[NSApp activateIgnoringOtherApps:YES];` works but `[NSApp activate];` doesn't, given that the former is deprecated, as you already mentioned, and the latter is what Apple precisely [recommends](https://developer.apple.com/documentation/appkit/nsapplication/activate(ignoringotherapps:)?language=objc) to use instead. >> In any case, probably something for https://bugs.openjdk.org/browse/JDK-8348878. > > @jperedadnr can you add this comment to https://bugs.openjdk.org/browse/JDK-8348878 please? Done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932595626 From kcr at openjdk.org Tue Jan 28 17:54:55 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 17:54:55 GMT Subject: RFR: 8348736: RichTextArea clamp and getText In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:10:18 GMT, Andy Goryachev wrote: > Fixes minor issues uncovered while writing API tests #1677: > > - StyledTextModel::clamp L559 is incorrect at the end of paragraph > - CodeArea.getText() adds extra newline at the end > > This change should be back-ported to jfx24. Looks good, including the updated title. I left a question and suggestion and will reapprove if you make changes. @arapte or @lukostyra can one of you be the second reviewer? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 424: > 422: StyledTextModel m = getModel(); > 423: if (m == null) { > 424: return null; This didn't used to return `null` before this fix (it would throw NPE on a null model). Perhaps returning the empty string be better? Either way, it would be helpful to document whether or not this method can return null. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 433: > 431: } catch (IOException e) { > 432: // should not happen > 433: throw new RuntimeException(e); Minor: wrapping it in `UncheckedIOException` is preferred over raw `RuntimeException`. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1684#pullrequestreview-2578992848 PR Comment: https://git.openjdk.org/jfx/pull/1684#issuecomment-2619689946 PR Review Comment: https://git.openjdk.org/jfx/pull/1684#discussion_r1932600423 PR Review Comment: https://git.openjdk.org/jfx/pull/1684#discussion_r1932602977 From mstrauss at openjdk.org Tue Jan 28 17:55:04 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jan 2025 17:55:04 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v41] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 23:39:26 GMT, Michael Strau? wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> hide default window buttons on macOS > > Another change is the option to use multiple header bars, which now cooperate gracefully. This enables application developers to create advanced layouts, for example having two header bars in a `SplitPane`, where each `HeaderBar` has a different background. > @mstr2 there is still active development going on - should this PR be sent back to Draft? I've incorporated review feedback received so far. Looking forward to additional feedback and reviews. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2619689928 From mstrauss at openjdk.org Tue Jan 28 17:58:58 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jan 2025 17:58:58 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v43] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 16:38:53 GMT, Andy Goryachev wrote: > Minor comment about the Monkey Tester (it's more of a limitation due to our test sprint process). There is a more recent repo https://github.com/andy-goryachev-oracle/MonkeyTest which has a dedicated Stage page which allows for limited configuration, have you tried it?. > > I see that your code does a bit more, so I'll incorporate your changes into the standalone repo regardless. The jfx MT will get a refresh once our test sprint starts (March?) I know about the MonkeyTester mirror, but I think the tests should go into the main repository with this PR. I'll have a look at the other Stage page, and incorporate changes here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2619698813 From angorya at openjdk.org Tue Jan 28 17:59:10 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 17:59:10 GMT Subject: RFR: 8348736: RichTextArea clamp and getText [v2] In-Reply-To: References: Message-ID: > Fixes minor issues uncovered while writing API tests #1677: > > - StyledTextModel::clamp L559 is incorrect at the end of paragraph > - CodeArea.getText() adds extra newline at the end > > This change should be back-ported to jfx24. 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/1684/files - new: https://git.openjdk.org/jfx/pull/1684/files/a55dc8db..ff8942b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1684&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1684&range=00-01 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1684.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1684/head:pull/1684 PR: https://git.openjdk.org/jfx/pull/1684 From angorya at openjdk.org Tue Jan 28 18:02:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 28 Jan 2025 18:02:59 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v43] In-Reply-To: References: Message-ID: <8RRl23yt3vni6e1HTg8deNgeNgQrflL5aTPy-w3uEPA=.e4e93965-9af2-4146-9281-7850828afef1@github.com> On Tue, 28 Jan 2025 17:56:36 GMT, Michael Strau? wrote: > I think the tests should go into the main repository with this PR you are absolutely right, my earlier comment was just FYI. these changes refer to new StageStyle's directly, while the mirror enumerates which makes it backward/forward compatible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2619706243 From kcr at openjdk.org Tue Jan 28 19:56:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 19:56:52 GMT Subject: RFR: 8348736: RichTextArea clamp and getText [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:59:10 GMT, Andy Goryachev wrote: >> Fixes minor issues uncovered while writing API tests #1677: >> >> - StyledTextModel::clamp L559 is incorrect at the end of paragraph >> - CodeArea.getText() adds extra newline at the end >> >> This change should be back-ported to jfx24. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1684#pullrequestreview-2579281038 From kcr at openjdk.org Tue Jan 28 21:59:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 21:59:51 GMT Subject: RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 17:32:21 GMT, Jose Pereda wrote: >> @jperedadnr can you add this comment to https://bugs.openjdk.org/browse/JDK-8348878 please? > > Done > I'm not sure why [NSApp activateIgnoringOtherApps:YES]; works but [NSApp activate]; doesn't, given that the former is deprecated, as you already mentioned, and the latter is what Apple precisely [recommends](https://developer.apple.com/documentation/appkit/nsapplication/activate(ignoringotherapps:)?language=objc) to use instead. The default activation mode is to only activate only when no other app is active, after first deactivating the launching application. This is true for the new `activate` method as well as the existing `activateWithOptions` method. `[NSApp activate]` is equivalent to `[NSApp activateIgnoringOtherApps:NO]`. The `activateIgnoringOtherApps` method says this: > By default, activation deactivates the calling app (assuming it was active), and then the new app is activated only if there?s no currently active application. This prevents the new app from stealing focus from the user, if the app is slow to activate and the user has switched to a different app in the interim. However, if you specify NSApplicationActivateIgnoringOtherApps, the application is activated regardless of the currently active app, potentially stealing focus from the user. Let's continue looking into this in the context of [JDK-8348878](https://bugs.openjdk.org/browse/JDK-8348878). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1685#discussion_r1932918326 From kcr at openjdk.org Wed Jan 29 00:08:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 00:08:59 GMT Subject: RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 Message-ID: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> We currently skip 4 failing lighting tests on macOS 14 / aarch64. Those same tests fail on macOS 15 now, so this modifies the check used to skip those tests to macOS 14 _or later_ / aarch64. I'll run a CI test build on macOS 15 with this fix and the fix in PR #1685. ------------- Commit messages: - 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 Changes: https://git.openjdk.org/jfx/pull/1686/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1686&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348895 Stats: 25 lines in 1 file changed: 20 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1686.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1686/head:pull/1686 PR: https://git.openjdk.org/jfx/pull/1686 From kcr at openjdk.org Wed Jan 29 00:08:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 00:08:59 GMT Subject: RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> References: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> Message-ID: <1WLWnMZVkRhyWSvT_0dvLMHq8hmdT00PoIxbW-xl6vs=.4e734f02-91b5-42cc-9048-dcc627a7e1d6@github.com> On Tue, 28 Jan 2025 21:23:37 GMT, Kevin Rushforth wrote: > We currently skip 4 failing lighting tests on macOS 14 / aarch64. Those same tests fail on macOS 15 now, so this modifies the check used to skip those tests to macOS 14 _or later_ / aarch64. > > I'll run a CI test build on macOS 15 with this fix and the fix in PR #1685. With this fix and the fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) all test pass on macOS 15 / aarch64 (as well as continuing to pass on other platforms). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1686#issuecomment-2620303901 From arapte at openjdk.org Wed Jan 29 04:22:54 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 29 Jan 2025 04:22:54 GMT Subject: RFR: 8348736: RichTextArea clamp and getText [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:59:10 GMT, Andy Goryachev wrote: >> Fixes minor issues uncovered while writing API tests #1677: >> >> - StyledTextModel::clamp L559 is incorrect at the end of paragraph >> - CodeArea.getText() adds extra newline at the end >> >> This change should be back-ported to jfx24. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1684#pullrequestreview-2579965590 From kcr at openjdk.org Wed Jan 29 13:06:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 13:06:56 GMT Subject: Integrated: 8348744: Application window not always activated on macOS 15 In-Reply-To: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> References: <6ginn8giH4EpW-olj69mB-OwUsry2ehOTsg3z2QfJHk=.995818d9-e727-4804-9479-8230e8bd35ca@github.com> Message-ID: On Tue, 28 Jan 2025 12:35:13 GMT, Kevin Rushforth wrote: > The fix for [JDK-8319066](https://bugs.openjdk.org/browse/JDK-8319066) added a needed call to activate a JavaFX window on macOS 14 or later via `[NSApp activate]`. In macOS 15, this doesn't always activate the window; even on macOS 14 there are certain cases where it might not. In all other places where we need to activate a window we call `[NSApp activateIgnoringOtherApps:YES]`. This is also what AWT uses in all places. > > The fix is to replace the call to `activate` with a call to `activateIgnoringOtherApps`. I ran a full set of headful tests on macOS 15, 14, and 13 (although the code is not executed on macOS 13), and everything looks good on my end. > > Worth noting is that `NSApp::activateIgnoringOtherApps` is deprecated as of MacOS SDK 14, which means that we might have problems in the future when we update the Xcode toolchain (or if they eventually degrade it so that the `ignoringOtherApps` part of this call stops doing anything), but that will be a problem we need to address anyway, affecting other places in JavaFX and AWT. > > I intend to backported this fix to `jfx24` after it is integrated into mainline (for 25). This pull request has now been integrated. Changeset: f55f5c60 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f55f5c609f67c1f7a8b8107d6ab1c6945fc44506 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8348744: Application window not always activated on macOS 15 Reviewed-by: angorya, jpereda ------------- PR: https://git.openjdk.org/jfx/pull/1685 From kcr at openjdk.org Wed Jan 29 13:58:24 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 13:58:24 GMT Subject: [jfx24] RFR: 8348744: Application window not always activated on macOS 15 Message-ID: Clean backport of macOS 15 activation fix to the `jfx24` stabilization branch. ------------- Commit messages: - Backport f55f5c609f67c1f7a8b8107d6ab1c6945fc44506 Changes: https://git.openjdk.org/jfx/pull/1687/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348744 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1687.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1687/head:pull/1687 PR: https://git.openjdk.org/jfx/pull/1687 From angorya at openjdk.org Wed Jan 29 15:32:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 15:32:06 GMT Subject: Integrated: 8348736: RichTextArea clamp and getText In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:10:18 GMT, Andy Goryachev wrote: > Fixes minor issues uncovered while writing API tests #1677: > > - StyledTextModel::clamp L559 is incorrect at the end of paragraph > - CodeArea.getText() adds extra newline at the end > > This change should be back-ported to jfx24. This pull request has now been integrated. Changeset: 2b5b1132 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/2b5b11320087de9b7bb6f330236a5c15eb4cabea Stats: 220 lines in 7 files changed: 156 ins; 51 del; 13 mod 8348736: RichTextArea clamp and getText Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1684 From kcr at openjdk.org Wed Jan 29 15:37:57 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 15:37:57 GMT Subject: RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> References: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> Message-ID: On Tue, 28 Jan 2025 21:23:37 GMT, Kevin Rushforth wrote: > We currently skip 4 failing lighting tests on macOS 14 / aarch64. Those same tests fail on macOS 15 now, so this modifies the check used to skip those tests to macOS 14 _or later_ / aarch64. > > I'll run a CI test build on macOS 15 with this fix and the fix in PR #1685. ~~@jperedadnr or @andy-goryachev-oracle can one of you review this clean backport?~~ wrong PR Reviewer: @arapte @jayathirthrao You might also want to take a look. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1686#issuecomment-2621984072 PR Comment: https://git.openjdk.org/jfx/pull/1686#issuecomment-2621985825 From kcr at openjdk.org Wed Jan 29 15:37:57 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 15:37:57 GMT Subject: [jfx24] RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 13:53:59 GMT, Kevin Rushforth wrote: > Clean backport of macOS 15 activation fix to the `jfx24` stabilization branch. @jperedadnr or @andy-goryachev-oracle can one of you review this clean backport? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1687#issuecomment-2621988968 From angorya at openjdk.org Wed Jan 29 15:40:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 15:40:57 GMT Subject: [jfx24] RFR: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 13:53:59 GMT, Kevin Rushforth wrote: > Clean backport of macOS 15 activation fix to the `jfx24` stabilization branch. looks good ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1687#pullrequestreview-2581449916 From arapte at openjdk.org Wed Jan 29 16:28:56 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 29 Jan 2025 16:28:56 GMT Subject: RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> References: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> Message-ID: On Tue, 28 Jan 2025 21:23:37 GMT, Kevin Rushforth wrote: > We currently skip 4 failing lighting tests on macOS 14 / aarch64. Those same tests fail on macOS 15 now, so this modifies the check used to skip those tests to macOS 14 _or later_ / aarch64. > > I'll run a CI test build on macOS 15 with this fix and the fix in PR #1685. LGTM. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1686#pullrequestreview-2581590482 From angorya at openjdk.org Wed Jan 29 16:45:23 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 16:45:23 GMT Subject: RFR: 8347359: RichTextArea API Tests Message-ID: Additional RichTextArea API tests. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into 8347359.rta.api.tests - review comments - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into - newlines - check - cleanup - clamp - get text - Merge branch 'master' into 8347359.rta.api.tests - ... and 9 more: https://git.openjdk.org/jfx/compare/2b5b1132...25845fa8 Changes: https://git.openjdk.org/jfx/pull/1677/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347359 Stats: 1384 lines in 10 files changed: 1323 ins; 29 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/1677.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1677/head:pull/1677 PR: https://git.openjdk.org/jfx/pull/1677 From angorya at openjdk.org Wed Jan 29 16:45:23 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 16:45:23 GMT Subject: RFR: 8347359: RichTextArea API Tests In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 19:44:01 GMT, Andy Goryachev wrote: > Additional RichTextArea API tests. one reviewer is probably fine, but feel free to take a look everyone. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1677#issuecomment-2622161782 From jdv at openjdk.org Wed Jan 29 17:05:01 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 29 Jan 2025 17:05:01 GMT Subject: RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> References: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> Message-ID: On Tue, 28 Jan 2025 21:23:37 GMT, Kevin Rushforth wrote: > We currently skip 4 failing lighting tests on macOS 14 / aarch64. Those same tests fail on macOS 15 now, so this modifies the check used to skip those tests to macOS 14 _or later_ / aarch64. > > I'll run a CI test build on macOS 15 with this fix and the fix in PR #1685. Marked as reviewed by jdv (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1686#pullrequestreview-2581688115 From angorya at openjdk.org Wed Jan 29 17:31:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 17:31:01 GMT Subject: [jfx24] RFR: 8348736: RichTextArea clamp and getText Message-ID: Clean backport of RichTextArea clamp and getText fix to the jfx24 stabilization branch. ------------- Commit messages: - Backport 2b5b11320087de9b7bb6f330236a5c15eb4cabea Changes: https://git.openjdk.org/jfx/pull/1688/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348736 Stats: 220 lines in 7 files changed: 156 ins; 51 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1688.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1688/head:pull/1688 PR: https://git.openjdk.org/jfx/pull/1688 From kcr at openjdk.org Wed Jan 29 17:33:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 17:33:51 GMT Subject: Integrated: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> References: <_IKfZc1aYcVEdO__C-q8NrnZuLp26qxrF4KpPq-Yh3U=.11a1fbad-f57d-4cd4-9849-d4df671b447d@github.com> Message-ID: On Tue, 28 Jan 2025 21:23:37 GMT, Kevin Rushforth wrote: > We currently skip 4 failing lighting tests on macOS 14 / aarch64. Those same tests fail on macOS 15 now, so this modifies the check used to skip those tests to macOS 14 _or later_ / aarch64. > > I'll run a CI test build on macOS 15 with this fix and the fix in PR #1685. This pull request has now been integrated. Changeset: 98b4b2e1 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/98b4b2e1127db5b23a4d7d86849aec0955d4fbf9 Stats: 25 lines in 1 file changed: 20 ins; 0 del; 5 mod 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 Reviewed-by: arapte, jdv ------------- PR: https://git.openjdk.org/jfx/pull/1686 From kcr at openjdk.org Wed Jan 29 17:36:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 17:36:51 GMT Subject: [jfx24] RFR: 8348736: RichTextArea clamp and getText In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 17:26:03 GMT, Andy Goryachev wrote: > Clean backport of RichTextArea clamp and getText fix to the jfx24 stabilization branch. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1688#pullrequestreview-2581769138 From kcr at openjdk.org Wed Jan 29 17:57:51 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 17:57:51 GMT Subject: [jfx24] Integrated: 8348744: Application window not always activated on macOS 15 In-Reply-To: References: Message-ID: <6t76X61SAStWwPLDdfR8m6OZKFi3QyeGLQLf_6JcKuo=.d3ecc267-9ef8-4583-94e2-0f52913f2791@github.com> On Wed, 29 Jan 2025 13:53:59 GMT, Kevin Rushforth wrote: > Clean backport of macOS 15 activation fix to the `jfx24` stabilization branch. This pull request has now been integrated. Changeset: 0f540e25 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0f540e251f81e726bdd51a32e6b408ddf06b22e9 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8348744: Application window not always activated on macOS 15 Reviewed-by: angorya Backport-of: f55f5c609f67c1f7a8b8107d6ab1c6945fc44506 ------------- PR: https://git.openjdk.org/jfx/pull/1687 From kcr at openjdk.org Wed Jan 29 17:59:00 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 17:59:00 GMT Subject: [jfx24] RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 Message-ID: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> Clean backport to the `jfx24` stabilization branch of test fix to exclude lighting tests on macOS 14+ (aarch64) ------------- Commit messages: - Backport 98b4b2e1127db5b23a4d7d86849aec0955d4fbf9 Changes: https://git.openjdk.org/jfx/pull/1689/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1689&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348895 Stats: 25 lines in 1 file changed: 20 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1689.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1689/head:pull/1689 PR: https://git.openjdk.org/jfx/pull/1689 From kcr at openjdk.org Wed Jan 29 18:03:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 18:03:52 GMT Subject: [jfx24] RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> References: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> Message-ID: On Wed, 29 Jan 2025 17:55:11 GMT, Kevin Rushforth wrote: > Clean backport to the `jfx24` stabilization branch of test fix to exclude lighting tests on macOS 14+ (aarch64) Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1689#issuecomment-2622462766 From duke at openjdk.org Wed Jan 29 18:08:26 2025 From: duke at openjdk.org (Ziad El Midaoui) Date: Wed, 29 Jan 2025 18:08:26 GMT Subject: RFR: 8340693: [TestBug] Format Error in USKeyboardTest Message-ID: The USKeyboardTest tests were failing with IllegalFormatArgumentIndexException at index 0, in java.util.Formatter the first argument is referred to as 1$ not 0$ . ------------- Commit messages: - Fixed USKeyboardTest Tests failing Changes: https://git.openjdk.org/jfx/pull/1683/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1683&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340693 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1683.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1683/head:pull/1683 PR: https://git.openjdk.org/jfx/pull/1683 From angorya at openjdk.org Wed Jan 29 18:08:26 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 18:08:26 GMT Subject: RFR: 8340693: [TestBug] Format Error in USKeyboardTest In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 19:46:22 GMT, Ziad El Midaoui wrote: > The USKeyboardTest tests were failing with IllegalFormatArgumentIndexException at index 0, in java.util.Formatter the first argument is referred to as 1$ not 0$ . Looks good! The test fails in the master branch and runs ok with the fix. I'll approve once OCA is verified. @Ziad-Mid please turn this into a regular pull request once the OCA gets verified. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1683#issuecomment-2616535149 PR Comment: https://git.openjdk.org/jfx/pull/1683#issuecomment-2619411533 From angorya at openjdk.org Wed Jan 29 18:26:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 18:26:55 GMT Subject: RFR: 8340693: [TestBug] Format Error in USKeyboardTest In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 19:46:22 GMT, Ziad El Midaoui wrote: > The USKeyboardTest tests were failing with IllegalFormatArgumentIndexException at index 0, in java.util.Formatter the first argument is referred to as 1$ not 0$ . Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1683#pullrequestreview-2581874377 From angorya at openjdk.org Wed Jan 29 18:31:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 18:31:55 GMT Subject: RFR: 8340693: [TestBug] Format Error in USKeyboardTest In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 19:46:22 GMT, Ziad El Midaoui wrote: > The USKeyboardTest tests were failing with IllegalFormatArgumentIndexException at index 0, in java.util.Formatter the first argument is referred to as 1$ not 0$ . the standard procedure is to wait at least 24 hours for people in other time zones to be able to take a look and comment (I don't really expect any comments, the fix is fairly simple) and then you can issue the integrate command. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1683#issuecomment-2622516825 From angorya at openjdk.org Wed Jan 29 17:49:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 17:49:53 GMT Subject: [jfx24] Integrated: 8348736: RichTextArea clamp and getText In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 17:26:03 GMT, Andy Goryachev wrote: > Clean backport of RichTextArea clamp and getText fix to the jfx24 stabilization branch. This pull request has now been integrated. Changeset: 7f3e320c Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/7f3e320c02c08e7e586f14a6f007eaac498044bb Stats: 220 lines in 7 files changed: 156 ins; 51 del; 13 mod 8348736: RichTextArea clamp and getText Reviewed-by: kcr Backport-of: 2b5b11320087de9b7bb6f330236a5c15eb4cabea ------------- PR: https://git.openjdk.org/jfx/pull/1688 From angorya at openjdk.org Wed Jan 29 19:01:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 19:01:40 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v2] In-Reply-To: References: Message-ID: > Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts). The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel). The default font size has changed from 10 to 12 to make it closer to win/linux. > > This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests. > > Existing tests have been adjusted/reworked mainly due to default font size change. 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 19 additional commits since the last revision: - atomic boolean - Merge branch 'master' into 8342565.stub.text.layout - cleanup - better test - cleanup - more magic - magic numbers - more - add exports - stub fonts - ... and 9 more: https://git.openjdk.org/jfx/compare/f8bcfa32...5010278f ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1667/files - new: https://git.openjdk.org/jfx/pull/1667/files/a4a3ebb3..5010278f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=00-01 Stats: 291 lines in 12 files changed: 186 ins; 79 del; 26 mod Patch: https://git.openjdk.org/jfx/pull/1667.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667 PR: https://git.openjdk.org/jfx/pull/1667 From angorya at openjdk.org Wed Jan 29 19:06:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 29 Jan 2025 19:06:54 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v7] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Mon, 27 Jan 2025 20:22:30 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - ... and 31 more: https://git.openjdk.org/jfx/compare/a1765747...5464d7ee @aghaisas or @arapte would you please take a look? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2622591988 From kcr at openjdk.org Wed Jan 29 21:45:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 21:45:59 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v7] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Mon, 27 Jan 2025 20:22:30 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - ... and 31 more: https://git.openjdk.org/jfx/compare/a1765747...5464d7ee All my testing looks good. I left a couple more comments about using ceil for max as well as min. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 79: > 77: min[i] = cmin; > 78: max[i] = cmax; > 79: pref[i] = clip(snapRound(c.getPrefWidth()), cmin, cmax); Since `prefWidth` is a size, should it also be `snapCeil`? modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 588: > 586: } > 587: > 588: private double snapFloor(double x) { This method can be removed if you change max to use `snapCeil`. modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 108: > 106: width = max; > 107: if (width < min) { > 108: // safety check in case floor(max) < ceil(min) This comment should now be changed to: "...in case ceil(max) < ceil(min)" (or maybe just "...max < min") ------------- PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-2582197459 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1934664642 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1934689930 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1934552495 From kcr at openjdk.org Wed Jan 29 21:46:00 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 21:46:00 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v7] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Wed, 5 Jul 2023 16:53:41 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 77: >> >>> 75: double cmin = snapCeil(c.getMinWidth()); // always honor min width! >>> 76: double cmax = snapFloor(c.getMaxWidth()); // TableColumnBase.doSetWidth() clamps to (min,max) range >>> 77: min[i] = cmin; >> >> Looking at `doSetWidth` I see that it clamps using unsnapped values, so the column can still be given an unsnapped size. When scale is 1.0, and the column for example has its min/max width set to 20.1 and 20.9, then snapCeil is 21 and snapFloor is 20 (so maximum is less than minimum, which may already be a bit dubious). When `doSetWidth` is called it will be clamped, resulting in `20.1` or `20.9`. > > For some reason, I've decided to leave that as is, but since you pointed it out, I think it ought to be fixed. > > I am going to implement proper snapping logic in ResizeFeaturesBase.setColumnWidth() using private APIs, with the intent to eventually convert them to public APIs with https://bugs.openjdk.org/browse/JDK-8311527 As with my earlier comment in `ResizeFeaturesBase` (which you fixed), I don't think we should be using different snapping functions for min and max. I recommend `snapCeil` for both. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1934655915 From kcr at openjdk.org Wed Jan 29 21:46:01 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jan 2025 21:46:01 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v6] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <6IwkYWlgpgGuZAqWRgmrK2YA4Zjm-KhYmXmFSLDddmQ=.fed0248f-135a-4f11-bff9-d9ebc7178958@github.com> Message-ID: <5vYcF55qwKUUNDzQYSQdF7h6Dkw8cSG16vzs7rkFamc=.4620c37f-4763-4f11-8c9f-b71edb18533e@github.com> On Mon, 27 Jan 2025 15:41:55 GMT, Andy Goryachev wrote: >>> we will violate the max constraint if we snap to a larger value. >> >> Well, it's inherently an over-constrained problem. Conceptually, though, this does not violate the constraint. When snap-to-pixel is enabled, all values, including min and max values are snapped to a pixel that can be almost 1 pixel larger or smaller than it's given value. Within that tolerance, we are honoring the min and max values. >> >> It isn't required that we always ceil the min value and floor the max value (not to mention that doing that is what causes the odd min > max). >> >> So I don't buy this argument. Is there some other reason to do it? > > no other reason. are you suggesting to simply `round()`? Your change to use `snapSize` for both (which ends up calling `ceil`) looks good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1934555424 From arapte at openjdk.org Thu Jan 30 03:39:52 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 30 Jan 2025 03:39:52 GMT Subject: [jfx24] RFR: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> References: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> Message-ID: On Wed, 29 Jan 2025 17:55:11 GMT, Kevin Rushforth wrote: > Clean backport to the `jfx24` stabilization branch of test fix to exclude lighting tests on macOS 14+ (aarch64) Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1689#pullrequestreview-2582850044 From kcr at openjdk.org Thu Jan 30 12:48:02 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 30 Jan 2025 12:48:02 GMT Subject: [jfx24] Integrated: 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 In-Reply-To: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> References: <6dlDJakhC1IOWB-T1jsdstf8xqpZsozDqf8DF1Se-KU=.30fdbfd6-63cc-4da2-b7cb-91a915b833cf@github.com> Message-ID: On Wed, 29 Jan 2025 17:55:11 GMT, Kevin Rushforth wrote: > Clean backport to the `jfx24` stabilization branch of test fix to exclude lighting tests on macOS 14+ (aarch64) This pull request has now been integrated. Changeset: e079ed31 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e079ed31f9bfd0af59319f48ebf9c75f78805970 Stats: 25 lines in 1 file changed: 20 ins; 0 del; 5 mod 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 Reviewed-by: arapte Backport-of: 98b4b2e1127db5b23a4d7d86849aec0955d4fbf9 ------------- PR: https://git.openjdk.org/jfx/pull/1689 From duke at openjdk.org Thu Jan 30 16:25:13 2025 From: duke at openjdk.org (Haidar Ali) Date: Thu, 30 Jan 2025 16:25:13 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v43] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 05:21:41 GMT, Michael Strau? wrote: >> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small MonkeyTester refactor I've been stalking this PR since October. Can't wait to use this feature in my project. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2624957389 From duke at openjdk.org Thu Jan 30 19:34:54 2025 From: duke at openjdk.org (Ziad El Midaoui) Date: Thu, 30 Jan 2025 19:34:54 GMT Subject: Integrated: 8340693: [TestBug] Format Error in USKeyboardTest In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 19:46:22 GMT, Ziad El Midaoui wrote: > The USKeyboardTest tests were failing with IllegalFormatArgumentIndexException at index 0, in java.util.Formatter the first argument is referred to as 1$ not 0$ . This pull request has now been integrated. Changeset: e0c73f6a Author: Ziad El Midaoui Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/e0c73f6a55e36df0defa28e1b353107fd5845c78 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8340693: [TestBug] Format Error in USKeyboardTest Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1683 From angorya at openjdk.org Thu Jan 30 23:02:36 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 30 Jan 2025 23:02:36 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v8] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). 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/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/5464d7ee..2fbc5859 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=06-07 Stats: 14 lines in 2 files changed: 0 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From angorya at openjdk.org Thu Jan 30 23:43:25 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 30 Jan 2025 23:43:25 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread Message-ID: Created a test that validates various Nodes can be initialized in a background thread. ------------- Commit messages: - cleanup - pagination - thread count - all controls - more tests - initial test Changes: https://git.openjdk.org/jfx/pull/1690/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348423 Stats: 1224 lines in 3 files changed: 1097 ins; 125 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1690.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1690/head:pull/1690 PR: https://git.openjdk.org/jfx/pull/1690 From mstrauss at openjdk.org Fri Jan 31 02:43:05 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 31 Jan 2025 02:43:05 GMT Subject: RFR: 8333275: ComboBox: adding an item from editor changes editor text Message-ID: When the current editor value of a `ComboBox` is added to its items list, the editor value may be changed to an entirely unrelated item in the list. However, our expectation would be that the editor reflects the newly added item instead. Under normal circumstances, adding items to the list in front of the current item causes `selectedIndex` to be shifted by the number of items added, keeping the editor value in sync with the currently selected item. Let's illustrate this with an example: `items = [foo, bar, baz]`, `selectedIndex = 0`, `selectedItem = foo` The user changes the editor value to `qux` and inserts the value at list position 0, causing the current index to be shifted to the right (in `ComboBoxSelectionModel::itemsContentObserver`): `items = [qux, foo, bar, baz]`, `selectedIndex = 1`, `selectedItem = foo` The index is shifted a second time in `ListViewBitSetSelectionModel::updateSelection`: `items = [qux, foo, bar, baz]`, `selectedIndex = 2`, `selectedItem = bar` Now `bar` is selected and shown in the editor, but we would expect `qux` instead. The fix is to detect that we're inserting the current editor value in `ComboBoxSelectionModel::itemsContentObserver`, and select the correct item directly. We also need to account for this situation in `ListViewBitSetSelectionModel`, where we check whether the current value is already contained in the added values. ------------- Commit messages: - fix - failing test Changes: https://git.openjdk.org/jfx/pull/1692/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1692&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333275 Stats: 67 lines in 3 files changed: 65 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1692.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1692/head:pull/1692 PR: https://git.openjdk.org/jfx/pull/1692 From lkostyra at openjdk.org Fri Jan 31 12:42:02 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 31 Jan 2025 12:42:02 GMT Subject: RFR: 8349008: Remove temporary font file tracking code Message-ID: This is a cleanup follow-up, removing `FontFileWriter.FontTracker` and all related uses. `FontTracker` was tracking font size use when SecurityManager was present, however since we removed SM, `FontTracker` was no longer activated and as such was dead code. `FontFileWriter.FontTracker` and its use in `FontFileWriter` + related methods were removed. This in turn cleaned up `PrismFontFile` and made a couple of variables not longer used, including a `bool tracking` argument in constructor. These cleanups propagated to `PrismFontFactory`, `{CT,DW,FT}Factory` and `{CT,DW,FT}FontFile` classes. Tests worked the same after this change. ------------- Commit messages: - 8349008: Remove temporary font file tracking code Changes: https://git.openjdk.org/jfx/pull/1693/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1693&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349008 Stats: 215 lines in 9 files changed: 0 ins; 175 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1693.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1693/head:pull/1693 PR: https://git.openjdk.org/jfx/pull/1693 From kcr at openjdk.org Fri Jan 31 14:58:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 14:58:08 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v8] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: <7yiuBJTkT82uSy70jkFvpm1o6vhxt5U0B4syviEbSzE=.559cd8cc-bd6b-4587-911f-4c5fc7084dd3@github.com> On Thu, 30 Jan 2025 23:02:36 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments LGTM now. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-2587001300 From angorya at openjdk.org Fri Jan 31 15:52:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 15:52:53 GMT Subject: RFR: 8349008: Remove temporary font file tracking code In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 12:37:04 GMT, Lukasz Kostyra wrote: > This is a cleanup follow-up, removing `FontFileWriter.FontTracker` and all related uses. `FontTracker` was tracking font size use when SecurityManager was present, however since we removed SM, `FontTracker` was no longer activated and as such was dead code. > > `FontFileWriter.FontTracker` and its use in `FontFileWriter` + related methods were removed. This in turn cleaned up `PrismFontFile` and made a couple of variables not longer used, including a `bool tracking` argument in constructor. These cleanups propagated to `PrismFontFactory`, `{CT,DW,FT}Factory` and `{CT,DW,FT}FontFile` classes. > > Tests worked the same after this change. modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java line 212: > 210: int fIndex, boolean register, > 211: boolean embedded, > 212: boolean copy) might want to change the copyright year to 2025 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1693#discussion_r1937522057 From angorya at openjdk.org Fri Jan 31 15:55:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 15:55:58 GMT Subject: RFR: 8349008: Remove temporary font file tracking code In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 12:37:04 GMT, Lukasz Kostyra wrote: > This is a cleanup follow-up, removing `FontFileWriter.FontTracker` and all related uses. `FontTracker` was tracking font size use when SecurityManager was present, however since we removed SM, `FontTracker` was no longer activated and as such was dead code. > > `FontFileWriter.FontTracker` and its use in `FontFileWriter` + related methods were removed. This in turn cleaned up `PrismFontFile` and made a couple of variables not longer used, including a `bool tracking` argument in constructor. These cleanups propagated to `PrismFontFactory`, `{CT,DW,FT}Factory` and `{CT,DW,FT}FontFile` classes. > > Tests worked the same after this change. lgtm, with one minor comment - will re-approve if you decide to change. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1693#pullrequestreview-2587144860 From kcr at openjdk.org Fri Jan 31 17:02:50 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 17:02:50 GMT Subject: RFR: 8349008: Remove temporary font file tracking code In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 12:37:04 GMT, Lukasz Kostyra wrote: > This is a cleanup follow-up, removing `FontFileWriter.FontTracker` and all related uses. `FontTracker` was tracking font size use when SecurityManager was present, however since we removed SM, `FontTracker` was no longer activated and as such was dead code. > > `FontFileWriter.FontTracker` and its use in `FontFileWriter` + related methods were removed. This in turn cleaned up `PrismFontFile` and made a couple of variables not longer used, including a `bool tracking` argument in constructor. These cleanups propagated to `PrismFontFactory`, `{CT,DW,FT}Factory` and `{CT,DW,FT}FontFile` classes. > > Tests worked the same after this change. Looks good with one minor thing I noticed. I greped for `tracker` in the font code after applying your patch, and see a comment that says "and decrement the byte count in the tracker object" in `PrismFontFactory.java`: 1405 } finally { 1406 /* If the data isn't a valid font, so that registering it 1407 * returns null, or we didn't get so far as copying the data, 1408 * delete the tmp file and decrement the byte count 1409 * in the tracker object before returning. 1410 */ I'll reapprove if you fix it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1693#pullrequestreview-2587304618 From angorya at openjdk.org Fri Jan 31 17:36:52 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 17:36:52 GMT Subject: RFR: 8333275: ComboBox: adding an item from editor changes editor text In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 02:37:42 GMT, Michael Strau? wrote: > When the current editor value of a `ComboBox` is added to its items list, the editor value may be changed to an entirely unrelated item in the list. However, our expectation would be that the editor reflects the newly added item instead. > > Under normal circumstances, adding items to the list in front of the current item causes `selectedIndex` to be shifted by the number of items added, keeping the editor value in sync with the currently selected item. > > Let's illustrate this with an example: > `items = [foo, bar, baz]`, `selectedIndex = 0`, `selectedItem = foo` > > The user changes the editor value to `qux` and inserts the value at list position 0, causing the current index to be shifted to the right (in `ComboBoxSelectionModel::itemsContentObserver`): > `items = [qux, foo, bar, baz]`, `selectedIndex = 1`, `selectedItem = foo` > > The index is shifted a second time in `ListViewBitSetSelectionModel::updateSelection`: > `items = [qux, foo, bar, baz]`, `selectedIndex = 2`, `selectedItem = bar` > > Now `bar` is selected and shown in the editor, but we would expect `qux` instead. The fix is to detect that we're inserting the current editor value in `ComboBoxSelectionModel::itemsContentObserver`, and select the correct item directly. We also need to account for this situation in `ListViewBitSetSelectionModel`, where we check whether the current value is already contained in the added values. modules/javafx.controls/src/main/java/javafx/scene/control/ComboBox.java line 601: > 599: } > 600: > 601: int index = -1; you may want to change the copyright year to 2025 in all the modified files modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 1315: > 1313: && (addedItemOffset = c.getAddedSubList().indexOf(selectedItem)) >= 0 > 1314: && selectedIndex == c.getFrom() + addedItemOffset) { > 1315: doSelectionUpdate = false; which scenario does this code path handle outside of tests? I could never hit a breakpoint in line 1315, except in ensureEditorValueDoesNotChangeWhenCurrentEditorValueIsAddedToItemsList(). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1692#discussion_r1937647640 PR Review Comment: https://git.openjdk.org/jfx/pull/1692#discussion_r1937646638 From mstrauss at openjdk.org Fri Jan 31 19:18:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 31 Jan 2025 19:18:17 GMT Subject: RFR: 8333275: ComboBox: adding an item from editor changes editor text [v2] In-Reply-To: References: Message-ID: <7yGjKkuy8uPB520iAFF2PkwK46QR9UhzRqadGQ_bW7A=.98f5a254-a592-4941-895d-d154be927157@github.com> On Fri, 31 Jan 2025 17:27:47 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright header > > modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java line 1315: > >> 1313: && (addedItemOffset = c.getAddedSubList().indexOf(selectedItem)) >= 0 >> 1314: && selectedIndex == c.getFrom() + addedItemOffset) { >> 1315: doSelectionUpdate = false; > > which scenario does this code path handle outside of tests? > > I could never hit a breakpoint in line 1315, except in ensureEditorValueDoesNotChangeWhenCurrentEditorValueIsAddedToItemsList(). It's only when `ComboBox.getEditor().setText(...)` is called, which doesn't seem to immediately update the current value. This shouldn't really happen in most applications. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1692#discussion_r1937796779 From mstrauss at openjdk.org Fri Jan 31 19:18:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 31 Jan 2025 19:18:17 GMT Subject: RFR: 8333275: ComboBox: adding an item from editor changes editor text [v2] In-Reply-To: References: Message-ID: > When the current editor value of a `ComboBox` is added to its items list, the editor value may be changed to an entirely unrelated item in the list. However, our expectation would be that the editor reflects the newly added item instead. > > Under normal circumstances, adding items to the list in front of the current item causes `selectedIndex` to be shifted by the number of items added, keeping the editor value in sync with the currently selected item. > > Let's illustrate this with an example: > `items = [foo, bar, baz]`, `selectedIndex = 0`, `selectedItem = foo` > > The user changes the editor value to `qux` and inserts the value at list position 0, causing the current index to be shifted to the right (in `ComboBoxSelectionModel::itemsContentObserver`): > `items = [qux, foo, bar, baz]`, `selectedIndex = 1`, `selectedItem = foo` > > The index is shifted a second time in `ListViewBitSetSelectionModel::updateSelection`: > `items = [qux, foo, bar, baz]`, `selectedIndex = 2`, `selectedItem = bar` > > Now `bar` is selected and shown in the editor, but we would expect `qux` instead. The fix is to detect that we're inserting the current editor value in `ComboBoxSelectionModel::itemsContentObserver`, and select the correct item directly. We also need to account for this situation in `ListViewBitSetSelectionModel`, where we check whether the current value is already contained in the added values. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: update copyright header ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1692/files - new: https://git.openjdk.org/jfx/pull/1692/files/25a57af9..204eae18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1692&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1692&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1692.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1692/head:pull/1692 PR: https://git.openjdk.org/jfx/pull/1692 From angorya at openjdk.org Fri Jan 31 19:26:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 19:26:51 GMT Subject: RFR: 8333275: ComboBox: adding an item from editor changes editor text [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 19:18:17 GMT, Michael Strau? wrote: >> When the current editor value of a `ComboBox` is added to its items list, the editor value may be changed to an entirely unrelated item in the list. However, our expectation would be that the editor reflects the newly added item instead. >> >> Under normal circumstances, adding items to the list in front of the current item causes `selectedIndex` to be shifted by the number of items added, keeping the editor value in sync with the currently selected item. >> >> Let's illustrate this with an example: >> `items = [foo, bar, baz]`, `selectedIndex = 0`, `selectedItem = foo` >> >> The user changes the editor value to `qux` and inserts the value at list position 0, causing the current index to be shifted to the right (in `ComboBoxSelectionModel::itemsContentObserver`): >> `items = [qux, foo, bar, baz]`, `selectedIndex = 1`, `selectedItem = foo` >> >> The index is shifted a second time in `ListViewBitSetSelectionModel::updateSelection`: >> `items = [qux, foo, bar, baz]`, `selectedIndex = 2`, `selectedItem = bar` >> >> Now `bar` is selected and shown in the editor, but we would expect `qux` instead. The fix is to detect that we're inserting the current editor value in `ComboBoxSelectionModel::itemsContentObserver`, and select the correct item directly. We also need to account for this situation in `ListViewBitSetSelectionModel`, where we check whether the current value is already contained in the added values. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright header Marked as reviewed by angorya (Reviewer). I'd like a second pair of eyes on this, due to change in ListView (though the change looks reasonable and the test seems to be doing the right thing). Also, I only tested it with the reproducer on macOS 15.1.1 M1, can we get this tested on Windows and/or Linux? (just noticed you already specified 2 reviewers, my "contribution" was unnecessary) ------------- PR Review: https://git.openjdk.org/jfx/pull/1692#pullrequestreview-2587607749 PR Comment: https://git.openjdk.org/jfx/pull/1692#issuecomment-2628126666 PR Comment: https://git.openjdk.org/jfx/pull/1692#issuecomment-2628130225 From kcr at openjdk.org Fri Jan 31 19:44:00 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 19:44:00 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 23:54:44 GMT, Andy Goryachev wrote: > Created a test that validates various Nodes can be initialized in a background thread. I like the overall structure of this test. I left several mostly "fit and finish" type comments. I will test it as part of finishing the review. What testing have you done? I recommend the following CI headful test runs: 1. A run using this branch "as is" to verify no failures on our headful systems 2. A run using a branch with all of the `@Disabled` tests enabled to see how well the test catches the bugs. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 136: > 134: * Tests Node initialization from a background thread, per > 135: * > 136: * https://openjfx.io/javadoc/23/javafx.graphics/javafx/scene/Node.html I prefer not to put external links to specific versions of the docs. I would just say "per the Node docs" or similar. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 146: > 144: * - WebView > 145: * > 146: * The test creates a visible node of a given type, and at the same time, starts a number of background threads Suggestion: "creates a visible node" --> "creates a visible node on the JavaFX application thread" tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 272: > 270: return c; > 271: }, (c) -> { > 272: c.show(); // does not fail here, unlike DatePicker? Interesting. I still think we should disallow it as I mentioned in the `DatePicker` case. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 305: > 303: return c; > 304: }, (c) -> { > 305: c.show(); // fails here As mentioned in the JBS issue, I think we should consider filing an issue to update the spec of `ComboBoxPopupControl::show` to require calling it on the JavaFX app thread (throwing an exception if called off thread). Either way, we should ensure that the skins themselves never call show unless the control is showing. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 377: > 375: c.setPopupSide(Side.RIGHT); > 376: accessControl(c); > 377: c.show(); This is another case of a `show` method that we should consider changing to require access only on the FX app thread. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 745: > 743: @Override > 744: public void run() { > 745: try { Suggestion: use a lambda rather than an inner class here . tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 755: > 753: inFx(() -> { > 754: operation.accept(visibleNode); > 755: }); Does this need to be done for each thread? I can see why it might make sense to do that, as it preserves the relative frequency of operations on the FX app thread versus the frequency off thread regardless of how many threads you have. It would risk flooding the FX event queue if the number of background threads were huge, but you limit it based on the number of physical HW threads, so this seems OK. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 779: > 777: > 778: private static boolean nextBoolean() { > 779: return new Random().nextBoolean(); It is a best practice when using Random to share a single instance and not allocate a new one each time. It is more performant and more random. tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 42: > 40: > 41: /** > 42: * Similar to VisualTestBase, but more convenient. If you are going to compare it to VisualTestBase, you need a more nuanced statement than just "more convenient" which could mislead someone into thinking that this is a replacement. It isn't. VisualTestBase is specifically intended for screen capture tests, so creates stages as `UNDECORATED` and `alwaysOnTop`, and provides pixel capture and comparison utilities. I recommend describing this class on its own terms. tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 65: > 63: stage.setScene(scene); > 64: stage.setWidth(STAGE_WIDTH); > 65: stage.setHeight(STAGE_HEIGHT); Typically, best practice is to set the width / height of the Scene, rather than the Stage, especially for decorated stages, although there are some times you might want to set the stage. It might not matter for what you are using it for. tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 81: > 79: @AfterAll > 80: public static void teardownOnce() { > 81: Util.shutdown(); Should you pass "stage" here, or do you ensure that the stage is always closed some other way? tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 173: > 171: * @param r the code to execute > 172: */ > 173: public void inFx(Runnable r) { Minor: Maybe call this method "runAndWait" instead? That would make it clearer what it does. tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 176: > 174: Util.runAndWait(() -> { > 175: r.run(); > 176: }); Minor: This can be reduced to `Util.runAndWait(r)` tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 183: > 181: * @param milliseconds the number of milliseconds to sleep > 182: */ > 183: protected void sleep(int milliseconds) { Maybe use `long` rather than `int` to match `Thread.sleep` and `Util.sleep`? It probably doesn't matter in practice. ------------- PR Review: https://git.openjdk.org/jfx/pull/1690#pullrequestreview-2587514918 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937765444 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937767206 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937799226 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937798147 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937801455 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937772645 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937776420 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937848601 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937750555 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937753823 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937755797 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937758040 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937762531 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937759121 From angorya at openjdk.org Fri Jan 31 19:52:11 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 19:52:11 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: References: Message-ID: <10MVPfOZNhuiNI8hv73NFXKrFgsWDSfToOqeW6qyJzE=.cc61e5b4-fc70-4a79-9818-156107289a1c@github.com> On Fri, 31 Jan 2025 19:41:06 GMT, Kevin Rushforth wrote: > What testing have you done? All disabled tests fail on my mac, I did not run the CI job (no need, I know they fail). Additionally, I ran the CI job with the tests disabled - this test runs fine (there were some unrelated failures on some platform) Curiously, I am having trouble reproducing the tooltip test today - it definitely failed yesterday. I am not sure what the difference is, so I am investigating this as a part of https://bugs.openjdk.org/browse/JDK-8348100 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2628250312 From angorya at openjdk.org Fri Jan 31 20:04:23 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 20:04:23 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 18:34:29 GMT, Kevin Rushforth wrote: >> Created a test that validates various Nodes can be initialized in a background thread. > > tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 81: > >> 79: @AfterAll >> 80: public static void teardownOnce() { >> 81: Util.shutdown(); > > Should you pass "stage" here, or do you ensure that the stage is always closed some other way? No, this method closes all the open stages. > tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 183: > >> 181: * @param milliseconds the number of milliseconds to sleep >> 182: */ >> 183: protected void sleep(int milliseconds) { > > Maybe use `long` rather than `int` to match `Thread.sleep` and `Util.sleep`? It probably doesn't matter in practice. it does not matter, no test should run 23 days ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937904580 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937912338 From kcr at openjdk.org Fri Jan 31 20:04:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 20:04:23 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: <10MVPfOZNhuiNI8hv73NFXKrFgsWDSfToOqeW6qyJzE=.cc61e5b4-fc70-4a79-9818-156107289a1c@github.com> References: <10MVPfOZNhuiNI8hv73NFXKrFgsWDSfToOqeW6qyJzE=.cc61e5b4-fc70-4a79-9818-156107289a1c@github.com> Message-ID: On Fri, 31 Jan 2025 19:49:02 GMT, Andy Goryachev wrote: > > What testing have you done? > > All disabled tests fail on my mac, I did not run the CI job (no need, I know they fail). Additionally, I ran the CI job with the tests disabled - this test runs fine (there were some unrelated failures on some platform) OK, good. I'll test on Windows. > Curiously, I am having trouble reproducing the tooltip test today - it definitely failed yesterday. I am not sure what the difference is, so I am investigating this as a part of https://bugs.openjdk.org/browse/JDK-8348100 It's a Friday and your system is tired after a long week? Seriously, that's one of the challenges of this sort of MT testing. For many race conditions, it's not easy to verify. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2628287537 From angorya at openjdk.org Fri Jan 31 20:10:04 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 20:10:04 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 19:16:44 GMT, Kevin Rushforth wrote: >> Created a test that validates various Nodes can be initialized in a background thread. > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 305: > >> 303: return c; >> 304: }, (c) -> { >> 305: c.show(); // fails here > > As mentioned in the JBS issue, I think we should consider filing an issue to update the spec of `ComboBoxPopupControl::show` to require calling it on the JavaFX app thread (throwing an exception if called off thread). Either way, we should ensure that the skins themselves never call show unless the control is showing. yes, we'll deal with later. I think there might be a solution which allows show() of an unconnected popup, and if that we'll use the ticket to add a javadoc comment and modify the test. > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 755: > >> 753: inFx(() -> { >> 754: operation.accept(visibleNode); >> 755: }); > > Does this need to be done for each thread? I can see why it might make sense to do that, as it preserves the relative frequency of operations on the FX app thread versus the frequency off thread regardless of how many threads you have. It would risk flooding the FX event queue if the number of background threads were huge, but you limit it based on the number of physical HW threads, so this seems OK. yes, jiggling the visible node during the test adds stress to the system, which is the intended behavior. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937930105 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937923749 From kcr at openjdk.org Fri Jan 31 20:10:04 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 20:10:04 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: References: Message-ID: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> On Fri, 31 Jan 2025 20:05:01 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 755: >> >>> 753: inFx(() -> { >>> 754: operation.accept(visibleNode); >>> 755: }); >> >> Does this need to be done for each thread? I can see why it might make sense to do that, as it preserves the relative frequency of operations on the FX app thread versus the frequency off thread regardless of how many threads you have. It would risk flooding the FX event queue if the number of background threads were huge, but you limit it based on the number of physical HW threads, so this seems OK. > > yes, jiggling the visible node during the test adds stress to the system, which is the intended behavior. Yes, I know. I was pointing out the fact that the frequency of the jitter will increase as the number of background threads increases. Which I think is fine. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937928906 From angorya at openjdk.org Fri Jan 31 20:15:09 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 20:15:09 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread In-Reply-To: References: Message-ID: <3nfBl0EEjPkaAWBj6TzqLHrdUm5POUus0HkR7B5lnP8=.9451dff5-a430-49d4-a0e3-e9418bcdab96@github.com> On Fri, 31 Jan 2025 19:36:02 GMT, Kevin Rushforth wrote: >> Created a test that validates various Nodes can be initialized in a background thread. > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 779: > >> 777: >> 778: private static boolean nextBoolean() { >> 779: return new Random().nextBoolean(); > > It is a best practice when using Random to share a single instance and not allocate a new one each time. It is more performant and more random. while true, the shared instance will add synchronization and this is something I would like to avoid. The degree of randomness is not that important in this case. the only thing that we lose is reproducibility, but in the case of a headful test it's probably impossible anyway, due to many other factors. In any case, I think the main purpose of this test is a sort of sanity check of the requirement, not an exhaustive test of all the properties and all the methods that the application can call from a background thread - at least that what I thought at the time of writing. We can always add more stress to it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937935407 From mstrauss at openjdk.org Fri Jan 31 20:15:10 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 31 Jan 2025 20:15:10 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v6] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 16:04:17 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they shouldn't be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - 8185887: Test for the TreeView graphic disappearance problem (JDK-8346824) > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > - 8185887: Rename method to fit domain > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction I tested this patch, which improves performance with many columns. The code changes look good. Regarding the discussion around requiring two layout passes: there's an old PR that attempted to fundamentally change that (iterative layout), which I think might solve a lot of these kinds of problems. ------------- Marked as reviewed by mstrauss (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1644#pullrequestreview-2587798369 From angorya at openjdk.org Fri Jan 31 20:54:31 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 20:54:31 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: Message-ID: > Created a test that validates various Nodes can be initialized in a background thread. 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/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/8786bab5..d1356dce Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=00-01 Stats: 50 lines in 2 files changed: 16 ins; 11 del; 23 mod Patch: https://git.openjdk.org/jfx/pull/1690.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1690/head:pull/1690 PR: https://git.openjdk.org/jfx/pull/1690 From angorya at openjdk.org Fri Jan 31 20:54:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 20:54:32 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: <10MVPfOZNhuiNI8hv73NFXKrFgsWDSfToOqeW6qyJzE=.cc61e5b4-fc70-4a79-9818-156107289a1c@github.com> Message-ID: On Fri, 31 Jan 2025 20:00:17 GMT, Kevin Rushforth wrote: > It's a Friday and your system is tired after a long week? It is also raining today... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2628374259 From kcr at openjdk.org Fri Jan 31 21:16:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 21:16:58 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 20:07:38 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 305: >> >>> 303: return c; >>> 304: }, (c) -> { >>> 305: c.show(); // fails here >> >> As mentioned in the JBS issue, I think we should consider filing an issue to update the spec of `ComboBoxPopupControl::show` to require calling it on the JavaFX app thread (throwing an exception if called off thread). Either way, we should ensure that the skins themselves never call show unless the control is showing. > > yes, we'll deal with later. > I think there might be a solution which allows show() of an unconnected popup, and if that we'll use the ticket to add a javadoc comment and modify the test. Yes, whatever we end up doing will be done as a follow-up. >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 779: >> >>> 777: >>> 778: private static boolean nextBoolean() { >>> 779: return new Random().nextBoolean(); >> >> It is a best practice when using Random to share a single instance and not allocate a new one each time. It is more performant and more random. > > while true, the shared instance will add synchronization and this is something I would like to avoid. The degree of randomness is not that important in this case. > > the only thing that we lose is reproducibility, but in the case of a headful test it's probably impossible anyway, due to many other factors. > > In any case, I think the main purpose of this test is a sort of sanity check of the requirement, not an exhaustive test of all the properties and all the methods that the application can call from a background thread - at least that what I thought at the time of writing. We can always add more stress to it. OK, that sounds reasonable. Maybe one other thing to consider would be `ThreadLocalRandom`, but it's probably OK ei ther way. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937984839 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937987472 From kcr at openjdk.org Fri Jan 31 21:16:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 21:16:59 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 20:54:31 GMT, Andy Goryachev wrote: >> Created a test that validates various Nodes can be initialized in a background thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 732: > 730: private void test(Supplier generator, Consumer operation) { > 731: AtomicReference ref = new AtomicReference(); > 732: runAndWait(() -> { What was the rationale for this change? This means we are no longer testing the ability to construct a node off thread. Related to this, I think a separate set of tests where we construct instances of the node in a loop would be useful, in addition to the set of tests that mutates the node in a loop. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1937983747 From kcr at openjdk.org Fri Jan 31 21:42:01 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 31 Jan 2025 21:42:01 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 21:09:12 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 732: > >> 730: private void test(Supplier generator, Consumer operation) { >> 731: AtomicReference ref = new AtomicReference(); >> 732: runAndWait(() -> { > > What was the rationale for this change? This means we are no longer testing the ability to construct a node off thread. > > Related to this, I think a separate set of tests where we construct instances of the node in a loop would be useful, in addition to the set of tests that mutates the node in a loop. I think this change is why the Tooltip test is no longer failing. The failure mode reported in [JDK-8348100](https://bugs.openjdk.org/browse/JDK-8348100) happens when constructing Tooltip on a background thread. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1938010321 From angorya at openjdk.org Fri Jan 31 23:06:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 23:06:49 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 21:39:12 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationBackgroundThreadTest.java line 732: >> >>> 730: private void test(Supplier generator, Consumer operation) { >>> 731: AtomicReference ref = new AtomicReference(); >>> 732: runAndWait(() -> { >> >> What was the rationale for this change? This means we are no longer testing the ability to construct a node off thread. >> >> Related to this, I think a separate set of tests where we construct instances of the node in a loop would be useful, in addition to the set of tests that mutates the node in a loop. > > I think this change is why the Tooltip test is no longer failing. The failure mode reported in [JDK-8348100](https://bugs.openjdk.org/browse/JDK-8348100) happens when constructing Tooltip on a background thread. The very first (visible) node should be created in the FX application thread (something I missed earlier). All other instances are created in the background thread - notice the second call to `generator.get()` inside the background thread lambda. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1938072166 From angorya at openjdk.org Fri Jan 31 23:06:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 23:06:50 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 23:02:35 GMT, Andy Goryachev wrote: >> I think this change is why the Tooltip test is no longer failing. The failure mode reported in [JDK-8348100](https://bugs.openjdk.org/browse/JDK-8348100) happens when constructing Tooltip on a background thread. > > The very first (visible) node should be created in the FX application thread (something I missed earlier). All other instances are created in the background thread - notice the second call to `generator.get()` inside the background thread lambda. > Related to this, I think a separate set of tests where we construct instances of the node in a loop would be useful, in addition to the set of tests that mutates the node in a loop. this is a good idea! thank you. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1938073217 From angorya at openjdk.org Fri Jan 31 23:25:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 23:25:32 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v3] In-Reply-To: References: Message-ID: > Created a test that validates various Nodes can be initialized in a background thread. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: fast loop ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/d1356dce..e0b30334 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=01-02 Stats: 38 lines in 1 file changed: 36 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1690.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1690/head:pull/1690 PR: https://git.openjdk.org/jfx/pull/1690 From angorya at openjdk.org Fri Jan 31 23:28:09 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 31 Jan 2025 23:28:09 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: Message-ID: > Created a test that validates various Nodes can be initialized in a background thread. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: better name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/e0b30334..3fde5133 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1690.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1690/head:pull/1690 PR: https://git.openjdk.org/jfx/pull/1690 From mstrauss at openjdk.org Fri Jan 31 23:31:58 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 31 Jan 2025 23:31:58 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs 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: On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # 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 (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... @hjohn I missed that you addressed my review comment about the removal of the `latestValueTracker` field. This concludes my review, so if you re-open this PR, I'll approve. ------------- PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-2588049698