From mstrauss at openjdk.org Sat Feb 1 07:20:15 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 1 Feb 2025 07:20:15 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v44] 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: added StageTester to MonkeyTester ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/3efd7827..cadf1c2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=43 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=42-43 Stats: 546 lines in 4 files changed: 276 ins; 267 del; 3 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 jhendrikx at openjdk.org Sat Feb 1 12:05:59 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 1 Feb 2025 12:05:59 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 25 Mar 2024 13:32:11 GMT, Michael Strau? 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... > > `ListenerManager` is an obvious improvement, as it fixes incorrect behavior and allows listeners to veto changes. However, the behavior of `ListenerManager` is also an implementation detail and not documented anywhere. This leads me to the following questions: > > 1. How will users know that they can now do all of the things that were previously broken? Do we need a specification for what is allowed and what's not allowed? > 2. Should this behavior be required for all valid `ObservableValue` implementations? (This would render many existing implementations defective.) > 3. If `ObservableValue` implementations are not required to replicate the `ListenerManager` behavior, we should probably make it easily discoverable whether any particular implementation (most of them are properties) supports nested changes/vetoing. In most of the public API, there's no obvious way to see (without looking at the source code) whether a property implementation extends one of the `*PropertyBase` classes. @mstr2 thanks for taking a look again, I didn't realize you were waiting specifically for that change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2628925057 From jhendrikx at openjdk.org Sat Feb 1 12:09:38 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 1 Feb 2025 12:09:38 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v2] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # 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... John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Merge branch 'openjdk:master' into feature/nested-emission-with-correct-old-values - Merge remote-tracking branch 'upstream/master' into feature/nested-emission-with-correct-old-values - Fix generic warnings - Fix merge - Merge remote-tracking branch 'upstream/master' into feature/nested-emission-with-correct-old-values - Prevent removal of weak listeners during unlock - Use an overridable method to store latest value - Merge the recursive notification loop code Made loop in ListenerList slightly more generic to allow merging the logic in OldValueCachingListenerList and ListenerList; performance impact seems minimal - Small bug fix in OldValueCachingListenerList - Added a test case to detect and avoid this problem - Improve doc - ... and 18 more: https://git.openjdk.org/jfx/compare/e0c73f6a...bc4e80db ------------- Changes: https://git.openjdk.org/jfx/pull/1081/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=01 Stats: 4358 lines in 39 files changed: 4195 ins; 7 del; 156 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Sat Feb 1 12:22:54 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 1 Feb 2025 12:22:54 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v2] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 17 Oct 2023 05:16:23 GMT, Michael Strau? wrote: >> Thanks, I'll look into that, it might speed up the 1 listener cases a bit. The same applies to OldValueCachingListenerManager#getValue I think. I know it isn't possible for the add/remove calls, as the data may change if they're nested, but for `fireValueChanged` I never really checked after going to this strategy. > > Have you considered passing `data` directly into the method? What is your conclusion? It almost has to work, considering the `getData` call is done immediately after the `fireValueChanged` call :) I'll make the changes and run some tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1938266146 From jhendrikx at openjdk.org Sat Feb 1 12:57:34 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 1 Feb 2025 12:57:34 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # 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... John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: - Clean-up and add tests - Pass in listener data directly for fireValueChanged calls - Fix documentation in a few places - Remove unused interface - Update copyrights and add missing ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/bc4e80db..139c2aa4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=01-02 Stats: 310 lines in 39 files changed: 189 ins; 36 del; 85 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From kcr at openjdk.org Sat Feb 1 14:53:54 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 1 Feb 2025 14:53:54 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing I'll put this back on my review queue. It would be good to get this in. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2628982209 From mstrauss at openjdk.org Sat Feb 1 17:19:55 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 1 Feb 2025 17:19:55 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing Marked as reviewed by mstrauss (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-2588370947 From lkostyra at openjdk.org Mon Feb 3 10:13:57 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 3 Feb 2025 10:13:57 GMT Subject: RFR: 8349008: Remove temporary font file tracking code In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 15:50:08 GMT, Andy Goryachev 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 Oh I did miss that file didn't I... I think it's time to make a pre-commit hook or something to take care of that for me ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1693#discussion_r1939119217 From lkostyra at openjdk.org Mon Feb 3 10:18:30 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 3 Feb 2025 10:18:30 GMT Subject: RFR: 8349008: Remove temporary font file tracking code [v2] In-Reply-To: References: 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. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: PrismFontFactory review fixes - Updated copyright header year - Fixed comment mentioning tracker ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1693/files - new: https://git.openjdk.org/jfx/pull/1693/files/27d8f8f9..61c51bb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1693&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1693&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 Mon Feb 3 13:37:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 13:37:52 GMT Subject: RFR: 8349008: Remove temporary font file tracking code [v2] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 10:18:30 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. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > PrismFontFactory review fixes > > - Updated copyright header year > - Fixed comment mentioning tracker Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1693#pullrequestreview-2589926704 From mstrauss at openjdk.org Mon Feb 3 14:33:43 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 3 Feb 2025 14:33:43 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] 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: macOS bugfixes, default button behavior ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/cadf1c2c..600c721b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=44 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=43-44 Stats: 217 lines in 9 files changed: 184 ins; 11 del; 22 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 Feb 3 15:11:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 15:11:54 GMT Subject: RFR: 8349008: Remove temporary font file tracking code [v2] In-Reply-To: References: Message-ID: <2I1djX2rURtMtW9nQCb6d3UuObdp8P0OyFrHQvx1lQQ=.e4fa4988-991e-48de-b282-4bf88d90ba8d@github.com> On Mon, 3 Feb 2025 10:18:30 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. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > PrismFontFactory review fixes > > - Updated copyright header year > - Fixed comment mentioning tracker Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1693#pullrequestreview-2590212996 From kcr at openjdk.org Mon Feb 3 17:21:55 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 17:21:55 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 23:28:09 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: > > better name I left a couple comments. Regarding the tooltip issue, I was able to make it fail reliably by doing two things: 1. When not on the FX app thread, create a new tooltip rather than using the one created in the generator 2. When on the FX app thread, alternate between moving the mouse onto / off of the control Like this: AtomicBoolean overTooltip = new AtomicBoolean(false); test(() -> { Tooltip t = new Tooltip("this is a tooltip"); t.setShowDelay(Duration.ZERO); t.setHideDelay(Duration.ZERO); Label c = new Label("testing tooltip"); c.setSkin(new LabelSkin(c)); c.setTooltip(t); c.setId("Tooltip"); return c; }, (c) -> { Tooltip t; if (Platform.isFxApplicationThread()) { t = c.getTooltip(); } else { t = new Tooltip("this is a tooltip"); } t.isShowing(); t.setGraphic(new Label("yo!")); if (Platform.isFxApplicationThread()) { boolean isOverTooltip = overTooltip.get(); Point2D p = isOverTooltip ? c.localToScreen(c.getWidth() + 5.0, c.getHeight() + 5.0) : c.localToScreen(c.getWidth() / 2.0, c.getHeight() / 2.0); robot.mouseMove(p); overTooltip.set(!isOverTooltip); } }); Feel free to use / adapt / whatever this suggestion. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 158: > 156: private static final AtomicLong seq = new AtomicLong(); > 157: private static final AtomicBoolean failed = new AtomicBoolean(); > 158: // for debugging purposes: setting this to false will skip working tests That should be "setting this to _true_ will skip..." tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 671: > 669: return c; > 670: }, (c) -> { > 671: Tooltip t = c.getTooltip(); For the background thread, construct a new object. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 675: > 673: t.setGraphic(new Label("yo!")); > 674: if (Platform.isFxApplicationThread()) { > 675: Point2D p = c.localToScreen(c.getWidth() / 2.0, c.getHeight() / 2.0); In order to reliably reproduce it with the manual test, I had to move the mouse off and on the tooltip (so the tooltip is shown / hidden repeatedly). You can do that here by alternately moving the mouse to the center (as you've done here) and outside the window. ------------- PR Review: https://git.openjdk.org/jfx/pull/1690#pullrequestreview-2590460238 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939696702 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939738534 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939744593 From kcr at openjdk.org Mon Feb 3 17:21:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 17:21:56 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:03:54 GMT, Andy Goryachev wrote: >> 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. > 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. Ah, I see that now (I had missed seeing the second call). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939699573 From kcr at openjdk.org Mon Feb 3 17:21:57 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 17:21:57 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> References: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> Message-ID: On Fri, 31 Jan 2025 20:07:11 GMT, Kevin Rushforth wrote: >> 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. Actually, in looking at this further, I wanted to suggest an alternative approach. Rather than having each background thread poke the application thread to run a test loop every 100 test loops of that background thread, you might consider having one additional thread whose job it is to periodically run a test loop on the app thread. With the current approach, it is likely running an app thread loop far more often than wanted for two reasons: 1. The background threads are (intentionally) free running rather than being tied to a frame or even a small sleep 2. Each background thread independently fires an FX app pass every 100 passes, meaning that if there are 20 threads, it will effectively run every 5 passes of a background thread (every 100 passes will queue up 20 calls to run a pass on the FX app thread) Having a dedicated test thread for testing on the FX app thread would allow to control its frequency independent of the background threads. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939701668 From angorya at openjdk.org Mon Feb 3 17:37:02 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 17:37:02 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> Message-ID: On Mon, 3 Feb 2025 16:39:44 GMT, Kevin Rushforth wrote: >> 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. > > Actually, in looking at this further, I wanted to suggest an alternative approach. Rather than having each background thread poke the application thread to run a test loop every 100 test loops of that background thread, you might consider having one additional thread whose job it is to periodically run a test loop on the app thread. With the current approach, it is likely running an app thread loop far more often than wanted for two reasons: > > 1. The background threads are (intentionally) free running rather than being tied to a frame or even a small sleep > 2. Each background thread independently fires an FX app pass every 100 passes, meaning that if there are 20 threads, it will effectively run every 5 passes of a background thread (every 100 passes will queue up 20 calls to run a pass on the FX app thread) > > Having a dedicated test thread for testing on the FX app thread would allow to control its frequency independent of the background threads. > > What do you think? I like it. Also, I think we may want to add a bit of randomness to the process - in the "jiggler" thread, as well as to tests themselves. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939775820 From angorya at openjdk.org Mon Feb 3 17:46:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 17:46:06 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 23:28:09 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: > > better name Re: tooltip issue: I was able to modify the test to reproduce the issue reliably (thanks for earlier suggestion to create tooltips in a tight loop). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2631648326 From kcr at openjdk.org Mon Feb 3 17:46:06 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 17:46:06 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 17:37:17 GMT, Andy Goryachev wrote: > Re: tooltip issue: I was able to modify the test to reproduce the issue reliably (thanks for earlier suggestion to create tooltips in a tight loop). Good to know. On Windows, I could only get it to fail by also moving the mouse on / off the tooltip I commented on above. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2631652125 From kcr at openjdk.org Mon Feb 3 17:46:07 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 17:46:07 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> Message-ID: On Mon, 3 Feb 2025 17:34:05 GMT, Andy Goryachev wrote: >> Actually, in looking at this further, I wanted to suggest an alternative approach. Rather than having each background thread poke the application thread to run a test loop every 100 test loops of that background thread, you might consider having one additional thread whose job it is to periodically run a test loop on the app thread. With the current approach, it is likely running an app thread loop far more often than wanted for two reasons: >> >> 1. The background threads are (intentionally) free running rather than being tied to a frame or even a small sleep >> 2. Each background thread independently fires an FX app pass every 100 passes, meaning that if there are 20 threads, it will effectively run every 5 passes of a background thread (every 100 passes will queue up 20 calls to run a pass on the FX app thread) >> >> Having a dedicated test thread for testing on the FX app thread would allow to control its frequency independent of the background threads. >> >> What do you think? > > I like it. > > Also, I think we may want to add a bit of randomness to the process - in the "jiggler" thread, as well as to tests themselves. A bit of randomness in the "jiggler" thread seems good. Not sure about adding more randomness in the tests -- maybe, but having them free running (rather than sleeping) is probably more stressful. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939784740 From angorya at openjdk.org Mon Feb 3 17:46:07 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 17:46:07 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> Message-ID: On Mon, 3 Feb 2025 17:41:21 GMT, Kevin Rushforth wrote: >> I like it. >> >> Also, I think we may want to add a bit of randomness to the process - in the "jiggler" thread, as well as to tests themselves. > > A bit of randomness in the "jiggler" thread seems good. Not sure about adding more randomness in the tests -- maybe, but having them free running (rather than sleeping) is probably more stressful. in some cases the animation and transitions are getting involved, which might uncover additional issues. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939787610 From kcr at openjdk.org Mon Feb 3 17:55:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 3 Feb 2025 17:55:59 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: <9xG_hIlJwD6mdvjZsr2VATGmHfvxTDQwzfBHvtsZksA=.92bed3dc-5901-4f94-9f17-0ed5a57204c6@github.com> Message-ID: On Mon, 3 Feb 2025 17:43:40 GMT, Andy Goryachev wrote: >> A bit of randomness in the "jiggler" thread seems good. Not sure about adding more randomness in the tests -- maybe, but having them free running (rather than sleeping) is probably more stressful. > > in some cases the animation and transitions are getting involved, which might uncover additional issues. That makes sense. Worth noting it that the animation and transitions only run on the app thread (although they can be started on any thread). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939799872 From lkostyra at openjdk.org Mon Feb 3 17:58:55 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 3 Feb 2025 17:58:55 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 8a5e488a Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/8a5e488a5d76bd40a25488b1604d3f53e3d22be8 Stats: 218 lines in 9 files changed: 0 ins; 176 del; 42 mod 8349008: Remove temporary font file tracking code Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1693 From angorya at openjdk.org Mon Feb 3 18:13:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 18:13:16 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v5] 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: jiggler ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/3fde5133..a05d3910 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=03-04 Stats: 71 lines in 1 file changed: 29 ins; 29 del; 13 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 Mon Feb 3 18:19:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 18:19:58 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v4] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 17:05:14 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> better name > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 671: > >> 669: return c; >> 670: }, (c) -> { >> 671: Tooltip t = c.getTooltip(); > > For the background thread, construct a new object. I am going to address the tooltip issue in a different PR so as not to prolong the review process... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1939827255 From angorya at openjdk.org Mon Feb 3 19:07:46 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 19:07:46 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v6] In-Reply-To: References: Message-ID: <8Gq-7IrerVLH3ux5ZLRTYW9veLnWr144fbFAFO0Byfw=.694850ed-10ea-4776-9c94-ece1a8cb7cbb@github.com> > 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: skip tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/a05d3910..e25f6f6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=04-05 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 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 Mon Feb 3 19:11:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 19:11:38 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v7] 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 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 12 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - jiggler - better name - fast loop - review comments - cleanup - pagination - thread count - all controls - ... and 2 more: https://git.openjdk.org/jfx/compare/14786ee5...597e39d3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/e25f6f6c..597e39d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=05-06 Stats: 244 lines in 11 files changed: 20 ins; 176 del; 48 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 Mon Feb 3 19:53:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 19:53:42 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v7] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 19:11:38 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 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - skip tests > - jiggler > - better name > - fast loop > - review comments > - cleanup > - pagination > - thread count > - all controls > - ... and 2 more: https://git.openjdk.org/jfx/compare/bf49b606...597e39d3 Created https://bugs.openjdk.org/browse/JDK-8349257 for any improvements to the existing tests and also to add the remaining Node classes (shapes etc.) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2631912710 From angorya at openjdk.org Mon Feb 3 21:47:11 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 21:47:11 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: References: Message-ID: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> > 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: more jitter ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/597e39d3..30700a69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=06-07 Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 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 Mon Feb 3 23:41:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 23:41:19 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 14:33:43 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: > > macOS bugfixes, default button behavior modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 41: > 39: import java.util.Optional; > 40: > 41: public final class HeaderButtonBehavior implements EventHandler { it might be better to call this class other than "behavior", "handler" perhaps? mouse handler? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1940273105 From angorya at openjdk.org Mon Feb 3 23:46:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 23:46:20 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 14:33:43 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: > > macOS bugfixes, default button behavior modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 88: > 86: stage.setMaximized(!stage.isMaximized()); > 87: } > 88: }); I think it might be better to add a default case here, _in case this enum evolves_. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1940277610 From angorya at openjdk.org Mon Feb 3 23:50:24 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 3 Feb 2025 23:50:24 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 14:33:43 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: > > macOS bugfixes, default button behavior tests/manual/monkey/src/com/oracle/tools/fx/monkey/MainWindow.java line 157: > 155: FX.item(m, orientation); > 156: FX.separator(m); > 157: FX.item(m, "Stage Tester", this::openStageTesterWindow); should this menu item be moved under "Tools"? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1940280164 From kcr at openjdk.org Tue Feb 4 01:03:22 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 01:03:22 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 23:43:47 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> macOS bugfixes, default button behavior > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 88: > >> 86: stage.setMaximized(!stage.isMaximized()); >> 87: } >> 88: }); > > I think it might be better to add a default case here, _in case this enum evolves_. Why? This isn't some external enum that might evolve out from under this code, but is part of the same feature. If the enum evolves then the resulting compiler error is a _good_ thing as it alerts whoever added the new enum that they didn't finish implementing it. A default makes sense when the enum might evolve separately from the use of the enum. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1940334817 From ambarish.rapte at oracle.com Tue Feb 4 05:48:50 2025 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 4 Feb 2025 05:48:50 +0000 Subject: [External] : Re: JavaFX Metal: First EA build available for Testing In-Reply-To: <473a4a52-e1b5-4f67-8587-d707500d002f@xpipe.io> References: <473a4a52-e1b5-4f67-8587-d707500d002f@xpipe.io> Message-ID: Hello Christopher, Thank you for trying out the EA build and sharing your feedback. It's great to hear that no significant issues have been observed. Could you please provide more details about the color difference issue? If possible - a reproducer program, screenshots (from both the EA build and the regular JavaFX build you use), and system information would be very helpful. You can update this information on https://bugs.openjdk.org/browse/JDK-8331413 Regards, Ambarish From: Christopher Schnick Date: Tuesday, 28 January 2025 at 20:08 To: Ambarish Rapte Cc: openjfx-dev at openjdk.org Subject: [External] : Re: JavaFX Metal: First EA build available for Testing 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: - 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 mhanl at openjdk.org Tue Feb 4 08:38:21 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 4 Feb 2025 08:38:21 GMT Subject: Integrated: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 16:32:49 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-8276326](https://bugs.openjdk.org... This pull request has now been integrated. Changeset: 1b12c8a4 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/1b12c8a490a87691e7e815a7e768854354cb54aa Stats: 1425 lines in 15 files changed: 1245 ins; 142 del; 38 mod 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction 8276326: Empty Cells in TableView supposedly after using setFixedCellSize() 8252566: TreeTableView: broken row layout for fixedCellSize 8346824: Collapsing tree view causes rendering issues Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1644 From mhanl at openjdk.org Tue Feb 4 08:53:20 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 4 Feb 2025 08:53:20 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v2] In-Reply-To: References: Message-ID: <0wEyW_nZiJr2zvfYsQ3bCD0pltWdIjRZsSOdV4huDFA=.731f76d2-1725-41cb-90f7-da3cdafe63ea@github.com> On Wed, 29 Jan 2025 19:01:40 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. > > 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/e1000640...5010278f modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2704: > 2702: private static double toViewPortLength(double prefHeight) { > 2703: // it would be better to calculate this from listView but there is no API for this > 2704: return prefHeight - 2; I think after this node is inside the scene tree and has a skin, you can just calculate that with: `prefHeight(-1) - snappedTopInset() - snappedBottomInset()`. Something like that I already used. Also, `Viewport` is one word, so should not be camel case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1940746119 From mhanl at openjdk.org Tue Feb 4 08:56:18 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 4 Feb 2025 08:56:18 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v2] In-Reply-To: References: Message-ID: <6Oo6L7G6zNL6cNZX-MOMVJI1Dz_er60aj5euXudRBLw=.b57e4f58-c3c7-4ad4-ade2-0ca402fa4b34@github.com> On Wed, 29 Jan 2025 19:01:40 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. > > 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/adaadda0...5010278f I think this is a good change, completely utilizing that the text layout code is abstracted away for good. Changes look good to me so far. Some tests are hard to understand the changes, but that is a preexisting problem (especially if the name of the test is just `rt_xxxx`). Not sure about the code style of using `S`, `M` or `L` as variable names (minor), so I will see what other reviewers say about this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2633256559 From mstrauss at openjdk.org Tue Feb 4 12:15:24 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 12:15:24 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 23:38:30 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> macOS bugfixes, default button behavior > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 41: > >> 39: import java.util.Optional; >> 40: >> 41: public final class HeaderButtonBehavior implements EventHandler { > > it might be better to call this class other than "behavior", "handler" perhaps? mouse handler? It's a bit more than just a generic handler, it basically encapsulates the entire behavior of a window button (including setting its visibility and disabled states). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1941053806 From mstrauss at openjdk.org Tue Feb 4 12:22:43 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 12:22:43 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v46] 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: move StageTester to Tools menu ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/600c721b..7cb591fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=45 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=44-45 Stats: 5 lines in 2 files changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Tue Feb 4 12:41:24 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 12:41:24 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] 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: add "maximized" pseudo-class for custom maximize button ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/7cb591fa..c30eb603 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=46 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=45-46 Stats: 37 lines in 3 files changed: 28 ins; 0 del; 9 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 Feb 4 13:02:27 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 13:02:27 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v45] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 12:12:31 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 41: >> >>> 39: import java.util.Optional; >>> 40: >>> 41: public final class HeaderButtonBehavior implements EventHandler { >> >> it might be better to call this class other than "behavior", "handler" perhaps? mouse handler? > > It's a bit more than just a generic handler, it basically encapsulates the entire behavior of a window button (including setting its visibility and disabled states). We generally use "Behavior" in the context of controls. Although not wrong, I also think another name might be better. Maybe "Controller"? Or "Manager"? Or ... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1941120150 From kcr at openjdk.org Tue Feb 4 13:19:24 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 13:19:24 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 12:41: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 incrementally with one additional commit since the last revision: > > add "maximized" pseudo-class for custom maximize button It looks like this is shaping up nicely. I'll put this on my review queue. One thing I wanted to raise is that there are a few new concepts here as well as a reasonably large API surface. This feature seems like a good candidate to release as a Preview Feature (*) to get more feedback on the API before finalizing it. That would mean reviving your [Preview Feature JEP / Draft PR](https://github.com/openjdk/jfx/pull/1359), which you had also mentioned as something to consider in your initial Description of this PR. Do you have any thoughts on this? (*) - It can't be an incubator module (at least not without doing something unnatural like creating a subclass of Stage, and that might not even work), since the new API elements and implementation are necessarily in the `javafx.graphics module`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2633879403 From duke at openjdk.org Tue Feb 4 14:41:06 2025 From: duke at openjdk.org (Ziad El Midaoui) Date: Tue, 4 Feb 2025 14:41:06 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception Message-ID: When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. Also added tests to test this new fix ------------- Commit messages: - Fixed TextInputControl binding prompt with linebreaks and added tests Changes: https://git.openjdk.org/jfx/pull/1694/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335587 Stats: 42 lines in 2 files changed: 37 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1694.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1694/head:pull/1694 PR: https://git.openjdk.org/jfx/pull/1694 From mstrauss at openjdk.org Tue Feb 4 15:16:16 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 15:16:16 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception In-Reply-To: References: Message-ID: <2muaK1yWJPzefHm5QDjd5Xgyy6oSbDRrjp2pXIb5b70=.46d153d5-6b52-4df4-9f7d-019483f04238@github.com> On Tue, 4 Feb 2025 14:11:00 GMT, Ziad El Midaoui wrote: > When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. > Also added tests to test this new fix In my opinion, both the original implementation, as well as the proposed fix, are defective. The implementation seems to try to enforce the (undocumented) invariant that the prompt text cannot contain line breaks. If that is indeed a sensible invariant, then the property should reject any attempt to set an invalid value by throwing an exception. Silently changing the property value is unexpected for developers. However, it doesn't seem to me that this is a sensible invariant. `TextFieldSkin` and `TextAreaSkin` render the prompt text with a `Text` node, which doesn't have a single-line restriction. Simply not doing anything to the prompt text would be a good choice. Another good choice would be to clean up the prompt text where it is used (i.e. in `TextFieldSkin` and `TextAreaSkin`). We already do this in other places, for example in `LabeledSkinBase::getCleanText`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1694#issuecomment-2634274218 From angorya at openjdk.org Tue Feb 4 15:27:27 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 15:27:27 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 12:41: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 incrementally with one additional commit since the last revision: > > add "maximized" pseudo-class for custom maximize button +1 for the preview idea ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2634306045 From angorya at openjdk.org Tue Feb 4 15:52:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 15:52:15 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 14:11:00 GMT, Ziad El Midaoui wrote: > When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. > Also added tests to test this new fix modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 323: > 321: if (txt != null && txt.contains("\n")) { > 322: txt = txt.replace("\n", ""); > 323: if(isBound()){ minor: try to match the existing formatting: `if (isBound()) {` (space after `if` and before `{`) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1694#discussion_r1941433595 From mstrauss at openjdk.org Tue Feb 4 15:57:29 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 15:57:29 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 12:41: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 incrementally with one additional commit since the last revision: > > add "maximized" pseudo-class for custom maximize button I also think that this should be a preview feature. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2634388150 From angorya at openjdk.org Tue Feb 4 16:04:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 16:04:19 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception In-Reply-To: <2muaK1yWJPzefHm5QDjd5Xgyy6oSbDRrjp2pXIb5b70=.46d153d5-6b52-4df4-9f7d-019483f04238@github.com> References: <2muaK1yWJPzefHm5QDjd5Xgyy6oSbDRrjp2pXIb5b70=.46d153d5-6b52-4df4-9f7d-019483f04238@github.com> Message-ID: <0ZKvEY-V9WSV7oLGE40ss3RlpH7Ic8Gu8c2pLjW3yMY=.3893c829-bcbd-4fd3-9bc9-cd1ffdb66dae@github.com> On Tue, 4 Feb 2025 15:13:31 GMT, Michael Strau? wrote: >> When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. >> Also added tests to test this new fix > > In my opinion, both the original implementation, as well as the proposed fix, are defective. > > The implementation seems to try to enforce the (undocumented) invariant that the prompt text cannot contain line breaks. If that is indeed a sensible invariant, then the property should reject any attempt to set an invalid value by throwing an exception. Silently changing the property value is unexpected for developers. > > However, it doesn't seem to me that this is a sensible invariant. `TextFieldSkin` and `TextAreaSkin` render the prompt text with a `Text` node, which doesn't have a single-line restriction. Simply not doing anything to the prompt text would be a good choice. Another good choice would be to clean up the prompt text where it is used (i.e. in `TextFieldSkin` and `TextAreaSkin`). We already do this in other places, for example in `LabeledSkinBase::getCleanText`. @mstr2 you bring a good point: the behavior (removing newlines) is undocumented, and it should be. I propose to do this in a separate issue, more specifically in https://bugs.openjdk.org/browse/JDK-8335547 which intends to remove the filtering for `TextArea` since that controls is capable of displaying multi-line prompts (and `TextField`/`PasswordField` are not) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1694#issuecomment-2634407246 From mstrauss at openjdk.org Tue Feb 4 16:07:26 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 16:07:26 GMT Subject: RFR: 8349373: Support JavaFX preview features Message-ID: This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. ------------- Commit messages: - Use enum constants instead of feature names - Merge branch 'master' into feature/previewfeature - Preview features Changes: https://git.openjdk.org/jfx/pull/1359/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349373 Stats: 124 lines in 2 files changed: 124 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1359.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1359/head:pull/1359 PR: https://git.openjdk.org/jfx/pull/1359 From angorya at openjdk.org Tue Feb 4 16:11:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 16:11:16 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v2] In-Reply-To: <6Oo6L7G6zNL6cNZX-MOMVJI1Dz_er60aj5euXudRBLw=.b57e4f58-c3c7-4ad4-ade2-0ca402fa4b34@github.com> References: <6Oo6L7G6zNL6cNZX-MOMVJI1Dz_er60aj5euXudRBLw=.b57e4f58-c3c7-4ad4-ade2-0ca402fa4b34@github.com> Message-ID: On Tue, 4 Feb 2025 08:53:31 GMT, Marius Hanl wrote: > `S`, `M` or `L` as variable names (minor) the meaning should be obvious from the context (small, medium, large) and I don't want code like this to take two pages: testScrollTo(360, 1, new Integer[] { S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S, S }); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2634428113 From mstrauss at openjdk.org Tue Feb 4 16:18:16 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 16:18:16 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception [v2] In-Reply-To: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> References: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> Message-ID: On Tue, 4 Feb 2025 16:01:03 GMT, Ziad El Midaoui wrote: >> When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. >> Also added tests to test this new fix > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in TextInputControl.java I guess I don't see the point of this particular ticket. This PR doesn't contain any useful change, because it is entirely subsumed in JDK-8335547. Why add code here and bother reviewers (even slightly), when the actual fix is to just remove the code? Even as an interim fix, it's mostly a waste of time for an issue that has existed for 13 years. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1694#issuecomment-2634447439 From angorya at openjdk.org Tue Feb 4 16:23:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 16:23:18 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception [v2] In-Reply-To: References: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> Message-ID: On Tue, 4 Feb 2025 16:15:48 GMT, Michael Strau? wrote: > the point of this particular ticket [NEW DRIVER. PLEASE BE PATIENT] ------------- PR Comment: https://git.openjdk.org/jfx/pull/1694#issuecomment-2634459921 From angorya at openjdk.org Tue Feb 4 18:00:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 18:00:40 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception [v2] In-Reply-To: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> References: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> Message-ID: On Tue, 4 Feb 2025 16:01:03 GMT, Ziad El Midaoui wrote: >> When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. >> Also added tests to test this new fix > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in TextInputControl.java Looks good in the MonkeyTester. Thank you for providing unit tests and especially covering a complete set of scenarios (from the applied logic standpoint): null, with, and without newlines. The fix is localized and well defined, so one reviewer is probably enough, but let's wait the prescribed time period (24h) to give other people a chance to take a look, especially @mstr2 :-) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1694#pullrequestreview-2593641273 From angorya at openjdk.org Tue Feb 4 18:22:34 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 18:22:34 GMT Subject: RFR: 8349373: Support JavaFX preview features In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 20:05:01 GMT, Michael Strau? wrote: > This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. PREVIEW-FEATURES.md line 1: > 1: # Preview features is this a good location of this document? should it be in /doc-files somewhere? PREVIEW-FEATURES.md line 32: > 30: application has not opted into the use of preview features. All preview features have equal status > 31: in any given JavaFX release and can not be enabled individually. > 32: do you want to talk about similarities and differences between this and jdk preview features https://openjdk.org/jeps/12 ? PREVIEW-FEATURES.md line 45: > 43: for the preview feature. This name will be used in warning and error messages when the preview feature > 44: is used by application developers. > 45: 4. Add runtime checks in appropriate places by invoking `com.sun.javafx.PreviewFeature..checkEnabled()`. what do you think about adding this checklist to the PreviewFeature class? possibly following by an example (to allow for copy-paste)? modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 37: > 35: * has opted into preview features. > 36: */ > 37: public enum PreviewFeature { Why enum? Maybe use a regular class with a public constructor should do it. What do you think? modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 78: > 76: } > 77: > 78: private final String featureName; would it be possible to move field to the beginning of the class please? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941678440 PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941685598 PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941683672 PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941689779 PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941690914 From jvos at openjdk.org Tue Feb 4 18:22:29 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Feb 2025 18:22:29 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 @jperedadnr Can you review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2634735115 From angorya at openjdk.org Tue Feb 4 18:41:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 18:41:19 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v3] 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 21 additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout - atomic boolean - Merge branch 'master' into 8342565.stub.text.layout - cleanup - better test - cleanup - more magic - magic numbers - more - ... and 11 more: https://git.openjdk.org/jfx/compare/2598a462...b1042820 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1667/files - new: https://git.openjdk.org/jfx/pull/1667/files/5010278f..b1042820 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=01-02 Stats: 1671 lines in 27 files changed: 1265 ins; 318 del; 88 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 Tue Feb 4 18:41:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 18:41:20 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v2] In-Reply-To: <0wEyW_nZiJr2zvfYsQ3bCD0pltWdIjRZsSOdV4huDFA=.731f76d2-1725-41cb-90f7-da3cdafe63ea@github.com> References: <0wEyW_nZiJr2zvfYsQ3bCD0pltWdIjRZsSOdV4huDFA=.731f76d2-1725-41cb-90f7-da3cdafe63ea@github.com> Message-ID: On Tue, 4 Feb 2025 08:50:43 GMT, Marius Hanl wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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/2b26b7b8...5010278f > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2704: > >> 2702: private static double toViewPortLength(double prefHeight) { >> 2703: // it would be better to calculate this from listView but there is no API for this >> 2704: return prefHeight - 2; > > I think after this node is inside the scene tree and has a skin, you can just calculate that with: > `prefHeight(-1) - snappedTopInset() - snappedBottomInset()`. > Something like that I already used. > > Also, `Viewport` is one word, so should not be camel case. using `prefHeight(-1) - snappedTopInset() - snappedBottomInset()` breaks the original test, I'd rather avoid that (all I did was minor refactoring to move the logic and the comment into one place). thanks for -> `toViewportLength()` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1941711373 From mstrauss at openjdk.org Tue Feb 4 18:44:19 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 18:44:19 GMT Subject: RFR: 8349373: Support JavaFX preview features In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 18:16:22 GMT, Andy Goryachev wrote: >> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. > > PREVIEW-FEATURES.md line 32: > >> 30: application has not opted into the use of preview features. All preview features have equal status >> 31: in any given JavaFX release and can not be enabled individually. >> 32: > > do you want to talk about similarities and differences between this and jdk preview features https://openjdk.org/jeps/12 ? This definition is, as you point out, largely lifted from JEP 12. Aside from wording changes, here are some key differences: * JEP 12 assumes that a feature should be finished within two releases. I think for JavaFX, being just a framework and not a programming language, it is sensible to assume that we can finish features in the next release; that is, a preview feature that is introduced in JavaFX N should be finished in N+1. * JEP 12 says that a preview feature should be at least 95% "done". I think we can be a little bit more risk-tolerant here, which is why I lowered this number to 90% "done". The general idea is that preview features in JavaFX should be faster and accept a little bit more risk than preview features in the JDK. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941716692 From angorya at openjdk.org Tue Feb 4 18:47:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 18:47:18 GMT Subject: RFR: 8349373: Support JavaFX preview features In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 18:41:13 GMT, Michael Strau? wrote: >> PREVIEW-FEATURES.md line 32: >> >>> 30: application has not opted into the use of preview features. All preview features have equal status >>> 31: in any given JavaFX release and can not be enabled individually. >>> 32: >> >> do you want to talk about similarities and differences between this and jdk preview features https://openjdk.org/jeps/12 ? > > This definition is, as you point out, largely lifted from JEP 12. Aside from wording changes, here are some key differences: > > * JEP 12 assumes that a feature should be finished within two releases. I think for JavaFX, being just a framework and not a programming language, it is sensible to assume that we can finish features in the next release; that is, a preview feature that is introduced in JavaFX N should be finished in N+1. > * JEP 12 says that a preview feature should be at least 95% "done". I think we can be a little bit more risk-tolerant here, which is why I lowered this number to 90% "done". > > The general idea is that preview features in JavaFX should be faster and accept a little bit more risk than preview features in the JDK. The space of people who know what a JDK preview is is larger than that of JFX people. I think we might want to point to JEP12 and explicitly explain the difference, that's all. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941721364 From angorya at openjdk.org Tue Feb 4 19:11:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 19:11:32 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 12:41: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 incrementally with one additional commit since the last revision: > > add "maximized" pseudo-class for custom maximize button I like the buttons in the content area of the test stage in the monkey tester! Do you mind if I eventually move the changes to the "Stage" page? ![Screenshot 2025-02-04 at 11 06 43](https://github.com/user-attachments/assets/07d32b46-04ba-452e-aab2-65974bef64f4) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2634831936 From mstrauss at openjdk.org Tue Feb 4 19:28:23 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 19:28:23 GMT Subject: RFR: 8349373: Support JavaFX preview features In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 18:13:19 GMT, Andy Goryachev wrote: >> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. > > PREVIEW-FEATURES.md line 1: > >> 1: # Preview features > > is this a good location of this document? > should it be in /doc-files somewhere? I think it's not a documentation of JavaFX itself, but more like a meta-documentation like our contribution guidelines. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941773184 From mstrauss at openjdk.org Tue Feb 4 19:23:19 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 19:23:19 GMT Subject: RFR: 8349373: Support JavaFX preview features In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 18:44:57 GMT, Andy Goryachev wrote: >> This definition is, as you point out, largely lifted from JEP 12. Aside from wording changes, here are some key differences: >> >> * JEP 12 assumes that a feature should be finished within two releases. I think for JavaFX, being just a framework and not a programming language, it is sensible to assume that we can finish features in the next release; that is, a preview feature that is introduced in JavaFX N should be finished in N+1. >> * JEP 12 says that a preview feature should be at least 95% "done". I think we can be a little bit more risk-tolerant here, which is why I lowered this number to 90% "done". >> >> The general idea is that preview features in JavaFX should be faster and accept a little bit more risk than preview features in the JDK. > > The space of people who know what a JDK preview is is larger than that of JFX people. I think we might want to point to JEP12 and explicitly explain the difference, that's all. We could also do that, but the problem is that the contents of JEP 12 only map to JavaFX in some parts, but not in others. So we would need to include weasel language like "where applicable" (which always leaves a bit of room for interpretation), or provide what would basically be a detailed sentence-by-sentence diff. So in the end, it might still be easier to point at our own (complete) definition instead of a partially applicable definition somewhere else. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941767371 From mstrauss at openjdk.org Tue Feb 4 19:39:07 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 19:39:07 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: > This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: move enum field to top ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1359/files - new: https://git.openjdk.org/jfx/pull/1359/files/925875b8..2fa3560d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1359.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1359/head:pull/1359 PR: https://git.openjdk.org/jfx/pull/1359 From mstrauss at openjdk.org Tue Feb 4 19:39:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 19:39:08 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: <9wVtLftClqLG0suJ3WW_5hzXMwj3ITkXv1NPYaiu6a4=.91e2af0b-c3da-491c-8cb5-c89fa8cae05f@github.com> On Tue, 4 Feb 2025 18:18:31 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> move enum field to top > > modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 37: > >> 35: * has opted into preview features. >> 36: */ >> 37: public enum PreviewFeature { > > Why enum? > Maybe use a regular class with a public constructor should do it. > What do you think? The idea is to make it easy and obvious to use from preview code: PreviewFeature.MY_PREVIEW_FEATURE.checkEnabled(); In addition to that, any IDE can easily list all uses of an enum constant, which gives you an overview where APIs of a particular feature are located. After all, enums are just regular classes with singleton instances. By the way, preview features can't be individually enabled or disabled. The point of checking on a enum constant is to generate an appropriate error message (including the name of the feature) in case the user didn't enable preview features. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941783408 From angorya at openjdk.org Tue Feb 4 19:45:21 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 19:45:21 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: <9wVtLftClqLG0suJ3WW_5hzXMwj3ITkXv1NPYaiu6a4=.91e2af0b-c3da-491c-8cb5-c89fa8cae05f@github.com> References: <9wVtLftClqLG0suJ3WW_5hzXMwj3ITkXv1NPYaiu6a4=.91e2af0b-c3da-491c-8cb5-c89fa8cae05f@github.com> Message-ID: On Tue, 4 Feb 2025 19:34:29 GMT, Michael Strau? wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 37: >> >>> 35: * has opted into preview features. >>> 36: */ >>> 37: public enum PreviewFeature { >> >> Why enum? >> Maybe use a regular class with a public constructor should do it. >> What do you think? > > The idea is to make it easy and obvious to use from preview code: > > PreviewFeature.MY_PREVIEW_FEATURE.checkEnabled(); > > In addition to that, any IDE can easily list all uses of an enum constant, which gives you an overview where APIs of a particular feature are located. After all, enums are just regular classes with singleton instances. > > By the way, preview features can't be individually enabled or disabled. The point of checking on a enum constant is to generate an appropriate error message (including the name of the feature) in case the user didn't enable preview features. my only objection is that enum implies the use of a switch pattern, which is not really applicable here. since it's in com.sun.* hierarchy and only intended for jfx devs, I am fine with enum. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941790951 From mstrauss at openjdk.org Tue Feb 4 19:53:25 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Feb 2025 19:53:25 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: <8wdsY39DgA7lUTIj2knA1W4_smb8oMZh_IlK8QWePwU=.22fa2c83-5741-4be4-8b8c-a97f4199a17c@github.com> On Tue, 4 Feb 2025 19:08:22 GMT, Andy Goryachev wrote: > Do you mind if I eventually move the changes to the "Stage" page? Sure, do that. It might be prudent to wait for the API in this PR to stabilize, though. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2634922394 From kcr at openjdk.org Tue Feb 4 20:23:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 20:23:21 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:20:47 GMT, Michael Strau? wrote: >> The space of people who know what a JDK preview is is larger than that of JFX people. I think we might want to point to JEP12 and explicitly explain the difference, that's all. > > We could also do that, but the problem is that the contents of JEP 12 only map to JavaFX in some parts, but not in others. So we would need to include weasel language like "where applicable" (which always leaves a bit of room for interpretation), or provide what would basically be a detailed sentence-by-sentence diff. > > So in the end, it might still be easier to point at our own (complete) definition instead of a partially applicable definition somewhere else. Andy's suggestion matches what I did for [Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). This idea being that, given familiarity with the JDK concept (with a pointer to where you can read more about that), how are JavaFX Preview Features different? 90% vs 95%, lack of javac support, we use a property rather than a dedicated command line option, etc. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941798119 From kcr at openjdk.org Tue Feb 4 20:23:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 20:23:21 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: <4xH9qqYHVSDUjHc_ytpkMUGKXxnVK4PC7IUhtX4BKN8=.a02469e8-10e5-4692-9998-345749fdaf96@github.com> On Tue, 4 Feb 2025 19:25:40 GMT, Michael Strau? wrote: >> PREVIEW-FEATURES.md line 1: >> >>> 1: # Preview features >> >> is this a good location of this document? >> should it be in /doc-files somewhere? > > I think it's not a documentation of JavaFX itself, but more like a meta-documentation like our contribution guidelines. We haven't (yet) formalized a home for JEPs, so it should probably be moved into a separate branch (and Draft PR) for now as supporting material, which is what I did for Incubator Modules: [JEP](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md), [Draft PR](https://github.com/openjdk/jfx/pull/1617). This reminds me that we really do need to formalize where we store JEPs. I'll start a thread on that on the mailing list soon (I hope later this week or early next). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941797735 From kcr at openjdk.org Tue Feb 4 20:23:20 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 20:23:20 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:39:07 GMT, Michael Strau? wrote: >> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > move enum field to top Overall, I like the direction of this. This isn't a review (yet), but just a few high-level comments (I also left a couple inline comments). As with Incubating Modules, the goal is to provide features that are not yet final, and are able to evolve before being finalized. To achieve this without surprising application developers and end users, we need to provide tools to allow developers and end users to know that they are using preview features that might work differently or not be available in subsequent versions of JavaFX. I think it generally does that, although I'll review it in more detail later. * I recommend a Draft PR with an example preview feature. That would also be a good place to host the JEP document (for now). You can see what I did in PR #1617 for Incubator Modules. * One of the important tenets of this is that the application developer needs to "opt in" in an obvious way. Since we can't have javac and java launcher support for this, your idea of a system property seems a good one. The system property should be read as early as possible to encourage passing it on the command line to make it more obvious (similarly our docs should show examples of running with `java -Djavafx.enablePreview=...` rather than a call to `System.setProperty`). Initializing the `PreviewFeature` class from the static initializer of `PlatformImpl` and `LauncherImpl` (as I did when adding the security manager check) might be helpful to this end. * Should the property be an integer (feature release) rather than boolean? Without some sort of annotation, I'm not sure it would help, but I'll throw it out there * I don't think the warning should be suppressible; the equivalent JDK warning isn't * Is there anything we could do with annotations that might be useful? Not sure on this one modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 52: > 50: private static final String SUPPRESS_WARNING_PROPERTY = "javafx.suppressPreviewBanner"; > 51: > 52: private static final boolean enabled = Boolean.getBoolean(ENABLE_PREVIEW_PROPERTY); The JDK requires that you opt into preview features _for a specific version_. That is, rather than a boolean, the JDK uses an integer feature release value that must match the current release. They do this by using the `--release` option (in connection with the `--enable-preview`), and compiling that into the class file, which we can't directly use. Maybe we can do something similar, though? ------------- PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2593835213 PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941798607 From kcr at openjdk.org Tue Feb 4 20:23:22 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Feb 2025 20:23:22 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: <6Qrvz1pjBb3IDdP-EXmlOAT-6DKtrT3nP0Z-HtLc50s=.6b97dab3-28db-4409-ab88-b10d8d4f3311@github.com> On Tue, 4 Feb 2025 19:47:08 GMT, Kevin Rushforth wrote: >> We could also do that, but the problem is that the contents of JEP 12 only map to JavaFX in some parts, but not in others. So we would need to include weasel language like "where applicable" (which always leaves a bit of room for interpretation), or provide what would basically be a detailed sentence-by-sentence diff. >> >> So in the end, it might still be easier to point at our own (complete) definition instead of a partially applicable definition somewhere else. > > Andy's suggestion matches what I did for [Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). This idea being that, given familiarity with the JDK concept (with a pointer to where you can read more about that), how are JavaFX Preview Features different? 90% vs 95%, lack of javac support, we use a property rather than a dedicated command line option, etc. > So in the end, it might still be easier to point at our own (complete) definition instead of a partially applicable definition somewhere else. Even if this ends up being the way we go, a pointer to JEP 12 and list of key differences would be helpful. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1941836869 From angorya at openjdk.org Tue Feb 4 20:56:28 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 20:56:28 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 12:41: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 incrementally with one additional commit since the last revision: > > add "maximized" pseudo-class for custom maximize button I wonder if the header bar needs to get clipped somehow: ![Screenshot 2025-02-04 at 12 50 23](https://github.com/user-attachments/assets/29f8be40-3b47-4192-a6c5-eeca00b22584) (also weird padding around buttons in the left content area) modules/javafx.base/src/test/java/test/util/ReflectionUtils.java line 41: > 39: * The field can be declared on any of the object's inherited classes. > 40: */ > 41: @SuppressWarnings("unchecked") is this annotation still needed (the build gives no warnings when it's removed)? modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h line 2: > 1: /* > 2: * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved. we probably want to change this to 2025 (and merge the latest master for good measure) tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/StageTesterWindow.java line 186: > 184: sizeComboBox.valueProperty().subscribe(event -> updateMinHeight.run()); > 185: headerBar.minSystemHeightProperty().subscribe(event -> updateMinHeight.run()); > 186: headerBar.setLeading(new Button("?")); minor: this is nice, but can we replace this with non-emoji character please? (messes up the line spacing in Eclipse) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2635049491 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1941811731 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1941806528 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1941871727 From angorya at openjdk.org Tue Feb 4 23:34:14 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Feb 2025 23:34:14 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> References: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> Message-ID: <7b0YecoGudUNWuj6J8SU30EUpJp5n7JK0tOUD3y8Pn0=.ff018656-7d0c-49a0-8eb1-94a36910dd11@github.com> On Mon, 3 Feb 2025 21:47:11 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: > > more jitter It looks like this test might depend on specifics of JIT: the very first run after re-compilation ("clean" in Eclipse) it fails (with all the tests enabled), but any number of subsequent runs pass just fine (macOS 15.1.1 M1). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1690#issuecomment-2635294085 From almatvee at openjdk.org Wed Feb 5 03:06:09 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 5 Feb 2025 03:06:09 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video Message-ID: - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. ------------- Commit messages: - 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video Changes: https://git.openjdk.org/jfx/pull/1695/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1695&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337960 Stats: 842 lines in 8 files changed: 592 ins; 64 del; 186 mod Patch: https://git.openjdk.org/jfx/pull/1695.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1695/head:pull/1695 PR: https://git.openjdk.org/jfx/pull/1695 From mhanl at openjdk.org Wed Feb 5 10:55:16 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 5 Feb 2025 10:55:16 GMT Subject: RFR: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception [v2] In-Reply-To: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> References: <482xB4D5jNKjhGd_LYMtghlVpniy0OMC3LeOgyd6lhI=.485ca52c-1923-4c41-b5cc-bf223d2fcd2f@github.com> Message-ID: On Tue, 4 Feb 2025 16:01:03 GMT, Ziad El Midaoui wrote: >> When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. >> Also added tests to test this new fix > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in TextInputControl.java I agree with @mstr2, but I think fixing the exception at least is good IMO. There are multiple locations in JFX where things are unbound to set a value. I think this should never happen, as it is unexpected for the developer. But that is a bigger problem to solve at one point. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1694#pullrequestreview-2595314059 From jpereda at openjdk.org Wed Feb 5 13:10:25 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 5 Feb 2025 13:10:25 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 Overall it looks really good, the new API is quite useful in some scenarios. I've done some successful tests and left some comments and questions about the API. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 83: > 81: @FunctionalInterface > 82: public static interface GeometryCallback { > 83: public void addRectangle(float left, float top, float right, float bottom); I understand that you use `float` here because all the calculations in `PrismTextLayout::getRange` use floats (from `TextRun`). However, the calculations down the line to generate the `Rectangle2D` mix floats and doubles without any casting (`TextUtils::getRange` with implicit casts from double to float, `PrismLayoutInfo::getGeometry` with float and double sums). Do you think we could use doubles here instead? modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 256: > 254: * @return the caret geometry > 255: */ > 256: public float[] getCaretInf(int offset, boolean leading); Is this a typo or is there a reason for naming this method `getCaretInf` instead of `getCaretInfo`? modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 268: > 266: * @param start the start offset > 267: * @param end the end offset > 268: * @param the type of the geometry missing `type`after `@param` modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismCaretInfo.java line 48: > 46: @Override > 47: public Rectangle2D getSegmentAt(int index) { > 48: return parts[index]; do we need a bound check here? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismLayoutInfo.java line 57: > 55: public Rectangle2D getBounds(boolean includeLineSpacing) { > 56: BaseBounds b = layout.getBounds(); > 57: Insets m = insets(); See my comments below about adding the insets to the layout information. Maybe we could also add another boolean `includeInsets` for this? modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismLayoutInfo.java line 127: > 125: > 126: private TextLine line(int ix) { > 127: return layout.getLines()[ix]; bound check? In any case, this private method is not used. modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextUtils.java line 45: > 43: /** > 44: * Queries the range geometry of the range of text within the text layout as > 45: * an array of {@code PathElement}s, for for one of the three possible types: typo `for for` modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextUtils.java line 49: > 47: *
  • {@link #TYPE_STRIKETHROUGH} - strike-through shape > 48: *
  • {@link #TYPE_TEXT} - text selection shape > 49: *
  • {@link #TYPE_UNDERLINE} - underline shape missing `TextLayout` before each type `#TYPE_...` modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 91: > 89: * @return the immutable list of {@code Rectangle2D} objects > 90: */ > 91: public abstract List selectionShape(int start, int end, boolean includeLineSpacing); See my comment below about using `javafx.scene.shape.Rectangle` instead of `javafx.geometry.Rectangle2D`: otherwise the API is misleading: `selectionShape` doesn't return a `Shape` subclass. modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 91: > 89: * @return the immutable list of {@code Rectangle2D} objects > 90: */ > 91: public abstract List selectionShape(int start, int end, boolean includeLineSpacing); I take that `LayoutInfo::selectionShape` should match the existing API `TextFlow::rangeShape` for the same selection coordinates. I wonder if you have tested this, with different insets. I take that with your current implementation, for `Rectangle2D` objects, it makes sense to have the insets of the TextFlow/Text node, but shapes don't include them. modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 56: > 54: * @since 25 > 55: */ > 56: public record TextLineInfo(int start, int end, Rectangle2D bounds) { I understand that you are using `javafx.geometry.Rectangle2D` for this PR to hold all caret/layout/line information related to bounds, and that seems to work fine so far. However, given that the `TextFlow`/`Text` APIs already provide information using `javafx.scene.shape.PathElement`, and given that as a result of this PR users will be able to query either old and new APIs, I was wondering if another `Shape` subclass might be better for the new API instead of `Rectangle2D`: As is now, you can't easily combine `Rectangle2D` with `PathElement` objects (in fact you need to do a manual conversion in `TextUtils::getRange` or `TextUtils::toRectangle2D`). Have you thought about using `javafx.scene.shape.Rectangle` instead? That would simplify your internal operations, and would be more easy to use for developers (for instance, drawing new shapes based the LayoutInfo, like in your MonkeyTester `LayoutInfoVisualizer` class). ------------- PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2593730681 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1941724308 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1941708045 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1941712304 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1941998555 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1942916469 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1942017852 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1941714592 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1941717570 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1942752033 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1942895045 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1942718447 From mhanl at openjdk.org Wed Feb 5 13:50:24 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 5 Feb 2025 13:50:24 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing Changes look good to me. Some nitpick in the javadoc which was at least for me hard to understand. Found no regression while testing. Test Coverage looks good as well. modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 35: > 33: > 34: /** > 35: * Extension of {@link ListenerListBase} which given an {@link ObservableValue} I had a hard time reading this sentence. Maybe it can be rephrased, so it is better understandable what the intent of this class is? Same in `OldValueCachingListenerList`. Maybe something like: `Extension of {@link ListenerListBase}, which allows a {@link ObservableValue} and its old value to notify all contained listeners with a depth first approach.` ------------- PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-2595527965 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1942776507 From arapte at openjdk.org Wed Feb 5 14:27:32 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 5 Feb 2025 14:27:32 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 13:44:47 GMT, Kevin Rushforth 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)? Created the task [JDK-8349472](https://bugs.openjdk.org/browse/JDK-8349472). Shall create a PR after this is integrated. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2636995801 From john.hendrikx at gmail.com Wed Feb 5 18:20:06 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 5 Feb 2025 19:20:06 +0100 Subject: Duplication in HBox/VBox Message-ID: Hi list, I wish to address the huge amount of duplication in HBox/VBox as it is error prone when doing modifications there.? I'm in the process of fixing these classes so that they no longer layout their children off-by-one-pixel on render scales other than 1 (they will often not fully fill the box, missing 1 pixel, due to rounding errors or incorrect snapping of values). There's two thing I want to do: - Make it clear which values are snapped, raw or near-snapped by using prefixes "raw", "snapped" and "near" in variables and method names.? Much of the code incorrectly assumes that adding, subtracting or multiplying two snapped values results in a snapped value.? This is not true, it is only a nearly snapped value; it must be resnapped if returned.? By meticulously tracking what is snapped, almost snapped and raw it is easier to call snap functions only when needed.? This is mostly renaming of variables.? There are numerous small problems in these classes (and probably other classes) where values are not resnapped after floating point calculations. - Deduplicate much of the code (I suspect 80-90%) by introducing a package private class AbstractBox, which holds the duplicated code. Since I dislike doing the same work twice, I did some research, and introducing a package private superclass?is a binary compatible change, even if duplicated public methods are moved to AbstractBox. Javadoc will also handle this correctly and will completely hide AbstractBox; public methods in AbstractBox will show up in HBox/VBox documentation, and HBox/VBox will be said to extend Pane still. An example of this pattern is AbstractStringBuilder, a package private class from which StringBuilder and StringBuffer inherit. At the time this was a binary compatible change when StringBuilder was introduced.? By looking at the Javadoc, you can't see it is there (https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/StringBuilder.html) and even its public methods are?show as being part of StringBuilder or StringBuffer directly. Let me know what you think. --John From andy.goryachev at oracle.com Wed Feb 5 18:28:56 2025 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 5 Feb 2025 18:28:56 +0000 Subject: Duplication in HBox/VBox In-Reply-To: References: Message-ID: Thank you John, I think it's the right approach. We probably should also look at the other containers to make sure all of them snap properly. This is a problem especially visible on Windows at fractional scales. Cheers, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, February 5, 2025 at 10:20 To: openjfx-dev at openjdk.org Subject: Duplication in HBox/VBox Hi list, I wish to address the huge amount of duplication in HBox/VBox as it is error prone when doing modifications there. I'm in the process of fixing these classes so that they no longer layout their children off-by-one-pixel on render scales other than 1 (they will often not fully fill the box, missing 1 pixel, due to rounding errors or incorrect snapping of values). There's two thing I want to do: - Make it clear which values are snapped, raw or near-snapped by using prefixes "raw", "snapped" and "near" in variables and method names. Much of the code incorrectly assumes that adding, subtracting or multiplying two snapped values results in a snapped value. This is not true, it is only a nearly snapped value; it must be resnapped if returned. By meticulously tracking what is snapped, almost snapped and raw it is easier to call snap functions only when needed. This is mostly renaming of variables. There are numerous small problems in these classes (and probably other classes) where values are not resnapped after floating point calculations. - Deduplicate much of the code (I suspect 80-90%) by introducing a package private class AbstractBox, which holds the duplicated code. Since I dislike doing the same work twice, I did some research, and introducing a package private superclass is a binary compatible change, even if duplicated public methods are moved to AbstractBox. Javadoc will also handle this correctly and will completely hide AbstractBox; public methods in AbstractBox will show up in HBox/VBox documentation, and HBox/VBox will be said to extend Pane still. An example of this pattern is AbstractStringBuilder, a package private class from which StringBuilder and StringBuffer inherit. At the time this was a binary compatible change when StringBuilder was introduced. By looking at the Javadoc, you can't see it is there (https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/StringBuilder.html) and even its public methods are show as being part of StringBuilder or StringBuffer directly. Let me know what you think. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Feb 5 20:40:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 20:40:32 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 Wed, 5 Feb 2025 13:07:50 GMT, Jose Pereda wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 25 25 > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismLayoutInfo.java line 57: > >> 55: public Rectangle2D getBounds(boolean includeLineSpacing) { >> 56: BaseBounds b = layout.getBounds(); >> 57: Insets m = insets(); > > See my comments below about adding the insets to the layout information. Maybe we could also add another boolean `includeInsets` for this? Good question! I don't think this is needed: the call returns the layout bounds (in the owning node coordinate system). The insets only change the position of the layout within the owning node, unlike lineSpacing which actually changes the shape by adding or removing the last line spacing. I think this method is ok as is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943630977 From angorya at openjdk.org Wed Feb 5 20:31:21 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 20:31:21 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 Tue, 4 Feb 2025 18:47:14 GMT, Jose Pereda wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 25 25 > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 83: > >> 81: @FunctionalInterface >> 82: public static interface GeometryCallback { >> 83: public void addRectangle(float left, float top, float right, float bottom); > > I understand that you use `float` here because all the calculations in `PrismTextLayout::getRange` use floats (from `TextRun`). > > However, the calculations down the line to generate the `Rectangle2D` mix floats and doubles without any casting (`TextUtils::getRange` with implicit casts from double to float, `PrismLayoutInfo::getGeometry` with float and double sums). > > Do you think we could use doubles here instead? the use of float in this interface is correct, but the code in TextUtils::getRange is bad, and i should feel bad. good catch! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943621599 From kcr at openjdk.org Wed Feb 5 20:53:24 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Feb 2025 20:53:24 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> References: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> Message-ID: <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> On Mon, 3 Feb 2025 21:47:11 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: > > more jitter Overall, this looks good. I think the framework is in a good enough place to integrate it now; we can always make improvements in the future if needed. Here are a couple general observations based on my testing (mostly on Windows): 1. Once a test fails, subsequent tests are likely to be impacted. I've seen several instances of a timeouts in later tests after a failure (when I enable a test associated with a known bug). In at least one case, the visible stage froze and became non-responsive. This isn't surprising to me, given that all tests are run in the same process. If any of the exceptions hit the FX application thread it will likely cause this behavior. 2. Some of the disabled tests only fail infrequently -- meaning that either the payload for the test or the 5 second duration might not be enough to trigger the bug reliably (although race conditions are notoriously hard to test "reliably"). We can look at these individual cases when reviewing the bug fix that will enable the corresponding test. I left a couple in-line questions and comments. Many would be questions for follow-up work (if at all). I'll re-approve if you decide to make any changes now. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 158: > 156: // for debugging purposes: setting this to true will skip working tests > 157: // TODO remove once all the tests pass > 158: private static final boolean SKIP_TEST = false; I presume this is just for your convenience while developing this test as a way to run only the test you are interested in? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 486: > 484: return c; > 485: }, (c) -> { > 486: c.setPannable(nextBoolean()); Do you think it's worth adding some scrolling here? That might be a good follow-on test enhancement. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 501: > 499: }, (c) -> { > 500: c.setEditable(nextBoolean()); > 501: accessControl(c); Is it worth adding code to increment / decrement the spinner? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 712: > 710: TreeItem root = new TreeItem<>(null); > 711: return root; > 712: }; `gen` is an unused local var. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 775: > 773: int threadCount = 1 + Runtime.getRuntime().availableProcessors() * 2; > 774: AtomicBoolean running = new AtomicBoolean(true); > 775: int additionalThreads = 2; // jiggler + tight loop I wonder if it is worth having more than 1 "tight loop" thread? Maybe dedicate 1/2 of the threads to a tight loop (`generator` in the loop) and 1/2 to access (`generator` once and `operation` in the loop) This is something that you could consider for a future improvement, tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 782: > 780: new Thread(() -> { > 781: try { > 782: while (running.get()) { Maybe exit early if there is a failure, e.g., `while (running.get() && !failed.get())`? In order to be effective, the `UncaughtExceptionHandler` would need to interrupt the main thread (so that `sleep(DURATION)` terminates early), so we would need to register the main thread with the `UncaughtExceptionHandler`. This could be a follow-on if we decide it is helpful (I'm not sure it's worth doing). tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 53: > 51: /** Stage valid only during test */ > 52: protected static Stage stage; > 53: protected static BorderPane content; MInor: I think `root` , `contentRoot`, or `contentPane` would be a better name here (it's a container for content, not the content itself as further indicated by the `setContent` method). tests/system/src/test/java/test/robot/testharness/RobotTestBase.java line 60: > 58: @Override > 59: public void start(Stage primaryStage) throws Exception { > 60: stage = primaryStage; Maybe `stage.setAlwaysOnTop(true)`? We do this for most other robot tests. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1690#pullrequestreview-2594237735 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1942002563 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943625091 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943625678 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943628584 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943631711 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943425979 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943446345 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943450309 From angorya at openjdk.org Wed Feb 5 20:35:24 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 20:35:24 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: <90IwTCTcUFrYPloNeeONG7AcomZThZ0Bz54N5YPVLnM=.33cb0b1e-8143-4ff2-80d9-82e1cd82b4db@github.com> On Tue, 4 Feb 2025 18:37:36 GMT, Jose Pereda wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 25 25 > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 268: > >> 266: * @param start the start offset >> 267: * @param end the end offset >> 268: * @param the type of the geometry > > missing `type`after `@param` eagle eye! > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismCaretInfo.java line 48: > >> 46: @Override >> 47: public Rectangle2D getSegmentAt(int index) { >> 48: return parts[index]; > > do we need a bound check here? no special handling is needed here I think: an exception will be thrown ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943625519 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943626862 From angorya at openjdk.org Wed Feb 5 21:28:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 21:28:50 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v17] 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 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 ag.text.layout.api - 25 25 - 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 - ... and 31 more: https://git.openjdk.org/jfx/compare/1b12c8a4...d688d746 ------------- Changes: https://git.openjdk.org/jfx/pull/1596/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=16 Stats: 1515 lines in 14 files changed: 1439 ins; 21 del; 55 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From angorya at openjdk.org Wed Feb 5 21:28:51 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 21:28:51 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 Wed, 5 Feb 2025 13:08:07 GMT, Jose Pereda wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 25 25 > > Overall it looks really good, the new API is quite useful in some scenarios. I've done some successful tests and left some comments and questions about the API. thank you for thoughtful comments, @jperedadnr ! > modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 91: > >> 89: * @return the immutable list of {@code Rectangle2D} objects >> 90: */ >> 91: public abstract List selectionShape(int start, int end, boolean includeLineSpacing); > > See my comment below about using `javafx.scene.shape.Rectangle` instead of `javafx.geometry.Rectangle2D`: otherwise the API is misleading: `selectionShape` doesn't return a `Shape` subclass. Good point. The word 'shape' might be confusing, although it is still correct in human terms (it is a shape, after all). I think it's ok, but we could use the word "geometry" for these methods `selectionGeometry` / `strikeThroughGeometry` / `underlineGeometry`, what do other people think? As for using `javafx.scene.shape.Rectangle` - it is too heavy of an object, with properties and everything, it's not what we ask from this method. > modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 91: > >> 89: * @return the immutable list of {@code Rectangle2D} objects >> 90: */ >> 91: public abstract List selectionShape(int start, int end, boolean includeLineSpacing); > > I take that `LayoutInfo::selectionShape` should match the existing API `TextFlow::rangeShape` for the same selection coordinates. > > I wonder if you have tested this, with different insets. I take that with your current implementation, for `Rectangle2D` objects, it makes sense to have the insets of the TextFlow/Text node, but shapes don't include them. We've got https://bugs.openjdk.org/browse/JDK-8341438 and a possibility of a regression if we change the existing methods. I would very much like to get your thoughts on this. > modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 56: > >> 54: * @since 25 >> 55: */ >> 56: public record TextLineInfo(int start, int end, Rectangle2D bounds) { > > I understand that you are using `javafx.geometry.Rectangle2D` for this PR to hold all caret/layout/line information related to bounds, and that seems to work fine so far. > > However, given that the `TextFlow`/`Text` APIs already provide information using `javafx.scene.shape.PathElement`, and given that as a result of this PR users will be able to query either old and new APIs, I was wondering if another `Shape` subclass might be better for the new API instead of `Rectangle2D`: As is now, you can't easily combine `Rectangle2D` with `PathElement` objects (in fact you need to do a manual conversion in `TextUtils::getRange` or `TextUtils::toRectangle2D`). > > Have you thought about using `javafx.scene.shape.Rectangle` instead? That would simplify your internal operations, and would be more easy to use for developers (for instance, drawing new shapes based the LayoutInfo, like in your MonkeyTester `LayoutInfoVisualizer` class). it was intentional decision to use the light weight `Rectangle2D` class instead of a `Shape` (which extends `Node`). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2638059384 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943674678 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943677479 PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1943679700 From angorya at openjdk.org Wed Feb 5 21:36:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 21:36:17 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> References: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> Message-ID: On Tue, 4 Feb 2025 22:49:42 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> more jitter > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 158: > >> 156: // for debugging purposes: setting this to true will skip working tests >> 157: // TODO remove once all the tests pass >> 158: private static final boolean SKIP_TEST = false; > > I presume this is just for your convenience while developing this test as a way to run only the test you are interested in? correct. > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 782: > >> 780: new Thread(() -> { >> 781: try { >> 782: while (running.get()) { > > Maybe exit early if there is a failure, e.g., `while (running.get() && !failed.get())`? > > In order to be effective, the `UncaughtExceptionHandler` would need to interrupt the main thread (so that `sleep(DURATION)` terminates early), so we would need to register the main thread with the `UncaughtExceptionHandler`. > > This could be a follow-on if we decide it is helpful (I'm not sure it's worth doing). Probably not worth doing it - the test is relatively quick (even after we add all other Nodes). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943688929 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943690492 From angorya at openjdk.org Wed Feb 5 21:43:21 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 21:43:21 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> References: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> Message-ID: On Wed, 5 Feb 2025 20:31:23 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> more jitter > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 486: > >> 484: return c; >> 485: }, (c) -> { >> 486: c.setPannable(nextBoolean()); > > Do you think it's worth adding some scrolling here? That might be a good follow-on test enhancement. follow-up > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 501: > >> 499: }, (c) -> { >> 500: c.setEditable(nextBoolean()); >> 501: accessControl(c); > > Is it worth adding code to increment / decrement the spinner? follow-up ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943697329 PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943697628 From angorya at openjdk.org Wed Feb 5 21:50:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 21:50:40 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v9] 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 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 15 additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - more jitter - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - jiggler - better name - fast loop - review comments - cleanup - ... and 5 more: https://git.openjdk.org/jfx/compare/27dbf5ce...0078aa18 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1690/files - new: https://git.openjdk.org/jfx/pull/1690/files/30700a69..0078aa18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1690&range=07-08 Stats: 1447 lines in 19 files changed: 1248 ins; 148 del; 51 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 Wed Feb 5 21:50:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 21:50:40 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> References: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> Message-ID: On Wed, 5 Feb 2025 20:38:00 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> more jitter > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 775: > >> 773: int threadCount = 1 + Runtime.getRuntime().availableProcessors() * 2; >> 774: AtomicBoolean running = new AtomicBoolean(true); >> 775: int additionalThreads = 2; // jiggler + tight loop > > I wonder if it is worth having more than 1 "tight loop" thread? Maybe dedicate 1/2 of the threads to a tight loop (`generator` in the loop) and 1/2 to access (`generator` once and `operation` in the loop) This is something that you could consider for a future improvement, this is an interesting idea, esp. for intermittent tests. I'll keep this as is for now, but will use the idea if we encounter more stubborn tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943701713 From kcr at openjdk.org Wed Feb 5 23:36:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Feb 2025 23:36:16 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v9] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 21:50:40 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 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 15 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - more jitter > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - skip tests > - jiggler > - better name > - fast loop > - review comments > - cleanup > - ... and 5 more: https://git.openjdk.org/jfx/compare/addd463c...0078aa18 Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1690#pullrequestreview-2597227312 From kcr at openjdk.org Wed Feb 5 23:36:18 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Feb 2025 23:36:18 GMT Subject: RFR: 8348423: [TestBug] stress test Nodes initialization from a background thread [v8] In-Reply-To: References: <2erUSRNYMlundJPFMV6eRoo_w8z1renL3FlM3NzbZWc=.2d6f388f-dab4-4f03-85a7-3357d280f473@github.com> <4UNv7sLyPp3NBnU3HEKbDDtuEvps5IYPHXzeebcPoi4=.10935126-a264-4f17-a5ff-c0948eb7b27d@github.com> Message-ID: On Wed, 5 Feb 2025 21:33:52 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 782: >> >>> 780: new Thread(() -> { >>> 781: try { >>> 782: while (running.get()) { >> >> Maybe exit early if there is a failure, e.g., `while (running.get() && !failed.get())`? >> >> In order to be effective, the `UncaughtExceptionHandler` would need to interrupt the main thread (so that `sleep(DURATION)` terminates early), so we would need to register the main thread with the `UncaughtExceptionHandler`. >> >> This could be a follow-on if we decide it is helpful (I'm not sure it's worth doing). > > Probably not worth doing it - the test is relatively quick (even after we add all other Nodes). Also, this would only bail out of a single test method, so very likely not worth it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1690#discussion_r1943827541 From angorya at openjdk.org Wed Feb 5 23:42:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Feb 2025 23:42:18 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 4c8b02a6 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/4c8b02a6786f87468310013d4c43a7e5711917c2 Stats: 1300 lines in 4 files changed: 1166 ins; 125 del; 9 mod 8348423: [TestBug] stress test Nodes initialization from a background thread Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1690 From duke at openjdk.org Wed Feb 5 23:45:16 2025 From: duke at openjdk.org (Ziad El Midaoui) Date: Wed, 5 Feb 2025 23:45:16 GMT Subject: Integrated: 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 14:11:00 GMT, Ziad El Midaoui wrote: > When binding the promptTextProperty of a TextInputControl (TextField or TextArea) to a text that contains linebreaks/newlines ("\n") the "bind" call causes a RuntimeException to be thrown, the solution to it is to unbind before calling the set(txt) method to set the new value for the property. > Also added tests to test this new fix This pull request has now been integrated. Changeset: d615fdc7 Author: Ziad El Midaoui Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/d615fdc717a55251225823ae5eeefb766e900e99 Stats: 42 lines in 2 files changed: 37 ins; 5 del; 0 mod 8335587: TextInputControl: Binding prompt text that contains linebreak causes exception Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1694 From angorya at openjdk.org Thu Feb 6 00:08:50 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Feb 2025 00:08:50 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils Message-ID: Thread-safe and re-entrant implementation of Utils. The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8347392.thread.safe.utils - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - review comments - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - more jitter - disabled titled pane test - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - ... and 12 more: https://git.openjdk.org/jfx/compare/d615fdc7...203f8de6 Changes: https://git.openjdk.org/jfx/pull/1691/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1691&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347392 Stats: 349 lines in 2 files changed: 144 ins; 85 del; 120 mod Patch: https://git.openjdk.org/jfx/pull/1691.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1691/head:pull/1691 PR: https://git.openjdk.org/jfx/pull/1691 From jvos at openjdk.org Thu Feb 6 08:47:24 2025 From: jvos at openjdk.org (Johan Vos) Date: Thu, 6 Feb 2025 08:47:24 GMT Subject: [jfx21u] Integrated: 8336940: Update GStreamer to 1.24.6 In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 07:55:06 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit b88ac049 from the openjdk/jfx repository. > > The commit being backported was authored by Alexander Matveev on 23 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora. > > Thanks! This pull request has now been integrated. Changeset: 41acdb60 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/41acdb60a95eb120c7617e178327af43b6353797 Stats: 24630 lines in 329 files changed: 13062 ins; 6878 del; 4690 mod 8336940: Update GStreamer to 1.24.6 8336939: Update Glib to 2.80.4 Backport-of: b88ac0495650bd033ba11e3131e9bffc517872eb ------------- PR: https://git.openjdk.org/jfx21u/pull/88 From mhanl at openjdk.org Thu Feb 6 13:18:35 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 6 Feb 2025 13:18:35 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v3] In-Reply-To: References: Message-ID: > This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. > > While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. > > It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). > Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge and adjust logic to master - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup - Call getFixedCellSize() once - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup ------------- Changes: https://git.openjdk.org/jfx/pull/1645/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=02 Stats: 143 lines in 5 files changed: 77 ins; 33 del; 33 mod Patch: https://git.openjdk.org/jfx/pull/1645.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/jfx/pull/1645 From kevin.rushforth at oracle.com Thu Feb 6 17:20:45 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 6 Feb 2025 09:20:45 -0800 Subject: JavaFX 24 is in Rampdown Phase Two (RDP2) Message-ID: To: JavaFX Developers As a reminder, JavaFX 24 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed during RDP2. Explicit approval is needed for all bug fixes and enhancements (except for doc and test fixes) to go in to the jfx24 branch [2]. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in JavaFX 24. We need to be extremely careful about including anything that introduces risk. We will use the same rules for RDP2 that the JDK uses [3], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 24 release. As an obvious choice, derived from the JBS fix version, we will use "jfx24-fix-request", "jfx24-fix-yes", "jfx24-fix-no" and "jfx24-fix-nmi", "jfx24-enhancement-request", "jfx24-enhancement-yes", "jfx24-enhancement-no" and "jfx24-enhancement-nmi" as corresponding labels. REMINDER: In this release we will integrate almost all stabilization changes via backports from the master branch [4]. ? * Almost all fixes intended for the 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 [5].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 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 RDP2 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 (or withdrawn if it is a backport of a fix already in `master`). Reviewers also need to be extra careful when reviewing PRs targeted to 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. 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] http://openjdk.org/jeps/3 [4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [5] https://openjdk.org/guide/#working-with-backports-in-jbs From angorya at openjdk.org Thu Feb 6 18:53:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Feb 2025 18:53:01 GMT Subject: RFR: 8348100: Tooltips cannot be instantiated on background thread Message-ID: Navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing a NPE. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8348100.tootlip.thread.safety - cleanup - tooltip test - Merge branch '8348423.node.thread.safety' into 8348100.tootlip.thread.safety - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - jiggler - tooltip test - better name - fast loop - ... and 7 more: https://git.openjdk.org/jfx/compare/d615fdc7...35aa3a37 Changes: https://git.openjdk.org/jfx/pull/1696/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1696&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348100 Stats: 51 lines in 2 files changed: 46 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1696.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1696/head:pull/1696 PR: https://git.openjdk.org/jfx/pull/1696 From martinfox656 at gmail.com Thu Feb 6 18:57:41 2025 From: martinfox656 at gmail.com (Martin Fox) Date: Thu, 6 Feb 2025 10:57:41 -0800 Subject: [External] : Re: Focus delegation API In-Reply-To: References: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> Message-ID: <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com> Michael, I?m (finally) looking at how this proposal could be extended to cover InputMethod events and have a few questions. In particular I want to verify that focus delegation needs to be in Node and not in, say, Control. This PR uses an event dispatcher to provide a cleaner way of channeling keyboard events to another node. I haven?t prototyped the code but I suspect a Control could do this using the existing API without any changes to the Node class. This PR also provides an API to query a node?s delegate, finally making the delegation public. This could also be an aspect of a Control rather than a Node. This PR also introduces a much cleaner way of getting the focused property set on the internal TextField of a ComboBox or Spinner. This seems to be the one part of the proposal that really needs to be in Node (and which would drag the stuff I already mentioned into Node). But it raises a question: why is JavaFX setting the focused property on the TextField editor to begin with? I presume it?s to ensure the editor has the correct visuals but this means two focus rings are shown when a ComboBox has focus. It also means that the editor?s focus ring shows up even if it?s not editable. Finally, an observation. Currently someone can attach an event handler on a Scene and see all events targeted at TextFields including TextFields inside ComboBoxes and Spinners. With this PR that would no longer work and they would have to attach their filter directly to those internal TextFields. I don?t have a strong opinion on whether this is a good idea or not but it should probably be noted in the proposal. Martin > On Dec 17, 2024, at 3:29?PM, Andy Goryachev wrote: > > Martin: > > I guess I am trying to say that I find the focus delegation idea as unnecessary - it feels to me like a band-aid on a broken event dispatching system. It might be the case that the current design was there from the beginning, and so probably all the other issues we have encountered so far due to that design: > > - the order of events is undefined > - the events are copied willy nilly and their isConsumed flag is ignored > - a parallel isConsumed mechanism gets invented > - it is possible for the application to create a misbehaving event dispatcher > - events that are intended for an inner component bubble up to the scene graph unnecessarily > - consumed events continue being dispatched > - multiple controls show input focus and handle input events simultaneously > > I am trying to find an alternative that will be easy for everyone to understand and use. Does not mean we should drop everything and re-write the whole thing, but I do want to continue the conversation. > > -andy > > > > > > From: Martin Fox > Date: Friday, December 13, 2024 at 08:03 > To: Andy Goryachev > Cc: OpenJFX > Subject: Re: [External] : Re: Focus delegation API > > Hi Andy, > > I?m trying to understand the use case you?ve outlined here since it doesn?t correspond to anything currently in JavaFX. > > > On Dec 10, 2024, at 8:32?AM, Andy Goryachev wrote: > > How does the idea of focus delegation works with multiple inner nodes that are supposed to handle different aspects of a complex control? For example, a custom combo box-like control may contain an editor (possibly created dynamically), may be a couple of buttons, may be even two editors. How would that work? > > In this example, the buttons need focus to respond to ENTER or SPACE key presses, the editors should respond to key typed and maybe LEFT/RIGHT arrow keys to switch between the two, and so on. Will the proposed design still work? > > Are you proposing a control which delegates events to one inner node that changes over time OR a control which delegates a single key event to multiple inner nodes at once? If the latter, would all of those inner nodes have the focused flag set? > > Neither of these correspond to a control design I?m familiar with. Can you point to an example? I can?t picture how such a control would appear to the user. > > In either case would the delegate nodes be accessible via an API like a Spinner?s editor or hidden like a Spinner?s buttons? In the unlikely event that we wanted to deliver key events to a Spinner?s buttons I could imagine using an internal mechanism but that doesn?t make much sense for the publicly accessible editor. Perhaps in your use-case we need two separate mechanisms for delivering key events, this PR and a different one for delegate nodes that aren?t advertised via the control?s API. > > Martin > > > From: openjfx-dev > on behalf of Michael Strau? > > Date: Monday, December 9, 2024 at 18:17 > To: > Cc: openjfx-dev > Subject: Re: [External] : Re: Focus delegation API > > > Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. > > I can't image that we would ever do this, considering that events have > been there almost from the beginning. We'd break half of the JavaFX > world if we changed the API of events. > In addition to that, this would remove functionality. As of now, you > can add a listener to Scene, and inspect which node is being targeted > by an event. > > > > > 2. ComboBox's skin has installed an event filter on ComboBox > > > > So we have another scenario where different priorities are needed: adding event filters. > > Maybe, but that's a different problem than what's being solved by > focus delegation. Focus delegation is all about removing defective > ad-hoc implementations, and offering a pre-made building block for > composite controls. > > > > > 3. However, it must forward the event to the TextField (as otherwise > > the TextField doesn't work), so it fires off a copy of the event > > targeted at TextField. > > > > Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. > > Sure, that would be an option. But it's not my preferred solution for > the following reasons: > 1. It's gratuitously different. Instead of using events like they > normally work, control skins would punch a hole through the scene > graph, and deliver the event directly to the delegation target. That > means that the skin's scene graph works differently as the outside > scene graph, as you can't observe events traveling through it. > 2. It requires the skin to implement a complex protocol (register an > event handler, copy the event, punch a hole through to the delegation > target, send off the event), whereas the focus delegation proposal > requires no additional implementation inside of the skin (aside from > selecting the delegation target). > > The advantage of focus delegation is that it just works, even > recursively, across arbitrary levels of abstractions (a skin might > contain another control, which itself has a skin, and so on). No > matter where you listen to events, you will always see exactly what > you'd expect to see: an event that is targeted at the next focused > node. This is another aspect of focus delegation, unrelated to events: > it formalizes the notion of multi-level focus without resorting to > hacks (like FakeFocusTextField). You'll need to solve this no matter > what, as users can click on the TextField. As we discussed, the > ComboBox must be the focus owner even when a user clicks on the > TextField. > > > > > Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. > > First of all, it's only one property (Node.hoistFocus), not a bunch. > And this is not related to events at all, it is a way for skins to > indicate that clicking on an internal node will focus the outside > control. > > The part of focus delegation that fixes the delivery of events in a > scene graph with potentially nested abstractions is done without any > new properties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Feb 6 19:44:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 6 Feb 2025 19:44:14 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 03:00:17 GMT, Alexander Matveev wrote: > - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. > - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. > - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. > - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. Reviewers: @kevinrushforth @arapte @tiainen @johanvos There is a small change to one of the Makefiles so you might want to do a test build ------------- PR Comment: https://git.openjdk.org/jfx/pull/1695#issuecomment-2640832060 From angorya at openjdk.org Thu Feb 6 19:53:45 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Feb 2025 19:53:45 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread Message-ID: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Root Cause: (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. With this change, it is safe to create and populate charts with data in a background thread. --- ## NOTES 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. ------------- Commit messages: - whitespace - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - cleanup - tests pass - chart tests only - more jitter - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - jiggler - better name - ... and 8 more: https://git.openjdk.org/jfx/compare/d615fdc7...4070d8cc Changes: https://git.openjdk.org/jfx/pull/1697/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349091 Stats: 304 lines in 11 files changed: 165 ins; 100 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1697.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697 PR: https://git.openjdk.org/jfx/pull/1697 From credmond at certak.com Thu Feb 6 19:56:57 2025 From: credmond at certak.com (Cormac Redmond) Date: Thu, 6 Feb 2025 19:56:57 +0000 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) Message-ID: Hi, I have found a "serious" bug, where two completely independent JFX applications, both with their own embedded runtime (built with jlink & jpackage) & using the same JavaFX version, are unable to run simultaneously, because of the JFX cache -- at least on Windows. When trying to run any application, NativeLibLoader does a checksum on DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); and tries to delete any files that exist where the checksums do not match (in order to replace them): if (!Arrays.equals(isHash, fileHash)) { > Files.delete(f.toPath()); > } But a second application *fails* to start, as it is unable to delete these files because they're in use by the first application (see stacktrace below). But why are the checksums different, shouldn't they be the same? They are different because the DLLs are signed by the builder of the applications -- different authors and different timestamps. So the DLL checksums will be different despite the DLLs being the same, in terms of the JFX version. Why are these JFX DLLs signed by the authors? Because for some reason, they come *unsigned*, and all DLLs when packaged *should* be signed, including any embedded in JARs, to avoid alarming Windows Defender warnings and mistrust, etc. There's no point spending a small fortune on Windows code-signing certs and shipping with any unsigned third-party DLLs (including any embedded in JARs). You might sign your own binaries and any unsigned third-party binaries. Similarly for MacOS, everything, including embedded native libs in JARs, etc., needs to be signed for gatekeeper & notarization to allow it. So it would be better if JFX DLLs came signed, to avoid forcing developers to do it (which would also avoid this checksum mishap). Or, if developers need to sign Oracle's DLLs, then this checksum approach isn't suitable. Also, there should really be a proper fallback in place -- a cache bug should not have such a catastrophic outcome. FYI: JLink also removes signatures from a bunch of JDK DLLs when assembling the runtime, but leaves a bunch of Windows DLLs untouched. Personally, I'd prefer all DLLs to come signed, and let the developers re-sign if they want. Removing the signatures is adding unnecessary hurdles for folks, for no benefit I can see. Anyway, example stacktrace: Loading D3D native library ... > WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program > Files\KafkIO\bin\prism_d3d.dll > Loading library prism_d3d from resource failed: > java.nio.file.AccessDeniedException: C:\Users\xyz > \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll > java.nio.file.AccessDeniedException: C:\Users\xyz > \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll > at > java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) > at > java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > at > java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > at > java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) > at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown > Source) > at java.base/java.nio.file.Files.delete(Unknown Source) > at > com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) > at > com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) > at > com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) > at > com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) > at > com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) > at > com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) > at java.base/java.security.AccessController.doPrivileged(Unknown > Source) > at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Unknown Source) > at java.base/java.lang.Class.forName(Unknown Source) > at > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > at java.base/java.lang.Thread.run(Unknown Source) > GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline > java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: > C:\Program > Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program > Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files > (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program > Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program > Files\SafeNet\Authentication\SAC\x64;C:\Program > Files\SafeNet\Authentication\SAC\x32;C:\Program > Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ > xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz > \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz > \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz \scoop\shims;C:\Users\xyz > \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program > Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. > at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) > at java.base/java.lang.System.loadLibrary(Unknown Source) > at > com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) > at > com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) > at > com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) > at java.base/java.security.AccessController.doPrivileged(Unknown > Source) > at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Unknown Source) > at java.base/java.lang.Class.forName(Unknown Source) > at > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > at java.base/java.lang.Thread.run(Unknown Source) Kind Regards, Cormac -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Feb 6 20:17:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 6 Feb 2025 20:17:15 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Thu, 6 Feb 2025 19:26:25 GMT, Andy Goryachev wrote: > Root Cause: > (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. > > I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. > > Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. > > The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. > > With this change, it is safe to create and populate charts with data in a background thread. > > --- > > ## NOTES > > 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. > 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. Reviewers: @kevinrushforth @azuev-java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2640901979 From angorya at openjdk.org Thu Feb 6 20:59:46 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Feb 2025 20:59:46 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread Message-ID: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> ## Root Cause Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). ## Solution Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. ------------- Commit messages: - postpone animation Changes: https://git.openjdk.org/jfx/pull/1698/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349105 Stats: 11 lines in 2 files changed: 4 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1698.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1698/head:pull/1698 PR: https://git.openjdk.org/jfx/pull/1698 From angorya at openjdk.org Thu Feb 6 22:35:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Feb 2025 22:35:16 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 23:35:05 GMT, Andy Goryachev wrote: > Thread-safe and re-entrant implementation of Utils. > > The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. @kevinrushforth I'd suggest to take a look at this first, as it blocks some other fixes. thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2641273730 From angorya at openjdk.org Thu Feb 6 23:32:25 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Feb 2025 23:32:25 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread Message-ID: ## Root Cause Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). ## Solution Skip the animation. The fix is similar to https://github.com/openjdk/jfx/pull/1698 ------------- Commit messages: - skip animation Changes: https://git.openjdk.org/jfx/pull/1699/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1699&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349098 Stats: 18 lines in 2 files changed: 2 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1699.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1699/head:pull/1699 PR: https://git.openjdk.org/jfx/pull/1699 From kcr at openjdk.org Fri Feb 7 00:42:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 00:42:17 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 23:35:05 GMT, Andy Goryachev wrote: > Thread-safe and re-entrant implementation of Utils. > > The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. The fix looks good. My testing is good as well. The now-enabled tests fail pretty reliably for me on Windows without your fix and all pass with your fix. I left a few minor questions / comments, but will approve as is. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 249: > 247: > 248: @Test > 249: public void checkBox() { Minor: this test calls `setSelected(true)`. Would introducing randomness via `setSelected(nextBoolean())` be useful here? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 263: > 261: > 262: @Test > 263: public void choiceBox() { Minor: select random item? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 330: > 328: > 329: @Test > 330: public void hyperlink() { Minor: `setVisited(nextBoolean())`? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1691#pullrequestreview-2600260514 PR Review Comment: https://git.openjdk.org/jfx/pull/1691#discussion_r1945619434 PR Review Comment: https://git.openjdk.org/jfx/pull/1691#discussion_r1945620100 PR Review Comment: https://git.openjdk.org/jfx/pull/1691#discussion_r1945618566 From kcr at openjdk.org Fri Feb 7 00:45:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 00:45:15 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Thu, 6 Feb 2025 20:43:54 GMT, Andy Goryachev wrote: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. The test runs out of heap space for me on Windows with or without your fix using the default heap size. This may point to a leak, although bumping up the memory causes it to pass with your fix. The fix looks good, although the test doesn't catch the bug most of the time (even when bumping up the heap). ------------- PR Review: https://git.openjdk.org/jfx/pull/1698#pullrequestreview-2600480255 From michaelstrau2 at gmail.com Fri Feb 7 07:52:59 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 7 Feb 2025 08:52:59 +0100 Subject: [External] : Re: Focus delegation API In-Reply-To: <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com> References: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com> Message-ID: > This PR uses an event dispatcher to provide a cleaner way of channeling keyboard events to another node. I haven?t prototyped the code but I suspect a Control could do this using the existing API without any changes to the Node class. > This PR also provides an API to query a node?s delegate, finally making the delegation public. This could also be an aspect of a Control rather than a Node. I'm not sure you could do that. The redirecting event dispatcher ensures that on each level of abstraction, you'll see events exactly how you would expect to see them in isolation. For example, consider a Control that contains a sub-graph of nodes and, eventually, a TextField. The idea is that the events received in the Control's sub-graph should be consistent with what would happen if the sub-graph was a top-level scene graph. What you could probably do in Control, is sending the event directly to its delegation target. But that would exclude listeners between the Control and its delegation target: Control=>[other nodes]=>target. > This PR also introduces a much cleaner way of getting the focused property set on the internal TextField of a ComboBox or Spinner. This seems to be the one part of the proposal that really needs to be in Node (and which would drag the stuff I already mentioned into Node). But it raises a question: why is JavaFX setting the focused property on the TextField editor to begin with? I presume it?s to ensure the editor has the correct visuals but this means two focus rings are shown when a ComboBox has focus. That's another aspect of the "consistency story" that this proposal tries to tell: you should be able to reason about the sub-graph of a Control in the same way as you reason about a top-level graph. If your control receives input, then it should also be focused. However, you point out an obvious sharp edge here. Consistent focus on sub-graphs also drag CSS into the equation, and this is where it gets a bit messy. The basic idea seems reasonable: JavaFX allows you to create new controls simply by composing existing controls. But it's not that easy: in some cases, you probably don't want nested focus rings in your composite control. But maybe you want the inner TextField to indicate focus in a different way, let's say with a colored background? Currently, styling composite controls is a bit awkward, since you'll need to provide styles for the inner control that undo things you don't need from the outer control. For exampe, if the outer control specifies a blue focus ring border, you'll need a contextual style for the inner control that makes the border go away. This entangles the styling of the outer and inner control in a very cumbersome way. > It also means that the editor?s focus ring shows up even if it?s not editable. I think that a node that is disabled, not editable, or not focus traversable should probably not be eligible to be a focus delegate. That would be inconsistent with top-level graphs. > Finally, an observation. Currently someone can attach an event handler on a Scene and see all events targeted at TextFields including TextFields inside ComboBoxes and Spinners. With this PR that would no longer work and they would have to attach their filter directly to those internal TextFields. I don?t have a strong opinion on whether this is a good idea or not but it should probably be noted in the proposal. Good point, I've added this to the proposal text. From michaelstrau2 at gmail.com Fri Feb 7 08:14:01 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 7 Feb 2025 09:14:01 +0100 Subject: Duplication in HBox/VBox In-Reply-To: References: Message-ID: > - Make it clear which values are snapped, raw or near-snapped by using > prefixes "raw", "snapped" and "near" in variables and method names. > Much of the code incorrectly assumes that adding, subtracting or > multiplying two snapped values results in a snapped value. This is not > true, it is only a nearly snapped value; it must be resnapped if > returned. By meticulously tracking what is snapped, almost snapped and > raw it is easier to call snap functions only when needed. This is > mostly renaming of variables. There are numerous small problems in > these classes (and probably other classes) where values are not > resnapped after floating point calculations. It is incredible easy to get this wrong. I'd appreciate a "how to snap correctly" tutorial/documentation somewhere in JavaFX. From mstrauss at openjdk.org Fri Feb 7 09:16:54 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Feb 2025 09:16:54 GMT Subject: RFR: 8349373: Support JavaFX preview features [v3] In-Reply-To: References: Message-ID: > This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. Michael Strau? has updated the pull request incrementally with four additional commits since the last revision: - javadoc - remove supporting documentation - warning can't be suppressed - initialize PreviewFeature early ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1359/files - new: https://git.openjdk.org/jfx/pull/1359/files/2fa3560d..0a2a48b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=01-02 Stats: 65 lines in 4 files changed: 10 ins; 50 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1359.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1359/head:pull/1359 PR: https://git.openjdk.org/jfx/pull/1359 From mstrauss at openjdk.org Fri Feb 7 15:10:21 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Feb 2025 15:10:21 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: Message-ID: <8RHKVr7d8HBbmtIJkXTx10wybGBgE3kU2gnKpDxB71U=.0d7575a4-48d1-4404-a20a-dc8e5adae9bf@github.com> On Tue, 4 Feb 2025 19:47:34 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> move enum field to top > > modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 52: > >> 50: private static final String SUPPRESS_WARNING_PROPERTY = "javafx.suppressPreviewBanner"; >> 51: >> 52: private static final boolean enabled = Boolean.getBoolean(ENABLE_PREVIEW_PROPERTY); > > The JDK requires that you opt into preview features _for a specific version_. That is, rather than a boolean, the JDK uses an integer feature release value that must match the current release. They do this by using the `--release` option (in connection with the `--enable-preview`), and compiling that into the class file, which we can't directly use. Maybe we can do something similar, though? This is only done at compilation time, not at runtime. JEP 12 elaborates on this: > --enable-preview itself does not take a version number because it would be easy to misinterpret. For example, on JDK 18, the (hypothetical) flag --enable-preview 19 would appear to suggest support for the preview features of JDK 19, but those features are not known at the time of JDK 18's release. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1946680175 From angorya at openjdk.org Fri Feb 7 15:59:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 15:59:16 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 07:58:47 GMT, Michael Strau? wrote: > What's the rationale for using a borrow pattern here, instead of simply synchronizing access to the object in question? A very good question! This pattern seemed to be the most applicable here: the solution needs to be both thread-safe and reentrant, with the expectation that in most cases the simple scenario happens where the static instance is used. We actually use that pattern using synchronization, see `GlyphLayout::getInstance()` for example. I think the use of AtomicBoolean is far better, so I took the same approach in #1667 . Is there a specific scenario that would not work or cause issues? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2643323226 From angorya at openjdk.org Fri Feb 7 16:03:13 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 16:03:13 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 7 Feb 2025 00:42:35 GMT, Kevin Rushforth wrote: > The test runs out of heap space for me on Windows This may be a memory leak, or it could simply be expected - after all, it is a stress test and we do create heavy objects in a tight loop. I think it's worth investigating in the context of this ticket. Thank you! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2643333815 From angorya at openjdk.org Fri Feb 7 16:18:35 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 16:18:35 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 23:39:26 GMT, Kevin Rushforth wrote: >> Thread-safe and re-entrant implementation of Utils. >> >> The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 249: > >> 247: >> 248: @Test >> 249: public void checkBox() { > > Minor: this test calls `setSelected(true)`. Would introducing randomness via `setSelected(nextBoolean())` be useful here? here and elsewhere, you are right ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1691#discussion_r1946792162 From angorya at openjdk.org Fri Feb 7 16:33:27 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 16:33:27 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: References: Message-ID: > Thread-safe and re-entrant implementation of Utils. > > The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. 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/1691/files - new: https://git.openjdk.org/jfx/pull/1691/files/203f8de6..1e9cb5d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1691&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1691&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1691.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1691/head:pull/1691 PR: https://git.openjdk.org/jfx/pull/1691 From kcr at openjdk.org Fri Feb 7 16:48:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 16:48:17 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: References: Message-ID: <6MmEKQXHA7uF2cQW4iPQAKh_A0wPzz7uhe5Cear0l_g=.eaa6b091-e6d3-43f1-94ab-53457eca2553@github.com> On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote: >> Thread-safe and re-entrant implementation of Utils. >> >> The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. > > 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/1691#pullrequestreview-2602264635 From kcr at openjdk.org Fri Feb 7 16:54:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 16:54:14 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: References: Message-ID: <1AhLrCKgGrvIzi-teKJTpGTRVOzCJ23GRZEUNATrPtU=.55528bbe-efb5-4ec4-bd09-f4c95e4c9952@github.com> On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote: >> Thread-safe and re-entrant implementation of Utils. >> >> The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments To add a little more to what Andy said, I think there are three main approaches that could have been used here: 1. Remove the static fields and always allocate a new object each time it is needed. 2. Keep the static fields for the common case where there is only one thread (typically the JavaFX application thread); check and allocate a new object if the static fields are already in use 3. Replace the static fields with ThreadLocalStorage There might be other solutions, but we don't want anything too complicated. Andy decided to go with 2. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2643463999 From kcr at openjdk.org Fri Feb 7 16:59:18 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 16:59:18 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 7 Feb 2025 16:01:02 GMT, Andy Goryachev wrote: > This may be a memory leak, or it could simply be expected - after all, it is a stress test and we do create heavy objects in a tight loop. > > I think it's worth investigating in the context of this ticket. Thank you! Yep, it does needs to be investigated for this PR, since we can't enable a test that will cause OOM when running the tests normally. I'll be interested to know what you find. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2643479700 From kcr at openjdk.org Fri Feb 7 17:17:18 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 17:17:18 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 23:20:30 GMT, Andy Goryachev wrote: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Skip the animation. > > The fix is similar to https://github.com/openjdk/jfx/pull/1698 Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1699#issuecomment-2643524697 From kcr at openjdk.org Fri Feb 7 17:44:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 17:44:16 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 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1692#pullrequestreview-2602409040 From mstrauss at openjdk.org Fri Feb 7 17:48:16 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Feb 2025 17:48:16 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote: >> Thread-safe and re-entrant implementation of Utils. >> >> The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by mstrauss (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1691#pullrequestreview-2602418608 From mstrauss at openjdk.org Fri Feb 7 17:51:16 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Feb 2025 17:51:16 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 5cdbae24 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/5cdbae240d7bfbab6d340363a7c394f941fbc36d Stats: 70 lines in 3 files changed: 65 ins; 0 del; 5 mod 8333275: ComboBox: adding an item from editor changes editor text Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1692 From angorya at openjdk.org Fri Feb 7 17:58:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 17:58:16 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: References: Message-ID: <_NOnT1N-n2wOYN8aM3egz9YCrCO3AAxRfw1dpnNcHf8=.c1179bed-48d2-415d-9e55-a8b7ada8e373@github.com> On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote: >> Thread-safe and re-entrant implementation of Utils. >> >> The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Hmmm, to further make a point: options 2 and 3 may not be re-entrant, so they probably won't work. We haven't encounter this re-entrancy issue, but I suppose it might be possible to have a text component embedded in another text component (e.g. a TextArea embedded inside a RichTextArea for some reason). Even if the access happens within the FX application thread, the inner layout might clobber the outer one. Thank you for a good discussion though! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2643614530 From kcr at openjdk.org Fri Feb 7 18:06:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 18:06:16 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: <_NOnT1N-n2wOYN8aM3egz9YCrCO3AAxRfw1dpnNcHf8=.c1179bed-48d2-415d-9e55-a8b7ada8e373@github.com> References: <_NOnT1N-n2wOYN8aM3egz9YCrCO3AAxRfw1dpnNcHf8=.c1179bed-48d2-415d-9e55-a8b7ada8e373@github.com> Message-ID: On Fri, 7 Feb 2025 17:55:28 GMT, Andy Goryachev wrote: > Hmmm, to further make a point: options 2 and 3 may not be re-entrant, so they probably won't work. Your solution is basically what I meant by option 2. The way you did it, always using the return value of a method that will return a "safe" instance to use, is reentrant. You are right that a simple approach to option 3 would not be reentrant. I like the solution you chose. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2643642428 From angorya at openjdk.org Fri Feb 7 18:12:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 18:12:17 GMT Subject: RFR: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils [v2] In-Reply-To: References: <_NOnT1N-n2wOYN8aM3egz9YCrCO3AAxRfw1dpnNcHf8=.c1179bed-48d2-415d-9e55-a8b7ada8e373@github.com> Message-ID: On Fri, 7 Feb 2025 18:03:41 GMT, Kevin Rushforth wrote: > Your solution is basically what I meant by option 2. right. "only one thread" threw me off, sorry. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2643660437 From angorya at openjdk.org Fri Feb 7 18:16:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 18:16:18 GMT Subject: Integrated: 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 23:35:05 GMT, Andy Goryachev wrote: > Thread-safe and re-entrant implementation of Utils. > > The new code still uses the static instances of Text and TextLayout for performance reasons, but adds a thread-safe mechanism to keep track of whether any of the instances is in use and when that happens, supplies a new instance instead. This solves both thread safety and re-entrancy. This pull request has now been integrated. Changeset: 2cf9779b Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/2cf9779bdef24d4f7ab5becd945b8baa6b0df06a Stats: 356 lines in 2 files changed: 145 ins; 85 del; 126 mod 8347392: Thread-unsafe implementation of c.s.j.scene.control.skin.Utils Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1691 From kcr at openjdk.org Fri Feb 7 18:40:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 18:40:17 GMT Subject: RFR: 8348100: Tooltips cannot be instantiated on background thread In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:35:06 GMT, Andy Goryachev wrote: > Navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing a NPE. I think the root cause of the problem is in `Tooltip::getStyleableParent`, which does not return a stable result when called from a background thread. The implementation does this: if (BEHAVIOR.hoveredNode == null) { return super.getStyleableParent(); } return BEHAVIOR.hoveredNode; Where `BEHAVIOR` is a static field of Tooltip. This might be a better fix: @Override public Styleable getStyleableParent() { if (!Platform.isFxApplicationThread() || BEHAVIOR.hoveredNode == null) { return super.getStyleableParent(); } return BEHAVIOR.hoveredNode; } and then you don't even need the null checks you added to `CssStyleHelper`. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 205: > 203: if (parent == null) { > 204: return; > 205: } While this does prevent the exception, I think this is fixing a symptom rather than the root cause. The only reason that parent can ever be null here and in the other place you added the null check is that `Tooltip::getStyleableParent` is returning a different answer between the time it is called to calculate `depth` and the time it is used here in a loop. This is happening because `Tooltip::getStyleableParent` uses static state that is only valid when on the FX application thread. ------------- PR Review: https://git.openjdk.org/jfx/pull/1696#pullrequestreview-2602481137 PR Review Comment: https://git.openjdk.org/jfx/pull/1696#discussion_r1946970797 From angorya at openjdk.org Fri Feb 7 18:41:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 18:41:53 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8349105.thread.safety.pagination - postpone animation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1698/files - new: https://git.openjdk.org/jfx/pull/1698/files/cd6b308d..a3330b2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=00-01 Stats: 426 lines in 5 files changed: 210 ins; 85 del; 131 mod Patch: https://git.openjdk.org/jfx/pull/1698.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1698/head:pull/1698 PR: https://git.openjdk.org/jfx/pull/1698 From angorya at openjdk.org Fri Feb 7 18:42:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 18:42:01 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Skip the animation. > > The fix is similar to https://github.com/openjdk/jfx/pull/1698 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8349098.thread.safe.tabpane - skip animation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1699/files - new: https://git.openjdk.org/jfx/pull/1699/files/46d7be12..40b9a23c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1699&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1699&range=00-01 Stats: 426 lines in 5 files changed: 210 ins; 85 del; 131 mod Patch: https://git.openjdk.org/jfx/pull/1699.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1699/head:pull/1699 PR: https://git.openjdk.org/jfx/pull/1699 From angorya at openjdk.org Fri Feb 7 18:43:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 18:43:32 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> > Root Cause: > (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. > > I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. > > Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. > > The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. > > With this change, it is safe to create and populate charts with data in a background thread. > > --- > > ## NOTES > > 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. > 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into 8349091.charts.thread.safety - whitespace - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - cleanup - tests pass - chart tests only - more jitter - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - jiggler - ... and 9 more: https://git.openjdk.org/jfx/compare/2cf9779b...4b6089e4 ------------- Changes: https://git.openjdk.org/jfx/pull/1697/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=01 Stats: 304 lines in 11 files changed: 165 ins; 100 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1697.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697 PR: https://git.openjdk.org/jfx/pull/1697 From angorya at openjdk.org Fri Feb 7 18:44:35 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 18:44:35 GMT Subject: RFR: 8348100: Tooltips cannot be instantiated on background thread [v2] In-Reply-To: References: Message-ID: > Navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing a NPE. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into 8348100.tootlip.thread.safety - Merge remote-tracking branch 'origin/master' into 8348100.tootlip.thread.safety - cleanup - tooltip test - Merge branch '8348423.node.thread.safety' into 8348100.tootlip.thread.safety - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - skip tests - jiggler - tooltip test - better name - ... and 8 more: https://git.openjdk.org/jfx/compare/2cf9779b...3ba9c9a2 ------------- Changes: https://git.openjdk.org/jfx/pull/1696/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1696&range=01 Stats: 51 lines in 2 files changed: 46 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1696.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1696/head:pull/1696 PR: https://git.openjdk.org/jfx/pull/1696 From angorya at openjdk.org Fri Feb 7 19:19:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 19:19:53 GMT Subject: RFR: 8348100: Tooltips cannot be instantiated on background thread [v3] In-Reply-To: References: Message-ID: > ## Root Cause > navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing the NPE. The null parent comes from a static Toolkit.BEHAVIOR field. > > ## Solution > avoid that code path if not in the fx application thread. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: behavior ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1696/files - new: https://git.openjdk.org/jfx/pull/1696/files/3ba9c9a2..6f48657a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1696&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1696&range=01-02 Stats: 55 lines in 2 files changed: 24 ins; 24 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1696.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1696/head:pull/1696 PR: https://git.openjdk.org/jfx/pull/1696 From kcr at openjdk.org Fri Feb 7 19:19:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 19:19:53 GMT Subject: RFR: 8348100: Tooltips cannot be instantiated on background thread [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 19:16:48 GMT, Andy Goryachev wrote: >> ## Root Cause >> navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing the NPE. The null parent comes from a static Toolkit.BEHAVIOR field. >> >> ## Solution >> avoid that code path if not in the fx application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > behavior Looks good now. I confirm that the new test fails reliably without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1696#pullrequestreview-2602617890 From angorya at openjdk.org Fri Feb 7 20:47:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 20:47:20 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation I am unable to reproduce OOM on Windows 11 with the fix (I did see the OOM earlier when it was failing before the fix). I've tried the unmodified test, as well as the extended version with the DURATION doubled to 10 seconds and added `@RepeatedTest(value = 5)` to the `pagination()` test. Same extended test passes just fine on macOS. A cursory look at the Pagination/PaginationSkin code reveals no obvious candidates for memory leaks. Maybe try running it again, now that it has the text layout fixes as well? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644090529 From kcr at openjdk.org Fri Feb 7 20:55:24 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 20:55:24 GMT Subject: [jfx24u] RFR: Merge jfx:jfx24 Message-ID: Clean merge from `jfx:jfx24`. ------------- Commit messages: - Merge remote-tracking branch 'jfx/jfx24' into merge-jfx-jfx24-to-master-2025-02-07 - 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on aarch64 - 8348744: Application window not always activated on macOS 15 - 8348736: RichTextArea clamp and getText The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx24u/pull/3/files Stats: 249 lines in 9 files changed: 176 ins; 54 del; 19 mod Patch: https://git.openjdk.org/jfx24u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx24u/pull/3 From martinfox656 at gmail.com Fri Feb 7 21:00:48 2025 From: martinfox656 at gmail.com (Martin Fox) Date: Fri, 7 Feb 2025 13:00:48 -0800 Subject: [External] : Re: Focus delegation API In-Reply-To: References: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com> Message-ID: > On Feb 6, 2025, at 11:52?PM, Michael Strau? wrote: > >> This PR uses an event dispatcher to provide a cleaner way of channeling keyboard events to another node. I haven?t prototyped the code but I suspect a Control could do this using the existing API without any changes to the Node class. >> This PR also provides an API to query a node?s delegate, finally making the delegation public. This could also be an aspect of a Control rather than a Node. > > I'm not sure you could do that. The redirecting event dispatcher > ensures that on each level of abstraction, you'll see events exactly > how you would expect to see them in isolation. I should have been clearer. In your PR the retargeting event dispatcher is added in Node.buildEventDispatchChain. I was thinking that it could be added in Control.buildEventDispatchChain. So I was playing devil?s advocate and suggesting that all of this get moved to Control. After all it seems like a lot of machinery to add to Node to clean up the implementation of a small number of controls. But on re-reading the PR I see that it?s the child of the delegating node that?s adding the dispatcher. Could you elaborate on why that is? It looks like you?re trying to ensure that the re-targeting of the event happens after the Control is done processing it even if a Control subclass overrides buildEventDispatchChain. I?m fine with adding focus delegation to Node instead of Control. In fact I would recommend it since it provides a clean way of getting InputMethod events working. > That's another aspect of the "consistency story" that this proposal > tries to tell: you should be able to reason about the sub-graph of a > Control in the same way as you reason about a top-level graph. If your > control receives input, then it should also be focused. I should have asked a different question. Is the focused flag being set to ensure the focus ring shows up? Or is it being set for some other reason and the focus ring is an unwelcome side-effect? I?m trying to get a handle on what parts of the system rely on this flag because the documentation is incorrect and the implementation is murky. For example, the ListView and TreeView manipulate the focused flag in surprising ways and it?s not entirely clear if this is just bookkeeping or if they?re also trying to invoke some specific behavior in another part of the system (like CSS). > I think that a node that is disabled, not editable, or not focus > traversable should probably not be eligible to be a focus delegate. > That would be inconsistent with top-level graphs. I don?t think a ComboBox?s editor should be focus traversable since the user should never be able to traverse to it. I?m not sure how you would enforce these restrictions. The enabled state is a property of Node but the editable state is not. This raises another question. Can the focus delegate of the focusOwner change dynamically? For example, what if the editor inside a ComboBox changes to an enabled state while the ComboBox is the focusOwner? I ask because the code that enables and disables InputMethod events queries state and needs to be aware of changes to that state. If we extend that state to include delegates (and I think we should) we need to know when a delegate might change. From kcr at openjdk.org Fri Feb 7 21:13:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 21:13:17 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: <_QraWIEbekyGdX4wVMxrYg0dLJJmiQTeHfQ7v0yy8PI=.9a8a6f28-1184-4c4c-835e-1ed641235036@github.com> On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation I still see the OOM. Are you running it from gradle? Here is the command line that will reproduce it, after first building with: "`gradle sdk shims`": gradle --info -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true \ :systemTests:test --tests NodeInitializationStressTest.pagination ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644134162 From kcr at openjdk.org Fri Feb 7 21:17:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 21:17:14 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation I also see the OOM on Mac. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644140495 From kcr at openjdk.org Fri Feb 7 21:19:33 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 21:19:33 GMT Subject: [jfx24u] RFR: Merge jfx:jfx24 [v2] In-Reply-To: References: Message-ID: > Clean merge from `jfx:jfx24`. 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 three additional commits since the last revision: - Merge remote-tracking branch 'jfx/jfx24' into merge-jfx-jfx24-to-master-2025-02-07 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Reviewed-by: jvos Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6 - 8347600: Change JavaFX release version to 24.0.1 in jfx24u Reviewed-by: jvos ------------- Changes: - all: https://git.openjdk.org/jfx24u/pull/3/files - new: https://git.openjdk.org/jfx24u/pull/3/files/02198930..02198930 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx24u&pr=3&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx24u&pr=3&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx24u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx24u/pull/3 From kcr at openjdk.org Fri Feb 7 21:19:33 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 21:19:33 GMT Subject: [jfx24u] Integrated: Merge jfx:jfx24 In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 20:51:24 GMT, Kevin Rushforth wrote: > Clean merge from `jfx:jfx24`. This pull request has now been integrated. Changeset: ec6b68c3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx24u/commit/ec6b68c37b44fb1fc5eba0e3b6572649ff9692ee Stats: 249 lines in 9 files changed: 176 ins; 54 del; 19 mod Merge ------------- PR: https://git.openjdk.org/jfx24u/pull/3 From angorya at openjdk.org Fri Feb 7 21:41:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 21:41:17 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation I see the problem with gradle (I was running it in Eclipse). We apparently set `-Xmx512m` which is simply inadequate. We should at least double that, or even go to 2GB. Where is it being set? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644176686 From kcr at openjdk.org Fri Feb 7 21:52:32 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 21:52:32 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: <-ocBuTpJvvBXk4A3BkYDEZtxgDGkfrMvmIs5ncsTZpk=.ff57db44-509e-44db-9c8e-08d2457cb7fc@github.com> On Fri, 7 Feb 2025 21:38:15 GMT, Andy Goryachev wrote: > I see the problem with gradle (I was running it in Eclipse). We apparently set -Xmx512m which is simply inadequate. We should at least double that, or even go to 2GB. > > Where is it being set? The default is set by the gradle installation itself, which is not controlled by us. I know you can bump the memory with a gradle option on the command line (which we do for our CI builds, but we just set it to 512Mb). We can trivially change our CI test script, but I'd be hesitant to require every developer to set that on the command line. A better solution might be to set the max heap to 1Gb in the system tests project in `build.gradle`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644192413 From angorya at openjdk.org Fri Feb 7 21:59:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 21:59:19 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <-ocBuTpJvvBXk4A3BkYDEZtxgDGkfrMvmIs5ncsTZpk=.ff57db44-509e-44db-9c8e-08d2457cb7fc@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> <-ocBuTpJvvBXk4A3BkYDEZtxgDGkfrMvmIs5ncsTZpk=.ff57db44-509e-44db-9c8e-08d2457cb7fc@github.com> Message-ID: On Fri, 7 Feb 2025 21:49:24 GMT, Kevin Rushforth wrote: > A better solution might be to set the max heap to 1Gb in the system tests project in `build.gradle`. created https://bugs.openjdk.org/browse/JDK-8349679 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644201952 From mstrauss at openjdk.org Fri Feb 7 22:06:22 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 7 Feb 2025 22:06:22 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 07:28:32 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: > > Revert "Addressed review comment" > > This reverts commit 60d4ba92b997be9937f0984761b278b21de816e7. Node:9099 `@param timer the transition timer` --> `@param propertyName the CSS name of the targeted property` Node:9082 add `@param propertyName the CSS name of the targeted property` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2644210978 From kcr at openjdk.org Fri Feb 7 22:36:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 22:36:16 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation A quick test suggests that there is still something up with Pagination that increasing the memory won't fully resolve. Even bumping it up to 2Gb fails sometimes on my Mac (e.g., if I increase the duration to 10 sec). I added `-verbose:gc` and the memory shoots up to almost 2Gb and doesn't really ever go down. None of the other tests come even close to hitting a memory problem, and when a GC happens, the memory in use drops down to about 12-15 Mbytes (not surprising given that the entire test suite runs with the default heap size if pagination is disabled). More study is needed, so let's pick this up next week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644250937 From angorya at openjdk.org Fri Feb 7 23:00:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 23:00:37 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v3] In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: gc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1698/files - new: https://git.openjdk.org/jfx/pull/1698/files/a3330b2d..300b269d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=01-02 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1698.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1698/head:pull/1698 PR: https://git.openjdk.org/jfx/pull/1698 From angorya at openjdk.org Fri Feb 7 23:00:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 23:00:37 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v2] In-Reply-To: <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> <5Np1IMn2GTqNjPnDYkEFHh0ACpMub9Qi9EL6njSBOlk=.623d3c04-c906-4f07-8f60-3cf68a3c52a9@github.com> Message-ID: On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation it looks like the amount of garbage generated during this test exceeds the ability of gc to collect it. adding System.gc() to the test allows it to run even after -Xmx500m, though I still would like to increase the heap size in [JDK-8349679](https://bugs.openjdk.org/browse/JDK-8349679) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2644279538 From angorya at openjdk.org Fri Feb 7 23:23:22 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 7 Feb 2025 23:23:22 GMT Subject: RFR: 8349679: build.gradle: increase system test memory limit to 1GB Message-ID: Increased max heap size for system tests from 521Mb to 1000Mb. ------------- Commit messages: - increase max heap size for system tests Changes: https://git.openjdk.org/jfx/pull/1701/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1701&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349679 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1701.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1701/head:pull/1701 PR: https://git.openjdk.org/jfx/pull/1701 From credmond at certak.com Sat Feb 8 12:31:47 2025 From: credmond at certak.com (Cormac Redmond) Date: Sat, 8 Feb 2025 12:31:47 +0000 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: References: Message-ID: Hi, I am surprised nobody else sees this bug as a higher-priority conversation point. It's troubling to see how running one self-contained application can break another self-contained application (because of a cache that most JFX devs wouldn't even know exist). If one well-behaved JFX application cannot delete/replace a file JFX cache on start-up, because another well-behaved JFX application is using that cached file (it will be if built on the same JFX version) -- then the application will not run, at all. And as I explained earlier, this is a likely occurring scenario in the wild -- the only reason this bug isn't more prevalent /reported / noticeable, is that it's not too likely for a user to have two JFX applications using the same JavaFX version, on their machine. But that's down to pure coincidence / chance. I wouldn't say the same for Electron or Flutter, etc. If they had this bug, it would be noticed and it would be news. Also, the creators of these applications would have no idea that their application is not starting, nor would the users know why. By the way, the problem is not just about *signed* DLLs + checksums, obviously. It would occur if the DLLs are different for any other reason too, obviously, and the authors of NativeLibLoader thought this possibility is high enough to do the checksum + delete + replace check. The application shouldn't silently fail because of a cache management bug. Regards, *Cormac Redmond* Software Engineer, Certak Ltd. e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com On Thu, 6 Feb 2025 at 19:56, Cormac Redmond wrote: > Hi, > > I have found a "serious" bug, where two completely independent JFX > applications, both with their own embedded runtime (built with jlink & > jpackage) & using the same JavaFX version, are unable to run > simultaneously, because of the JFX cache -- at least on Windows. > > When trying to run any application, NativeLibLoader does a checksum on > DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); > and tries to delete any files that exist where the checksums do not match > (in order to replace them): > > if (!Arrays.equals(isHash, fileHash)) { >> Files.delete(f.toPath()); >> } > > > But a second application *fails* to start, as it is unable to delete > these files because they're in use by the first application (see stacktrace > below). > > But why are the checksums different, shouldn't they be the same? They are > different because the DLLs are signed by the builder of the applications -- > different authors and different timestamps. So the DLL checksums will be > different despite the DLLs being the same, in terms of the JFX version. > > Why are these JFX DLLs signed by the authors? Because for some reason, > they come *unsigned*, and all DLLs when packaged *should* be signed, > including any embedded in JARs, to avoid alarming Windows Defender warnings > and mistrust, etc. There's no point spending a small fortune on Windows > code-signing certs and shipping with any unsigned third-party DLLs > (including any embedded in JARs). You might sign your own binaries and any > unsigned third-party binaries. Similarly for MacOS, everything, including > embedded native libs in JARs, etc., needs to be signed for gatekeeper & > notarization to allow it. > > So it would be better if JFX DLLs came signed, to avoid forcing developers > to do it (which would also avoid this checksum mishap). Or, if developers > need to sign Oracle's DLLs, then this checksum approach isn't suitable. > Also, there should really be a proper fallback in place -- a cache bug > should not have such a catastrophic outcome. > > FYI: JLink also removes signatures from a bunch of JDK DLLs when > assembling the runtime, but leaves a bunch of Windows DLLs > untouched. Personally, I'd prefer all DLLs to come signed, and let the > developers re-sign if they want. Removing the signatures is adding > unnecessary hurdles for folks, for no benefit I can see. > > Anyway, example stacktrace: > > Loading D3D native library ... >> WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program >> Files\KafkIO\bin\prism_d3d.dll >> Loading library prism_d3d from resource failed: >> java.nio.file.AccessDeniedException: C:\Users\xyz >> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >> java.nio.file.AccessDeniedException: C:\Users\xyz >> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >> at >> java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) >> at >> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >> at >> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >> at >> java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) >> at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown >> Source) >> at java.base/java.nio.file.Files.delete(Unknown Source) >> at >> com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) >> at >> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) >> at >> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) >> at >> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) >> at >> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >> at >> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >> at java.base/java.security.AccessController.doPrivileged(Unknown >> Source) >> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Unknown Source) >> at java.base/java.lang.Class.forName(Unknown Source) >> at >> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >> at >> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >> at >> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >> at java.base/java.lang.Thread.run(Unknown Source) >> GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline >> java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: >> C:\Program >> Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program >> Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files >> (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program >> Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program >> Files\SafeNet\Authentication\SAC\x64;C:\Program >> Files\SafeNet\Authentication\SAC\x32;C:\Program >> Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ >> xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz >> \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz >> \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz \scoop\shims;C:\Users\x >> yz \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program >> Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. >> at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) >> at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) >> at java.base/java.lang.System.loadLibrary(Unknown Source) >> at >> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) >> at >> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >> at >> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >> at java.base/java.security.AccessController.doPrivileged(Unknown >> Source) >> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >> at java.base/java.lang.Class.forName0(Native Method) >> at java.base/java.lang.Class.forName(Unknown Source) >> at java.base/java.lang.Class.forName(Unknown Source) >> at >> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >> at >> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >> at >> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >> at java.base/java.lang.Thread.run(Unknown Source) > > > > Kind Regards, > Cormac > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Sat Feb 8 12:49:38 2025 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 8 Feb 2025 13:49:38 +0100 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: References: Message-ID: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> I think that went a bit under the radar as this only occurs when using the maven dependencies. The SDK and jmod downloads do not have that issue as they don't copy DLLs into any temp directory. Only the maven jars have to do this. About signing any JavaFX DLLs, that would indeed be a good addition considering all other JDK DLLs are signed. Best Christopher Schnick On 08/02/2025 13:31, Cormac Redmond wrote: > Hi, > > I am surprised nobody else sees this bug as a higher-priority > conversation point. > > It's troubling to see how running one self-contained application can > break another self-contained application (because of a cache that most > JFX devs wouldn't even know exist). > > If one well-behaved JFX application cannot delete/replace a file JFX > cache on start-up, because another well-behaved JFX application is > using that cached file (it will be if built on the same JFX version) > -- then the application will not run, at all. > > And as I explained earlier, this is a likely occurring scenario in the > wild -- the only reason this bug isn't more prevalent /reported / > noticeable, is that it's not too likely for a user to have two JFX > applications using the same JavaFX version, on their machine. But > that's down to pure coincidence / chance. I wouldn't say the same for > Electron or Flutter, etc. If they had this bug, it would be noticed > and it would be news. > > Also, the creators of these applications would have no idea that their > application is not starting, nor would the users know why. > > By the way, the problem is not just about *signed* DLLs + checksums, > obviously. It would occur if the DLLs are different for any other > reason?too, obviously, and the authors of NativeLibLoader thought this > possibility is high enough to do the checksum?+ delete + replace > check. The application shouldn't silently fail because of a cache > management bug. > > > > > Regards, > * > * > *Cormac Redmond* > Software Engineer, Certak Ltd. > * > * > e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com > > > > > On Thu, 6 Feb 2025 at 19:56, Cormac Redmond wrote: > > Hi, > > I have found a "serious"?bug, where two completely independent JFX > applications,?both with their own embedded runtime (built with > jlink & jpackage) & using the same JavaFX version, are unable to > run simultaneously, because of the JFX cache -- at least on Windows. > > When trying to run any application, NativeLibLoader does a > checksum on DLLs in the > cache?(e.g.:?C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); > and tries to delete any files that exist where the checksums do > not match (in order to replace them): > > ?if (!Arrays.equals(isHash, fileHash)) { > ? ? ? ? ? ? ? ? Files.delete(f.toPath()); > ? ? ? ? ? ? } > > > But a second application _fails_?to start, as it is unable to > delete these files because they're in use by the first application > (see stacktrace below). > > But why are the checksums different, shouldn't they be the same? > They are different because the DLLs are signed by the builder of > the applications -- different authors and different timestamps. So > the DLL checksums will be different despite the DLLs being the > same, in terms of the JFX version. > > Why are these JFX DLLs signed by the authors? Because for some > reason, they come _unsigned_, and all DLLs when packaged > *_should_*?be signed, including any embedded in JARs, to avoid > alarming?Windows Defender warnings and mistrust, etc. There's no > point spending a small fortune on Windows code-signing certs and > shipping with any unsigned third-party DLLs (including any > embedded in JARs). You might sign your own binaries and any > unsigned third-party binaries. Similarly for MacOS, everything, > including embedded native libs in JARs, etc., needs to be signed > for gatekeeper & notarization to allow it. > > So it would be better if JFX DLLs came signed, to avoid forcing > developers to do it (which would also avoid this checksum mishap). > Or, if developers need to sign Oracle's DLLs, then this checksum > approach isn't suitable. Also, there should really be a proper > fallback in place -- a cache bug should not have such?a > catastrophic outcome. > > FYI: JLink also removes signatures from a bunch of JDK DLLs when > assembling the runtime, but leaves a bunch of Windows DLLs > untouched.?Personally, I'd prefer all DLLs to come signed, and let > the developers re-sign if they want. Removing the signatures is > adding unnecessary?hurdles for folks, for no benefit?I can see. > > Anyway, example stacktrace: > > Loading D3D native library ... > WARNING: java.lang.UnsatisfiedLinkError: Can't load library: > C:\Program Files\KafkIO\bin\prism_d3d.dll > Loading library prism_d3d from resource failed: > java.nio.file.AccessDeniedException: > C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll > java.nio.file.AccessDeniedException: > C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll > ? ? ? ? at > java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown > Source) > ? ? ? ? at > java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown > Source) > ? ? ? ? at > java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown > Source) > ? ? ? ? at > java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown > Source) > ? ? ? ? at > java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown > Source) > ? ? ? ? at java.base/java.nio.file.Files.delete(Unknown Source) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) > ? ? ? ? at > com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) > ? ? ? ? at > java.base/java.security.AccessController.doPrivileged(Unknown > Source) > ? ? ? ? at > com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) > ? ? ? ? at java.base/java.lang.Class.forName0(Native Method) > ? ? ? ? at java.base/java.lang.Class.forName(Unknown Source) > ? ? ? ? at java.base/java.lang.Class.forName(Unknown Source) > ? ? ? ? at > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) > ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) > ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > ? ? ? ? at java.base/java.lang.Thread.run(Unknown Source) > GraphicsPipeline.createPipeline failed for > com.sun.prism.d3d.D3DPipeline > java.lang.UnsatisfiedLinkError: no prism_d3d in > java.library.path: C:\Program > Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program > Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program?Files > (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program > Files\dotnet\;C:\Program Files\Git\cmd;C:\Program > Files\7-Zip;C:\Program > Files\SafeNet\Authentication\SAC\x64;C:\Program > Files\SafeNet\Authentication\SAC\x32;C:\Program > Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz\scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz\scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz > \scoop\shims;C:\Users\xyz > \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program > Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program > Files\KafkIO\app;. > ? ? ? ? at java.base/java.lang.ClassLoader.loadLibrary(Unknown > Source) > ? ? ? ? at java.base/java.lang.Runtime.loadLibrary0(Unknown > Source) > ? ? ? ? at java.base/java.lang.System.loadLibrary(Unknown Source) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) > ? ? ? ? at > com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) > ? ? ? ? at > com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) > ? ? ? ? at > java.base/java.security.AccessController.doPrivileged(Unknown > Source) > ? ? ? ? at > com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) > ? ? ? ? at java.base/java.lang.Class.forName0(Native Method) > ? ? ? ? at java.base/java.lang.Class.forName(Unknown Source) > ? ? ? ? at java.base/java.lang.Class.forName(Unknown Source) > ? ? ? ? at > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) > ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) > ? ? ? ? at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > ? ? ? ? at java.base/java.lang.Thread.run(Unknown Source) > > > > Kind Regards, > Cormac > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From credmond at certak.com Sat Feb 8 17:35:00 2025 From: credmond at certak.com (Cormac Redmond) Date: Sat, 8 Feb 2025 17:35:00 +0000 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> References: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> Message-ID: Hi, Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods (as many do). And the clashing application in question, must be the same. But this is a real problem that occurred with a real user, and I only have a handful of users. Oracle signing the JFX DLLs, while an improvement, would still leave the following problems wide open: - There's no way to stop a developer (or some build tool) from re-signing or removing signature from signed DLLs, in which case this problem can still re-occur - In the event of a genuine difference of a DLLs (under the same cache folder version), if the DLL cannot be deleted (to be replaced), because a running application application is using it -- a completely feasibly scenario -- then we have one application breaking another. Also, the developers shipping apps are in full control of the JFX JARs, their DLLs, and the *reported" javafx.version and javafx.runtime.version. E.g., I could have JFX 21.0.5 in a JFX 23.0.2 cache folder if I wanted simply by changing javafx.runtime.version (or javafx.cachedir). It's far too brittle. Regards, *Cormac Redmond* Software Engineer, Certak Ltd. e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com On Sat, 8 Feb 2025 at 12:49, Christopher Schnick wrote: > I think that went a bit under the radar as this only occurs when using the > maven dependencies. The SDK and jmod downloads do not have that issue as > they don't copy DLLs into any temp directory. Only the maven jars have to > do this. > > About signing any JavaFX DLLs, that would indeed be a good addition > considering all other JDK DLLs are signed. > > Best > Christopher Schnick > On 08/02/2025 13:31, Cormac Redmond wrote: > > Hi, > > I am surprised nobody else sees this bug as a higher-priority conversation > point. > > It's troubling to see how running one self-contained application can break > another self-contained application (because of a cache that most JFX devs > wouldn't even know exist). > > If one well-behaved JFX application cannot delete/replace a file JFX cache > on start-up, because another well-behaved JFX application is using that > cached file (it will be if built on the same JFX version) -- then the > application will not run, at all. > > And as I explained earlier, this is a likely occurring scenario in the > wild -- the only reason this bug isn't more prevalent /reported / > noticeable, is that it's not too likely for a user to have two JFX > applications using the same JavaFX version, on their machine. But that's > down to pure coincidence / chance. I wouldn't say the same for Electron or > Flutter, etc. If they had this bug, it would be noticed and it would be > news. > > Also, the creators of these applications would have no idea that their > application is not starting, nor would the users know why. > > By the way, the problem is not just about *signed* DLLs + checksums, > obviously. It would occur if the DLLs are different for any other > reason too, obviously, and the authors of NativeLibLoader thought this > possibility is high enough to do the checksum + delete + replace check. The > application shouldn't silently fail because of a cache management bug. > > > > > Regards, > > *Cormac Redmond* > Software Engineer, Certak Ltd. > > e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com > > > > On Thu, 6 Feb 2025 at 19:56, Cormac Redmond wrote: > >> Hi, >> >> I have found a "serious" bug, where two completely independent JFX >> applications, both with their own embedded runtime (built with jlink & >> jpackage) & using the same JavaFX version, are unable to run >> simultaneously, because of the JFX cache -- at least on Windows. >> >> When trying to run any application, NativeLibLoader does a checksum on >> DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); >> and tries to delete any files that exist where the checksums do not match >> (in order to replace them): >> >> if (!Arrays.equals(isHash, fileHash)) { >>> Files.delete(f.toPath()); >>> } >> >> >> But a second application *fails* to start, as it is unable to delete >> these files because they're in use by the first application (see stacktrace >> below). >> >> But why are the checksums different, shouldn't they be the same? They are >> different because the DLLs are signed by the builder of the applications -- >> different authors and different timestamps. So the DLL checksums will be >> different despite the DLLs being the same, in terms of the JFX version. >> >> Why are these JFX DLLs signed by the authors? Because for some reason, >> they come *unsigned*, and all DLLs when packaged *should* be signed, >> including any embedded in JARs, to avoid alarming Windows Defender warnings >> and mistrust, etc. There's no point spending a small fortune on Windows >> code-signing certs and shipping with any unsigned third-party DLLs >> (including any embedded in JARs). You might sign your own binaries and any >> unsigned third-party binaries. Similarly for MacOS, everything, including >> embedded native libs in JARs, etc., needs to be signed for gatekeeper & >> notarization to allow it. >> >> So it would be better if JFX DLLs came signed, to avoid forcing >> developers to do it (which would also avoid this checksum mishap). Or, if >> developers need to sign Oracle's DLLs, then this checksum approach isn't >> suitable. Also, there should really be a proper fallback in place -- a >> cache bug should not have such a catastrophic outcome. >> >> FYI: JLink also removes signatures from a bunch of JDK DLLs when >> assembling the runtime, but leaves a bunch of Windows DLLs >> untouched. Personally, I'd prefer all DLLs to come signed, and let the >> developers re-sign if they want. Removing the signatures is adding >> unnecessary hurdles for folks, for no benefit I can see. >> >> Anyway, example stacktrace: >> >> Loading D3D native library ... >>> WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program >>> Files\KafkIO\bin\prism_d3d.dll >>> Loading library prism_d3d from resource failed: >>> java.nio.file.AccessDeniedException: C:\Users\xyz >>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>> java.nio.file.AccessDeniedException: C:\Users\xyz >>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>> at >>> java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) >>> at >>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>> at >>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>> at >>> java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) >>> at >>> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) >>> at java.base/java.nio.file.Files.delete(Unknown Source) >>> at >>> com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) >>> at >>> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) >>> at >>> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) >>> at >>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) >>> at >>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>> at >>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>> at java.base/java.security.AccessController.doPrivileged(Unknown >>> Source) >>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Unknown Source) >>> at java.base/java.lang.Class.forName(Unknown Source) >>> at >>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>> at >>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>> at >>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>> at java.base/java.lang.Thread.run(Unknown Source) >>> GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline >>> java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: >>> C:\Program >>> Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program >>> Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files >>> (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program >>> Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program >>> Files\SafeNet\Authentication\SAC\x64;C:\Program >>> Files\SafeNet\Authentication\SAC\x32;C:\Program >>> Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ >>> xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz >>> \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz >>> \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz \scoop\shims;C:\Users\x >>> yz \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program >>> Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. >>> at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) >>> at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) >>> at java.base/java.lang.System.loadLibrary(Unknown Source) >>> at >>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) >>> at >>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>> at >>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>> at java.base/java.security.AccessController.doPrivileged(Unknown >>> Source) >>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>> at java.base/java.lang.Class.forName0(Native Method) >>> at java.base/java.lang.Class.forName(Unknown Source) >>> at java.base/java.lang.Class.forName(Unknown Source) >>> at >>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>> at >>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>> at >>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>> at java.base/java.lang.Thread.run(Unknown Source) >> >> >> >> Kind Regards, >> Cormac >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at weblite.ca Sat Feb 8 18:16:41 2025 From: steve at weblite.ca (Steve Hannah) Date: Sat, 8 Feb 2025 10:16:41 -0800 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: References: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> Message-ID: This also doesn't seem to affect apps running with the zulufx distributions (the JRE with JavaFX bundled). E.g. this build of JavaFX ensemble https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble It uses Java 19, and OpenJFX 20, and it doesn't seem to create an .openjfx directory anywhere that I can find. Therefore, you can deploy your app using jDeploy and it won't have this issue. (Disclosure, I'm the creator of jDeploy). Similarly, if you bundle your app with a ZuluFX distribution, and strip out your maven jars (which is what jDeploy does), you won't have this issue. Steve On Sat, Feb 8, 2025 at 9:35?AM Cormac Redmond wrote: > Hi, > > Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods > (as many do). And the clashing application in question, must be the same. > But this is a real problem that occurred with a real user, and I only have > a handful of users. > > Oracle signing the JFX DLLs, while an improvement, would still leave the > following problems wide open: > > - There's no way to stop a developer (or some build tool) from > re-signing or removing signature from signed DLLs, in which case this > problem can still re-occur > - In the event of a genuine difference of a DLLs (under the same cache > folder version), if the DLL cannot be deleted (to be replaced), because a > running application application is using it -- a completely feasibly > scenario -- then we have one application breaking another. > > Also, the developers shipping apps are in full control of the JFX JARs, > their DLLs, and the *reported" javafx.version and javafx.runtime.version. > E.g., I could have JFX 21.0.5 in a JFX 23.0.2 cache folder if I wanted > simply by changing javafx.runtime.version (or javafx.cachedir). > > It's far too brittle. > > > > Regards, > > *Cormac Redmond* > Software Engineer, Certak Ltd. > > e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com > > > > > On Sat, 8 Feb 2025 at 12:49, Christopher Schnick > wrote: > >> I think that went a bit under the radar as this only occurs when using >> the maven dependencies. The SDK and jmod downloads do not have that issue >> as they don't copy DLLs into any temp directory. Only the maven jars have >> to do this. >> >> About signing any JavaFX DLLs, that would indeed be a good addition >> considering all other JDK DLLs are signed. >> >> Best >> Christopher Schnick >> On 08/02/2025 13:31, Cormac Redmond wrote: >> >> Hi, >> >> I am surprised nobody else sees this bug as a higher-priority >> conversation point. >> >> It's troubling to see how running one self-contained application can >> break another self-contained application (because of a cache that most JFX >> devs wouldn't even know exist). >> >> If one well-behaved JFX application cannot delete/replace a file JFX >> cache on start-up, because another well-behaved JFX application is using >> that cached file (it will be if built on the same JFX version) -- then the >> application will not run, at all. >> >> And as I explained earlier, this is a likely occurring scenario in the >> wild -- the only reason this bug isn't more prevalent /reported / >> noticeable, is that it's not too likely for a user to have two JFX >> applications using the same JavaFX version, on their machine. But that's >> down to pure coincidence / chance. I wouldn't say the same for Electron or >> Flutter, etc. If they had this bug, it would be noticed and it would be >> news. >> >> Also, the creators of these applications would have no idea that their >> application is not starting, nor would the users know why. >> >> By the way, the problem is not just about *signed* DLLs + checksums, >> obviously. It would occur if the DLLs are different for any other >> reason too, obviously, and the authors of NativeLibLoader thought this >> possibility is high enough to do the checksum + delete + replace check. The >> application shouldn't silently fail because of a cache management bug. >> >> >> >> >> Regards, >> >> *Cormac Redmond* >> Software Engineer, Certak Ltd. >> >> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >> >> >> >> On Thu, 6 Feb 2025 at 19:56, Cormac Redmond wrote: >> >>> Hi, >>> >>> I have found a "serious" bug, where two completely independent JFX >>> applications, both with their own embedded runtime (built with jlink & >>> jpackage) & using the same JavaFX version, are unable to run >>> simultaneously, because of the JFX cache -- at least on Windows. >>> >>> When trying to run any application, NativeLibLoader does a checksum on >>> DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); >>> and tries to delete any files that exist where the checksums do not match >>> (in order to replace them): >>> >>> if (!Arrays.equals(isHash, fileHash)) { >>>> Files.delete(f.toPath()); >>>> } >>> >>> >>> But a second application *fails* to start, as it is unable to delete >>> these files because they're in use by the first application (see stacktrace >>> below). >>> >>> But why are the checksums different, shouldn't they be the same? They >>> are different because the DLLs are signed by the builder of the >>> applications -- different authors and different timestamps. So the DLL >>> checksums will be different despite the DLLs being the same, in terms of >>> the JFX version. >>> >>> Why are these JFX DLLs signed by the authors? Because for some reason, >>> they come *unsigned*, and all DLLs when packaged *should* be signed, >>> including any embedded in JARs, to avoid alarming Windows Defender warnings >>> and mistrust, etc. There's no point spending a small fortune on Windows >>> code-signing certs and shipping with any unsigned third-party DLLs >>> (including any embedded in JARs). You might sign your own binaries and any >>> unsigned third-party binaries. Similarly for MacOS, everything, including >>> embedded native libs in JARs, etc., needs to be signed for gatekeeper & >>> notarization to allow it. >>> >>> So it would be better if JFX DLLs came signed, to avoid forcing >>> developers to do it (which would also avoid this checksum mishap). Or, if >>> developers need to sign Oracle's DLLs, then this checksum approach isn't >>> suitable. Also, there should really be a proper fallback in place -- a >>> cache bug should not have such a catastrophic outcome. >>> >>> FYI: JLink also removes signatures from a bunch of JDK DLLs when >>> assembling the runtime, but leaves a bunch of Windows DLLs >>> untouched. Personally, I'd prefer all DLLs to come signed, and let the >>> developers re-sign if they want. Removing the signatures is adding >>> unnecessary hurdles for folks, for no benefit I can see. >>> >>> Anyway, example stacktrace: >>> >>> Loading D3D native library ... >>>> WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program >>>> Files\KafkIO\bin\prism_d3d.dll >>>> Loading library prism_d3d from resource failed: >>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>> at >>>> java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) >>>> at >>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>> at >>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>> at >>>> java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) >>>> at >>>> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) >>>> at java.base/java.nio.file.Files.delete(Unknown Source) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>> at >>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>> at >>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>> at java.base/java.lang.Class.forName0(Native Method) >>>> at java.base/java.lang.Class.forName(Unknown Source) >>>> at java.base/java.lang.Class.forName(Unknown Source) >>>> at >>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>> at >>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>> at >>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>> at java.base/java.lang.Thread.run(Unknown Source) >>>> GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline >>>> java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: >>>> C:\Program >>>> Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program >>>> Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files >>>> (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program >>>> Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program >>>> Files\SafeNet\Authentication\SAC\x64;C:\Program >>>> Files\SafeNet\Authentication\SAC\x32;C:\Program >>>> Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ >>>> xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz >>>> \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz >>>> \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz \scoop\shims;C:\Users\ >>>> xyz \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program >>>> Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. >>>> at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) >>>> at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) >>>> at java.base/java.lang.System.loadLibrary(Unknown Source) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) >>>> at >>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>> at >>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>> at >>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>> at java.base/java.lang.Class.forName0(Native Method) >>>> at java.base/java.lang.Class.forName(Unknown Source) >>>> at java.base/java.lang.Class.forName(Unknown Source) >>>> at >>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>> at >>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>> at >>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>> at java.base/java.lang.Thread.run(Unknown Source) >>> >>> >>> >>> Kind Regards, >>> Cormac >>> >>> >>> -- Steve Hannah Web Lite Solutions Corp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Sat Feb 8 19:19:56 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 8 Feb 2025 19:19:56 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v4] 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Fixed javadoc for internal Node methods - Merge remote-tracking branch 'origin/master' into 8344367_Fix_mistakes_in_FX_API_docs - Revert "Addressed review comment" This reverts commit 60d4ba92b997be9937f0984761b278b21de816e7. - Addressed review comment - More corrections - Batch typo fixes - Fix mistakes in OpenJFX docs ------------- Changes: https://git.openjdk.org/jfx/pull/1642/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1642&range=03 Stats: 78 lines in 40 files changed: 1 ins; 0 del; 77 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 credmond at certak.com Sat Feb 8 21:01:20 2025 From: credmond at certak.com (Cormac Redmond) Date: Sat, 8 Feb 2025 21:01:20 +0000 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: References: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> Message-ID: Hi Steve, Thanks. I can also workaround it (with very limited changes) in another way by overriding javafx.runtime.version with something specific to my app, and its version (which will ultimately dictate the cache directory name) -- as the chances of having a clash then, are astronomically low. However, none of these things are solutions, but workarounds -- my stance is that it should not be up to the developer to firstly know this problem even exists (most won't), and then to workaround it by avoiding using certain JARs. It's not like we're building apps in un-documented or unusual ways, quite the opposite. Kind Regards, Cormac On Sat, 8 Feb 2025 at 18:16, Steve Hannah wrote: > This also doesn't seem to affect apps running with the zulufx > distributions (the JRE with JavaFX bundled). > > E.g. this build of JavaFX ensemble > https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble > It uses Java 19, and OpenJFX 20, and it doesn't seem to create an .openjfx > directory anywhere that I can find. > > Therefore, you can deploy your app using jDeploy and it won't have this > issue. (Disclosure, I'm the creator of jDeploy). Similarly, if you bundle > your app with a ZuluFX distribution, and strip out your maven jars (which > is what jDeploy does), you won't have this issue. > > Steve > > On Sat, Feb 8, 2025 at 9:35?AM Cormac Redmond wrote: > >> Hi, >> >> Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods >> (as many do). And the clashing application in question, must be the same. >> But this is a real problem that occurred with a real user, and I only have >> a handful of users. >> >> Oracle signing the JFX DLLs, while an improvement, would still leave the >> following problems wide open: >> >> - There's no way to stop a developer (or some build tool) from >> re-signing or removing signature from signed DLLs, in which case this >> problem can still re-occur >> - In the event of a genuine difference of a DLLs (under the same >> cache folder version), if the DLL cannot be deleted (to be replaced), >> because a running application application is using it -- a completely >> feasibly scenario -- then we have one application breaking another. >> >> Also, the developers shipping apps are in full control of the JFX JARs, >> their DLLs, and the *reported" javafx.version and javafx.runtime.version. >> E.g., I could have JFX 21.0.5 in a JFX 23.0.2 cache folder if I wanted >> simply by changing javafx.runtime.version (or javafx.cachedir). >> >> It's far too brittle. >> >> >> >> Regards, >> >> *Cormac Redmond* >> Software Engineer, Certak Ltd. >> >> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >> >> >> >> >> On Sat, 8 Feb 2025 at 12:49, Christopher Schnick >> wrote: >> >>> I think that went a bit under the radar as this only occurs when using >>> the maven dependencies. The SDK and jmod downloads do not have that issue >>> as they don't copy DLLs into any temp directory. Only the maven jars have >>> to do this. >>> >>> About signing any JavaFX DLLs, that would indeed be a good addition >>> considering all other JDK DLLs are signed. >>> >>> Best >>> Christopher Schnick >>> On 08/02/2025 13:31, Cormac Redmond wrote: >>> >>> Hi, >>> >>> I am surprised nobody else sees this bug as a higher-priority >>> conversation point. >>> >>> It's troubling to see how running one self-contained application can >>> break another self-contained application (because of a cache that most JFX >>> devs wouldn't even know exist). >>> >>> If one well-behaved JFX application cannot delete/replace a file JFX >>> cache on start-up, because another well-behaved JFX application is using >>> that cached file (it will be if built on the same JFX version) -- then the >>> application will not run, at all. >>> >>> And as I explained earlier, this is a likely occurring scenario in the >>> wild -- the only reason this bug isn't more prevalent /reported / >>> noticeable, is that it's not too likely for a user to have two JFX >>> applications using the same JavaFX version, on their machine. But that's >>> down to pure coincidence / chance. I wouldn't say the same for Electron or >>> Flutter, etc. If they had this bug, it would be noticed and it would be >>> news. >>> >>> Also, the creators of these applications would have no idea that their >>> application is not starting, nor would the users know why. >>> >>> By the way, the problem is not just about *signed* DLLs + checksums, >>> obviously. It would occur if the DLLs are different for any other >>> reason too, obviously, and the authors of NativeLibLoader thought this >>> possibility is high enough to do the checksum + delete + replace check. The >>> application shouldn't silently fail because of a cache management bug. >>> >>> >>> >>> >>> Regards, >>> >>> *Cormac Redmond* >>> Software Engineer, Certak Ltd. >>> >>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >>> >>> >>> >>> On Thu, 6 Feb 2025 at 19:56, Cormac Redmond wrote: >>> >>>> Hi, >>>> >>>> I have found a "serious" bug, where two completely independent JFX >>>> applications, both with their own embedded runtime (built with jlink & >>>> jpackage) & using the same JavaFX version, are unable to run >>>> simultaneously, because of the JFX cache -- at least on Windows. >>>> >>>> When trying to run any application, NativeLibLoader does a checksum on >>>> DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); >>>> and tries to delete any files that exist where the checksums do not match >>>> (in order to replace them): >>>> >>>> if (!Arrays.equals(isHash, fileHash)) { >>>>> Files.delete(f.toPath()); >>>>> } >>>> >>>> >>>> But a second application *fails* to start, as it is unable to delete >>>> these files because they're in use by the first application (see stacktrace >>>> below). >>>> >>>> But why are the checksums different, shouldn't they be the same? They >>>> are different because the DLLs are signed by the builder of the >>>> applications -- different authors and different timestamps. So the DLL >>>> checksums will be different despite the DLLs being the same, in terms of >>>> the JFX version. >>>> >>>> Why are these JFX DLLs signed by the authors? Because for some reason, >>>> they come *unsigned*, and all DLLs when packaged *should* be signed, >>>> including any embedded in JARs, to avoid alarming Windows Defender warnings >>>> and mistrust, etc. There's no point spending a small fortune on Windows >>>> code-signing certs and shipping with any unsigned third-party DLLs >>>> (including any embedded in JARs). You might sign your own binaries and any >>>> unsigned third-party binaries. Similarly for MacOS, everything, including >>>> embedded native libs in JARs, etc., needs to be signed for gatekeeper & >>>> notarization to allow it. >>>> >>>> So it would be better if JFX DLLs came signed, to avoid forcing >>>> developers to do it (which would also avoid this checksum mishap). Or, if >>>> developers need to sign Oracle's DLLs, then this checksum approach isn't >>>> suitable. Also, there should really be a proper fallback in place -- a >>>> cache bug should not have such a catastrophic outcome. >>>> >>>> FYI: JLink also removes signatures from a bunch of JDK DLLs when >>>> assembling the runtime, but leaves a bunch of Windows DLLs >>>> untouched. Personally, I'd prefer all DLLs to come signed, and let the >>>> developers re-sign if they want. Removing the signatures is adding >>>> unnecessary hurdles for folks, for no benefit I can see. >>>> >>>> Anyway, example stacktrace: >>>> >>>> Loading D3D native library ... >>>>> WARNING: java.lang.UnsatisfiedLinkError: Can't load library: >>>>> C:\Program Files\KafkIO\bin\prism_d3d.dll >>>>> Loading library prism_d3d from resource failed: >>>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>>> at >>>>> java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) >>>>> at >>>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>>> at >>>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>>> at >>>>> java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) >>>>> at >>>>> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) >>>>> at java.base/java.nio.file.Files.delete(Unknown Source) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>>> at >>>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>>> at >>>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>>> at java.base/java.lang.Class.forName0(Native Method) >>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>> at >>>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>>> at >>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>>> at >>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>>> at java.base/java.lang.Thread.run(Unknown Source) >>>>> GraphicsPipeline.createPipeline failed for >>>>> com.sun.prism.d3d.D3DPipeline >>>>> java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: >>>>> C:\Program >>>>> Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program >>>>> Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files >>>>> (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program >>>>> Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program >>>>> Files\SafeNet\Authentication\SAC\x64;C:\Program >>>>> Files\SafeNet\Authentication\SAC\x32;C:\Program >>>>> Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ >>>>> xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz >>>>> \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz >>>>> \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz >>>>> \scoop\shims;C:\Users\xyz >>>>> \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program >>>>> Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. >>>>> at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) >>>>> at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) >>>>> at java.base/java.lang.System.loadLibrary(Unknown Source) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) >>>>> at >>>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>>> at >>>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>>> at >>>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>>> at java.base/java.lang.Class.forName0(Native Method) >>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>> at >>>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>>> at >>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>>> at >>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>>> at java.base/java.lang.Thread.run(Unknown Source) >>>> >>>> >>>> >>>> Kind Regards, >>>> Cormac >>>> >>>> >>>> > > -- > Steve Hannah > Web Lite Solutions Corp. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Sun Feb 9 10:56:25 2025 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 9 Feb 2025 11:56:25 +0100 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: References: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> Message-ID: Hi Cormac, I understand the problem, and I agree it can be really annoying. It either needs better communication, or a fix. The maven artifacts are something we added with Gluon (hence not Oracle). As you said, windows signing certificates come with a price (and building hassle). The reason we started uploading those artifacts is mainly because developers are very used to the maven artifact approach during development. I believe this lowered the bar for JavaFX development after the JDK didn't ship with the JavaFX code anymore. A developer who just wants to explore using JavaFX is less likely to download an additional SDK or jmods. Simply adding a few lines in a pom.xml is something most developers are familiar with. For shipping applications, I strongly discourage this, and highly recommend the SDK/jmods approach. I can see now though that offering the "maven artifacts for developers" created higher expectations than intended. The problem you described is more or less documented in https://bugs.openjdk.org/browse/JDK-8316276 . There have been discussions (e.g. on the jigsaw list) in the past about this, as other projects (e.g. dl4j) have similar issues with jars containing native code. There is no standard approach in Java to deal with this, which is why the NativeLibLoader contains a bunch of logic that allows to invoke the code in the native libs from the classes in the same jar. That logic has been modified over the years, to account for specific issues (e.g. [1] and [2]), but it's not perfect. I'm not against signing those libraries (it is a net loss of money and time though), but as you noticed yourself, this won't fix all problems. We should probably make it more clear that the maven artifacts should not be used in production systems, and are for development only -- for developers by developers. - Johan [1] https://bugs.openjdk.org/browse/JDK-8317308 [2] https://bugs.openjdk.org/browse/JDK-8307536 On Sat, Feb 8, 2025 at 10:01?PM Cormac Redmond wrote: > Hi Steve, > > Thanks. I can also workaround it (with very limited changes) in another > way by overriding javafx.runtime.version with something specific to my > app, and its version (which will ultimately dictate the cache directory > name) -- as the chances of having a clash then, are astronomically low. > > However, none of these things are solutions, but workarounds -- my stance > is that it should not be up to the developer to firstly know this problem > even exists (most won't), and then to workaround it by avoiding using > certain JARs. It's not like we're building apps in un-documented or unusual > ways, quite the opposite. > > > Kind Regards, > Cormac > > On Sat, 8 Feb 2025 at 18:16, Steve Hannah wrote: > >> This also doesn't seem to affect apps running with the zulufx >> distributions (the JRE with JavaFX bundled). >> >> E.g. this build of JavaFX ensemble >> https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble >> It uses Java 19, and OpenJFX 20, and it doesn't seem to create an >> .openjfx directory anywhere that I can find. >> >> Therefore, you can deploy your app using jDeploy and it won't have this >> issue. (Disclosure, I'm the creator of jDeploy). Similarly, if you bundle >> your app with a ZuluFX distribution, and strip out your maven jars (which >> is what jDeploy does), you won't have this issue. >> >> Steve >> >> On Sat, Feb 8, 2025 at 9:35?AM Cormac Redmond >> wrote: >> >>> Hi, >>> >>> Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods >>> (as many do). And the clashing application in question, must be the same. >>> But this is a real problem that occurred with a real user, and I only have >>> a handful of users. >>> >>> Oracle signing the JFX DLLs, while an improvement, would still leave the >>> following problems wide open: >>> >>> - There's no way to stop a developer (or some build tool) from >>> re-signing or removing signature from signed DLLs, in which case this >>> problem can still re-occur >>> - In the event of a genuine difference of a DLLs (under the same >>> cache folder version), if the DLL cannot be deleted (to be replaced), >>> because a running application application is using it -- a completely >>> feasibly scenario -- then we have one application breaking another. >>> >>> Also, the developers shipping apps are in full control of the JFX JARs, >>> their DLLs, and the *reported" javafx.version and javafx.runtime.version. >>> E.g., I could have JFX 21.0.5 in a JFX 23.0.2 cache folder if I wanted >>> simply by changing javafx.runtime.version (or javafx.cachedir). >>> >>> It's far too brittle. >>> >>> >>> >>> Regards, >>> >>> *Cormac Redmond* >>> Software Engineer, Certak Ltd. >>> >>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >>> >>> >>> >>> >>> On Sat, 8 Feb 2025 at 12:49, Christopher Schnick >>> wrote: >>> >>>> I think that went a bit under the radar as this only occurs when using >>>> the maven dependencies. The SDK and jmod downloads do not have that issue >>>> as they don't copy DLLs into any temp directory. Only the maven jars have >>>> to do this. >>>> >>>> About signing any JavaFX DLLs, that would indeed be a good addition >>>> considering all other JDK DLLs are signed. >>>> >>>> Best >>>> Christopher Schnick >>>> On 08/02/2025 13:31, Cormac Redmond wrote: >>>> >>>> Hi, >>>> >>>> I am surprised nobody else sees this bug as a higher-priority >>>> conversation point. >>>> >>>> It's troubling to see how running one self-contained application can >>>> break another self-contained application (because of a cache that most JFX >>>> devs wouldn't even know exist). >>>> >>>> If one well-behaved JFX application cannot delete/replace a file JFX >>>> cache on start-up, because another well-behaved JFX application is using >>>> that cached file (it will be if built on the same JFX version) -- then the >>>> application will not run, at all. >>>> >>>> And as I explained earlier, this is a likely occurring scenario in the >>>> wild -- the only reason this bug isn't more prevalent /reported / >>>> noticeable, is that it's not too likely for a user to have two JFX >>>> applications using the same JavaFX version, on their machine. But that's >>>> down to pure coincidence / chance. I wouldn't say the same for Electron or >>>> Flutter, etc. If they had this bug, it would be noticed and it would be >>>> news. >>>> >>>> Also, the creators of these applications would have no idea that their >>>> application is not starting, nor would the users know why. >>>> >>>> By the way, the problem is not just about *signed* DLLs + checksums, >>>> obviously. It would occur if the DLLs are different for any other >>>> reason too, obviously, and the authors of NativeLibLoader thought this >>>> possibility is high enough to do the checksum + delete + replace check. The >>>> application shouldn't silently fail because of a cache management bug. >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> *Cormac Redmond* >>>> Software Engineer, Certak Ltd. >>>> >>>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >>>> >>>> >>>> >>>> On Thu, 6 Feb 2025 at 19:56, Cormac Redmond >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I have found a "serious" bug, where two completely independent JFX >>>>> applications, both with their own embedded runtime (built with jlink & >>>>> jpackage) & using the same JavaFX version, are unable to run >>>>> simultaneously, because of the JFX cache -- at least on Windows. >>>>> >>>>> When trying to run any application, NativeLibLoader does a checksum >>>>> on DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); >>>>> and tries to delete any files that exist where the checksums do not match >>>>> (in order to replace them): >>>>> >>>>> if (!Arrays.equals(isHash, fileHash)) { >>>>>> Files.delete(f.toPath()); >>>>>> } >>>>> >>>>> >>>>> But a second application *fails* to start, as it is unable to delete >>>>> these files because they're in use by the first application (see stacktrace >>>>> below). >>>>> >>>>> But why are the checksums different, shouldn't they be the same? They >>>>> are different because the DLLs are signed by the builder of the >>>>> applications -- different authors and different timestamps. So the DLL >>>>> checksums will be different despite the DLLs being the same, in terms of >>>>> the JFX version. >>>>> >>>>> Why are these JFX DLLs signed by the authors? Because for some reason, >>>>> they come *unsigned*, and all DLLs when packaged *should* be signed, >>>>> including any embedded in JARs, to avoid alarming Windows Defender warnings >>>>> and mistrust, etc. There's no point spending a small fortune on Windows >>>>> code-signing certs and shipping with any unsigned third-party DLLs >>>>> (including any embedded in JARs). You might sign your own binaries and any >>>>> unsigned third-party binaries. Similarly for MacOS, everything, including >>>>> embedded native libs in JARs, etc., needs to be signed for gatekeeper & >>>>> notarization to allow it. >>>>> >>>>> So it would be better if JFX DLLs came signed, to avoid forcing >>>>> developers to do it (which would also avoid this checksum mishap). Or, if >>>>> developers need to sign Oracle's DLLs, then this checksum approach isn't >>>>> suitable. Also, there should really be a proper fallback in place -- a >>>>> cache bug should not have such a catastrophic outcome. >>>>> >>>>> FYI: JLink also removes signatures from a bunch of JDK DLLs when >>>>> assembling the runtime, but leaves a bunch of Windows DLLs >>>>> untouched. Personally, I'd prefer all DLLs to come signed, and let the >>>>> developers re-sign if they want. Removing the signatures is adding >>>>> unnecessary hurdles for folks, for no benefit I can see. >>>>> >>>>> Anyway, example stacktrace: >>>>> >>>>> Loading D3D native library ... >>>>>> WARNING: java.lang.UnsatisfiedLinkError: Can't load library: >>>>>> C:\Program Files\KafkIO\bin\prism_d3d.dll >>>>>> Loading library prism_d3d from resource failed: >>>>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>>>> at >>>>>> java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) >>>>>> at >>>>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>>>> at >>>>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>>>> at >>>>>> java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) >>>>>> at >>>>>> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) >>>>>> at java.base/java.nio.file.Files.delete(Unknown Source) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>>>> at >>>>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>>>> at >>>>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>>>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>>>> at java.base/java.lang.Class.forName0(Native Method) >>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>> at >>>>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>>>> at >>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>>>> at >>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>>>> at java.base/java.lang.Thread.run(Unknown Source) >>>>>> GraphicsPipeline.createPipeline failed for >>>>>> com.sun.prism.d3d.D3DPipeline >>>>>> java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: >>>>>> C:\Program >>>>>> Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program >>>>>> Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files >>>>>> (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program >>>>>> Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program >>>>>> Files\SafeNet\Authentication\SAC\x64;C:\Program >>>>>> Files\SafeNet\Authentication\SAC\x32;C:\Program >>>>>> Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ >>>>>> xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz >>>>>> \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz >>>>>> \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz >>>>>> \scoop\shims;C:\Users\xyz >>>>>> \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program >>>>>> Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. >>>>>> at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) >>>>>> at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) >>>>>> at java.base/java.lang.System.loadLibrary(Unknown Source) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) >>>>>> at >>>>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>>>> at >>>>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>>>> at >>>>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>>>> at com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>>>> at java.base/java.lang.Class.forName0(Native Method) >>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>> at >>>>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>>>> at >>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>>>> at >>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>>>> at java.base/java.lang.Thread.run(Unknown Source) >>>>> >>>>> >>>>> >>>>> Kind Regards, >>>>> Cormac >>>>> >>>>> >>>>> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Sun Feb 9 17:57:57 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 9 Feb 2025 18:57:57 +0100 Subject: [External] : Re: Focus delegation API In-Reply-To: References: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com> Message-ID: > But on re-reading the PR I see that it?s the child of the delegating node that?s adding the dispatcher. Could you elaborate on why that is? I guess that's just the way I made it work. Implementing this in Control is not something I've thought about a lot. > I should have asked a different question. Is the focused flag being set to ensure the focus ring shows up? Or is it being set for some other reason and the focus ring is an unwelcome side-effect? > > I?m trying to get a handle on what parts of the system rely on this flag because the documentation is incorrect and the implementation is murky. For example, the ListView and TreeView manipulate the focused flag in surprising ways and it?s not entirely clear if this is just bookkeeping or if they?re also trying to invoke some specific behavior in another part of the system (like CSS). That's a good question. Let's start with the easy part: I think that tinkering with the focused flag is a bad idea. It looks like some controls do that to implement a scheme where a focused/selected cell is tracked in the context of ListView, TableView, etc. However, input focus and a "focused cell" are not the same thing, and it is confusing people: https://bugs.openjdk.org/browse/JDK-8317426 Controls should just stop doing that, and invent a new property for their "focused cell" thing. The other part of the question is whether we need nested focus flags at all. I think we probably need it because controls sometimes do certain things when they are focused. For example, TextInputControl shows a caret only when it is focused, and we want the caret to be visible if the TextInputControl is nested in another control. In general, if we want to support composite controls, where inner controls "just work", we most likely can't treat them differently than if they were top-level controls. > I don?t think a ComboBox?s editor should be focus traversable since the user should never be able to traverse to it. Yes, good point. > I?m not sure how you would enforce these restrictions. The enabled state is a property of Node but the editable state is not. Also a good point. > This raises another question. Can the focus delegate of the focusOwner change dynamically? For example, what if the editor inside a ComboBox changes to an enabled state while the ComboBox is the focusOwner? I ask because the code that enables and disables InputMethod events queries state and needs to be aware of changes to that state. If we extend that state to include delegates (and I think we should) we need to know when a delegate might change. I see no reason why a control shouldn't dynamically change what it returns from getFocusDelegate(). However, there's no notification mechanism that would indicate when something has changed. Would you need something like Scene.focusOwner(), but instead of containing the outermost focused node (like ComboBox), it contains the last node in the current delegation chain (TextField)? From mstrauss at openjdk.org Sun Feb 9 18:32:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 9 Feb 2025 18:32:17 GMT Subject: RFR: 8348100: Tooltips cannot be instantiated on background thread [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 19:19:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing the NPE. The null parent comes from a static Toolkit.BEHAVIOR field. >> >> ## Solution >> avoid that code path if not in the fx application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > behavior Marked as reviewed by mstrauss (Reviewer). modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 74: > 72: import com.sun.javafx.css.StyleManager; > 73: import com.sun.javafx.scene.NodeHelper; > 74: import com.sun.javafx.stage.PopupWindowHelper; That's a lot of import noise for such a small patch... ------------- PR Review: https://git.openjdk.org/jfx/pull/1696#pullrequestreview-2604330579 PR Review Comment: https://git.openjdk.org/jfx/pull/1696#discussion_r1948165334 From tsayao at openjdk.org Sun Feb 9 19:15:49 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 9 Feb 2025 19:15:49 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode Message-ID: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. It's not specific to i3. I used `gdk_window_get_root_origin` because GTK will try harder to find the value, even if `_NET_FRAME_EXTENTS` is not supported on some Window Manager. ------------- Commit messages: - Forgot debug print - 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode Changes: https://git.openjdk.org/jfx/pull/1702/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348095 Stats: 19 lines in 3 files changed: 3 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1702.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1702/head:pull/1702 PR: https://git.openjdk.org/jfx/pull/1702 From sykora at openjdk.org Mon Feb 10 10:27:18 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Mon, 10 Feb 2025 10:27:18 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 03:00:17 GMT, Alexander Matveev wrote: > - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. > - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. > - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. > - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. All builds went fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1695#pullrequestreview-2605319916 From martinfox656 at gmail.com Mon Feb 10 13:12:13 2025 From: martinfox656 at gmail.com (Martin Fox) Date: Mon, 10 Feb 2025 05:12:13 -0800 Subject: [External] : Re: Focus delegation API In-Reply-To: References: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com> Message-ID: > I guess that's just the way I made it work. Implementing this in > Control is not something I've thought about a lot. It was really my thought experiment to begin with. Not sure it?s even possible to do this without involving Scene and Scene knows nothing about Controls. Don?t give it another thought. > I see no reason why a control shouldn't dynamically change what it > returns from getFocusDelegate(). However, there's no notification > mechanism that would indicate when something has changed. Would you > need something like Scene.focusOwner(), but instead of containing the > outermost focused node (like ComboBox), it contains the last node in > the current delegation chain (TextField)? I?ll go think about the implementation and get back to you. For now I just needed to clarify that a Node?s focus delegate can change dynamically and that there might be a chain of delegates (which is the tricky part). From jbhaskar at openjdk.org Mon Feb 10 15:31:44 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 10 Feb 2025 15:31:44 GMT Subject: RFR: 8340322: Update WebKit to 620.1 Message-ID: Webkit JavaFx upgrade from 619.1 to 620.1
    Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. ------------- Commit messages: - Webkit 2.46.5 upgrade Changes: https://git.openjdk.org/jfx/pull/1703/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8340322 Stats: 773682 lines in 8157 files changed: 644444 ins; 72180 del; 57058 mod Patch: https://git.openjdk.org/jfx/pull/1703.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1703/head:pull/1703 PR: https://git.openjdk.org/jfx/pull/1703 From kcr at openjdk.org Mon Feb 10 15:38:20 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 15:38:20 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. ### NOTE TO REVIEWERS The upstream WebKit has switched compilers on Windows platforms from MSVC to `clang-cl`. We still use MSVC for everything else (other than WebKit), and use the MSVC linker for `jfxwebkit.dll`. The version of clang-cl that we tested with is 19.1.7, which can be found here: https://github.com/llvm/llvm-project/releases/tag/llvmorg-19.1.7 Specifically, this artifact: clang+llvm-19.1.7-x86_64-pc-windows-msvc.tar.xz Reviewers: @kevinrushforth @arapte and either @johanvos or @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1703#issuecomment-2648420999 From angorya at openjdk.org Mon Feb 10 15:39:25 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 15:39:25 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 19:19:56 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed javadoc for internal Node methods > - Merge remote-tracking branch 'origin/master' into 8344367_Fix_mistakes_in_FX_API_docs > - Revert "Addressed review comment" > > This reverts commit 60d4ba92b997be9937f0984761b278b21de816e7. > - Addressed review comment > - More corrections > - Batch typo fixes > - Fix mistakes in OpenJFX docs Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1642#pullrequestreview-2606276700 From angorya at openjdk.org Mon Feb 10 15:45:24 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 15:45:24 GMT Subject: Integrated: 8348100: Tooltips cannot be instantiated on background thread In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:35:06 GMT, Andy Goryachev wrote: > ## Root Cause > navigating up the parent hierarchy during CSS processing in a background thread encounters a null parent, causing the NPE. The null parent comes from a static Toolkit.BEHAVIOR field. > > ## Solution > avoid that code path if not in the fx application thread. This pull request has now been integrated. Changeset: 3ce3af03 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/3ce3af0379e95ff31867c9ce636896ec073bbe4b Stats: 92 lines in 2 files changed: 66 ins; 21 del; 5 mod 8348100: Tooltips cannot be instantiated on background thread Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1696 From kcr at openjdk.org Mon Feb 10 16:25:20 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 16:25:20 GMT Subject: RFR: 8349679: build.gradle: increase system test memory limit to 1GB In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 23:19:37 GMT, Andy Goryachev wrote: > Increased max heap size for system tests from 521Mb to 1000Mb. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1701#pullrequestreview-2606454400 From kcr at openjdk.org Mon Feb 10 16:29:22 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 16:29:22 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 19:19:56 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed javadoc for internal Node methods > - Merge remote-tracking branch 'origin/master' into 8344367_Fix_mistakes_in_FX_API_docs > - Revert "Addressed review comment" > > This reverts commit 60d4ba92b997be9937f0984761b278b21de816e7. > - Addressed review comment > - More corrections > - Batch typo fixes > - Fix mistakes in OpenJFX docs Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1642#pullrequestreview-2606464609 From nlisker at openjdk.org Mon Feb 10 16:35:17 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 10 Feb 2025 16:35:17 GMT Subject: Integrated: 8344367: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker wrote: > A batch of typo and grammar fixes that were found by the spellchecker. > > Integration can wait until RDP 1/2. This pull request has now been integrated. Changeset: 8818ccf8 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/8818ccf8ca883cda49c296ebf6d960c6929a9644 Stats: 78 lines in 40 files changed: 1 ins; 0 del; 77 mod 8344367: Fix mistakes in FX API docs Reviewed-by: angorya, kcr, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1642 From angorya at openjdk.org Mon Feb 10 16:46:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 16:46:18 GMT Subject: RFR: 8349679: build.gradle: increase system test memory limit to 1GB In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 23:19:37 GMT, Andy Goryachev wrote: > Increased max heap size for system tests from 521Mb to 1000Mb. @johanvos could this change have any negative impact on Gluon's CI? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1701#issuecomment-2648634312 From kcr at openjdk.org Mon Feb 10 16:50:18 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 16:50:18 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v3] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 7 Feb 2025 23:00:37 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > gc With the explicit call to `System.gc()` this now passes for me. I was also able to reproduce the failure without your fix using the latest version of the test, and confirm that it passes with your fix. I think the frequency of calling `System.gc()` is probably too high. Perhaps calling it every 10 or 100 times through the loop would suffice (and then it would be a better stress test of object allocation, since System.gc() effectively introduces delay)? That might be difficult to do without modifying the `test` method, so we could consider this for a follow-up. Somewhat related, I'm convinced that there is a leak somewhere. If I run just the pagination test for 100 seconds rather than 5, it's easy to see that the memory keeps growing -- with or without the fix for this bug. We should file a follow-up bug for this. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1698#pullrequestreview-2606530903 From nlisker at openjdk.org Mon Feb 10 16:54:17 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 10 Feb 2025 16:54:17 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 19:19:56 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed javadoc for internal Node methods > - Merge remote-tracking branch 'origin/master' into 8344367_Fix_mistakes_in_FX_API_docs > - Revert "Addressed review comment" > > This reverts commit 60d4ba92b997be9937f0984761b278b21de816e7. > - Addressed review comment > - More corrections > - Batch typo fixes > - Fix mistakes in OpenJFX docs Do I need to `/backport` this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2648656369 From angorya at openjdk.org Mon Feb 10 17:06:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 17:06:15 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v3] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 7 Feb 2025 23:00:37 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > gc You are probably right about `System.gc()` being called too often. I would say though that the purpose of this test is to uncover initialization issues rather than finding other problems with the controls, so it's probably ok as is. For the OOME - there seems to be no leak, since the memory usage drops down to initial values either using `System.gc()` in the loop, or when running in the IDE with the large heap: the memory fills up rather quickly, then drops again down to low value when one hits "Run GC" in the VirtualVM for example. (we also have no leak detected in the skin test and no memory issues logged against Pagination in JBS) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2648689041 From kcr at openjdk.org Mon Feb 10 18:00:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 18:00:21 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v3] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: <_e1k5MPaa2Wlskc1G-aLrJ0npiEOKS-9MxX6r9sl7uM=.82fc1a40-9003-4e1e-b5d8-06ea1e8733f6@github.com> On Mon, 10 Feb 2025 17:03:49 GMT, Andy Goryachev wrote: > You are probably right about `System.gc()` being called too often. I would say though that the purpose of this test is to uncover initialization issues rather than finding other problems with the controls, so it's probably ok as is. it still might be worth a follow-up bug. As it is, calling `System.gc()` each time through the loop means that you are creating far fewer objects than you would in a tight loop (by an order of magnitude based on a few quick tests I did). > For the OOME - there seems to be no leak, since the memory usage drops down to initial values either using `System.gc()` in the loop, or when running in the IDE with the large heap: the memory fills up rather quickly, then drops again down to low value when one hits "Run GC" in the VirtualVM for example. When I run it with `-verbose:gc` I see the memory continually increasing, although slowly. I'll try it with Visual VM and see if I spot anything. In any case, if there is a leak here, it isn't a large one (and isn't directly related to this bug), so would be something to look into as a follow-up. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2648821316 From kcr at openjdk.org Mon Feb 10 18:02:27 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 18:02:27 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: <37FlZu7qEX-3kZnEcAPWMh91x9izw3dO1FI3hsu4Xjw=.dcd5d235-584b-4340-addc-d3b4636c3923@github.com> On Mon, 10 Feb 2025 16:51:28 GMT, Nir Lisker wrote: > Do I need to `/backport` this? Yes please. `/backport :jfx24` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2648826371 From angorya at openjdk.org Mon Feb 10 18:10:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 18:10:20 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v3] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 7 Feb 2025 23:00:37 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > gc Created https://bugs.openjdk.org/browse/JDK-8349750 placeholder for collecting follow-up issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2648849090 From kizune at openjdk.org Mon Feb 10 18:40:16 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 10 Feb 2025 18:40:16 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> Message-ID: On Fri, 7 Feb 2025 18:43:32 GMT, Andy Goryachev wrote: >> Root Cause: >> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. >> >> I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. >> >> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. >> >> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. >> >> With this change, it is safe to create and populate charts with data in a background thread. >> >> --- >> >> ## NOTES >> >> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. >> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' into 8349091.charts.thread.safety > - whitespace > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - cleanup > - tests pass > - chart tests only > - more jitter > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - skip tests > - jiggler > - ... and 9 more: https://git.openjdk.org/jfx/compare/2cf9779b...4b6089e4 tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 186: > 184: accessChart(c); > 185: c.getData().setAll(createNumberSeries()); > 186: c.getData().setAll(createNumberSeries()); Just curious - why do we do setAll twice in all the tests? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1949684775 From angorya at openjdk.org Mon Feb 10 18:43:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 18:43:18 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> Message-ID: <47o-NdybeK2ARCfUvT5mjQQFWlI_RocBRXRRbR6Tyq0=.ecabaf73-beb6-4519-93b9-1a45a00ef217@github.com> On Mon, 10 Feb 2025 18:38:00 GMT, Alexander Zuev 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 19 commits: >> >> - Merge branch 'master' into 8349091.charts.thread.safety >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - cleanup >> - tests pass >> - chart tests only >> - more jitter >> - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety >> - skip tests >> - jiggler >> - ... and 9 more: https://git.openjdk.org/jfx/compare/2cf9779b...4b6089e4 > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 186: > >> 184: accessChart(c); >> 185: c.getData().setAll(createNumberSeries()); >> 186: c.getData().setAll(createNumberSeries()); > > Just curious - why do we do setAll twice in all the tests? good question! this code exercises both remove and add code paths. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1949688772 From nlisker at openjdk.org Mon Feb 10 18:46:24 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 10 Feb 2025 18:46:24 GMT Subject: [jfx24] RFR: 8344367: Fix mistakes in FX API docs Message-ID: <2sBSyTVdYgaQ8eC6XWgK1WtR01NSMRAYPI4TQQ6jaus=.51998762-8e37-4945-9fd9-e17e07c1466f@github.com> 8344367: Fix mistakes in FX API docs ------------- Commit messages: - Backport 8818ccf8ca883cda49c296ebf6d960c6929a9644 Changes: https://git.openjdk.org/jfx/pull/1704/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1704&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344367 Stats: 78 lines in 40 files changed: 1 ins; 0 del; 77 mod Patch: https://git.openjdk.org/jfx/pull/1704.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1704/head:pull/1704 PR: https://git.openjdk.org/jfx/pull/1704 From kcr at openjdk.org Mon Feb 10 19:00:20 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 19:00:20 GMT Subject: [jfx24] RFR: 8344367: Fix mistakes in FX API docs In-Reply-To: <2sBSyTVdYgaQ8eC6XWgK1WtR01NSMRAYPI4TQQ6jaus=.51998762-8e37-4945-9fd9-e17e07c1466f@github.com> References: <2sBSyTVdYgaQ8eC6XWgK1WtR01NSMRAYPI4TQQ6jaus=.51998762-8e37-4945-9fd9-e17e07c1466f@github.com> Message-ID: <602Bv7rZQYkz2MTY-ZW0xIB9ZwNwO5gv6rAZy7Jr33w=.73f098e8-2d2c-4ff5-bde8-39ce6ced87a6@github.com> On Mon, 10 Feb 2025 18:42:31 GMT, Nir Lisker wrote: > 8344367: Fix mistakes in FX API docs Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1704#pullrequestreview-2606873109 From nlisker at openjdk.org Mon Feb 10 19:15:18 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 10 Feb 2025 19:15:18 GMT Subject: [jfx24] Integrated: 8344367: Fix mistakes in FX API docs In-Reply-To: <2sBSyTVdYgaQ8eC6XWgK1WtR01NSMRAYPI4TQQ6jaus=.51998762-8e37-4945-9fd9-e17e07c1466f@github.com> References: <2sBSyTVdYgaQ8eC6XWgK1WtR01NSMRAYPI4TQQ6jaus=.51998762-8e37-4945-9fd9-e17e07c1466f@github.com> Message-ID: <_T2BJTxstwLSLwkx8sj8Rzj8miU5x5ruBRgnVIti4nM=.3a2246b7-a6d1-4cdc-bbf7-b0af81ab5a5b@github.com> On Mon, 10 Feb 2025 18:42:31 GMT, Nir Lisker wrote: > 8344367: Fix mistakes in FX API docs This pull request has now been integrated. Changeset: 0424b8b1 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/0424b8b1705252ded4ffc4a681a1ba67124ddb12 Stats: 78 lines in 40 files changed: 1 ins; 0 del; 77 mod 8344367: Fix mistakes in FX API docs Reviewed-by: kcr Backport-of: 8818ccf8ca883cda49c296ebf6d960c6929a9644 ------------- PR: https://git.openjdk.org/jfx/pull/1704 From angorya at openjdk.org Mon Feb 10 22:30:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Feb 2025 22:30:32 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v4] In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: slow down gc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1698/files - new: https://git.openjdk.org/jfx/pull/1698/files/300b269d..3256957e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1698.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1698/head:pull/1698 PR: https://git.openjdk.org/jfx/pull/1698 From kcr at openjdk.org Mon Feb 10 22:38:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Feb 2025 22:38:16 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v4] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Mon, 10 Feb 2025 22:30:32 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > slow down gc I filed [JDK-8349756](https://bugs.openjdk.org/browse/JDK-8349756) to track the leak. I think the call to `System.gc()` is effective only because it slows down the tight loop. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 417: > 415: if (nextBoolean(0.1)) { > 416: System.gc(); > 417: } While investigation the Pagination leak I also took a closer look at this `System.gc()`. The reason this prevents the OOM has nothing to do with the GC per se, but rather it slows the loops down so much that they don't generate nearly as much garbage in the 5 seconds the test runs in. You can verify that yourself by replacing the `System.gc()` with `sleep(10)` or similar (depending on the speed of your system), and get the same effect. I don't think there is a good reason to call `System.gc()` at all in this loop. Once the leak is fixed, it should run fine at full speed. ------------- PR Review: https://git.openjdk.org/jfx/pull/1698#pullrequestreview-2607335526 PR Review Comment: https://git.openjdk.org/jfx/pull/1698#discussion_r1949997384 From credmond at certak.com Mon Feb 10 23:28:31 2025 From: credmond at certak.com (Cormac Redmond) Date: Mon, 10 Feb 2025 23:28:31 +0000 Subject: Bug: Impossible to load 2+ independent applications if both are using the same JFX version (Windows, JFX 23.0.2+3) In-Reply-To: References: <61f32f24-41ce-4468-a0e6-f30809b2a3df@xpipe.io> Message-ID: Hi Johan, Thanks as always for the explanation, and some of the history on this. I'll go the jmods route to avoid this. Agreed a warning on this *somewhere* would be good, as it's not something developers typically need to consider. Kind Regards, Cormac On Sun, 9 Feb 2025 at 10:56, Johan Vos wrote: > Hi Cormac, > > I understand the problem, and I agree it can be really annoying. It either > needs better communication, or a fix. The maven artifacts are something we > added with Gluon (hence not Oracle). As you said, windows signing > certificates come with a price (and building hassle). > The reason we started uploading those artifacts is mainly because > developers are very used to the maven artifact approach during development. > I believe this lowered the bar for JavaFX development after the JDK didn't > ship with the JavaFX code anymore. A developer who just wants to explore > using JavaFX is less likely to download an additional SDK or jmods. Simply > adding a few lines in a pom.xml is something most developers are familiar > with. > For shipping applications, I strongly discourage this, and > highly recommend the SDK/jmods approach. I can see now though that offering > the "maven artifacts for developers" created higher expectations than > intended. > > The problem you described is more or less documented in > https://bugs.openjdk.org/browse/JDK-8316276 . There have been discussions > (e.g. on the jigsaw list) in the past about this, as other projects (e.g. > dl4j) have similar issues with jars containing native code. There is no > standard approach in Java to deal with this, which is why the > NativeLibLoader contains a bunch of logic that allows to invoke the code in > the native libs from the classes in the same jar. That logic has been > modified over the years, to account for specific issues (e.g. [1] and [2]), > but it's not perfect. > > I'm not against signing those libraries (it is a net loss of money and > time though), but as you noticed yourself, this won't fix all problems. We > should probably make it more clear that the maven artifacts should not be > used in production systems, and are for development only -- for developers > by developers. > > - Johan > > [1] https://bugs.openjdk.org/browse/JDK-8317308 > [2] https://bugs.openjdk.org/browse/JDK-8307536 > > On Sat, Feb 8, 2025 at 10:01?PM Cormac Redmond > wrote: > >> Hi Steve, >> >> Thanks. I can also workaround it (with very limited changes) in another >> way by overriding javafx.runtime.version with something specific to my >> app, and its version (which will ultimately dictate the cache directory >> name) -- as the chances of having a clash then, are astronomically low. >> >> However, none of these things are solutions, but workarounds -- my stance >> is that it should not be up to the developer to firstly know this problem >> even exists (most won't), and then to workaround it by avoiding using >> certain JARs. It's not like we're building apps in un-documented or unusual >> ways, quite the opposite. >> >> >> Kind Regards, >> Cormac >> >> On Sat, 8 Feb 2025 at 18:16, Steve Hannah wrote: >> >>> This also doesn't seem to affect apps running with the zulufx >>> distributions (the JRE with JavaFX bundled). >>> >>> E.g. this build of JavaFX ensemble >>> https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble >>> It uses Java 19, and OpenJFX 20, and it doesn't seem to create an >>> .openjfx directory anywhere that I can find. >>> >>> Therefore, you can deploy your app using jDeploy and it won't have this >>> issue. (Disclosure, I'm the creator of jDeploy). Similarly, if you bundle >>> your app with a ZuluFX distribution, and strip out your maven jars (which >>> is what jDeploy does), you won't have this issue. >>> >>> Steve >>> >>> On Sat, Feb 8, 2025 at 9:35?AM Cormac Redmond >>> wrote: >>> >>>> Hi, >>>> >>>> Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods >>>> (as many do). And the clashing application in question, must be the same. >>>> But this is a real problem that occurred with a real user, and I only have >>>> a handful of users. >>>> >>>> Oracle signing the JFX DLLs, while an improvement, would still leave >>>> the following problems wide open: >>>> >>>> - There's no way to stop a developer (or some build tool) from >>>> re-signing or removing signature from signed DLLs, in which case this >>>> problem can still re-occur >>>> - In the event of a genuine difference of a DLLs (under the same >>>> cache folder version), if the DLL cannot be deleted (to be replaced), >>>> because a running application application is using it -- a completely >>>> feasibly scenario -- then we have one application breaking another. >>>> >>>> Also, the developers shipping apps are in full control of the JFX JARs, >>>> their DLLs, and the *reported" javafx.version and javafx.runtime.version. >>>> E.g., I could have JFX 21.0.5 in a JFX 23.0.2 cache folder if I wanted >>>> simply by changing javafx.runtime.version (or javafx.cachedir). >>>> >>>> It's far too brittle. >>>> >>>> >>>> >>>> Regards, >>>> >>>> *Cormac Redmond* >>>> Software Engineer, Certak Ltd. >>>> >>>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >>>> >>>> >>>> >>>> >>>> On Sat, 8 Feb 2025 at 12:49, Christopher Schnick >>>> wrote: >>>> >>>>> I think that went a bit under the radar as this only occurs when using >>>>> the maven dependencies. The SDK and jmod downloads do not have that issue >>>>> as they don't copy DLLs into any temp directory. Only the maven jars have >>>>> to do this. >>>>> >>>>> About signing any JavaFX DLLs, that would indeed be a good addition >>>>> considering all other JDK DLLs are signed. >>>>> >>>>> Best >>>>> Christopher Schnick >>>>> On 08/02/2025 13:31, Cormac Redmond wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am surprised nobody else sees this bug as a higher-priority >>>>> conversation point. >>>>> >>>>> It's troubling to see how running one self-contained application can >>>>> break another self-contained application (because of a cache that most JFX >>>>> devs wouldn't even know exist). >>>>> >>>>> If one well-behaved JFX application cannot delete/replace a file JFX >>>>> cache on start-up, because another well-behaved JFX application is using >>>>> that cached file (it will be if built on the same JFX version) -- then the >>>>> application will not run, at all. >>>>> >>>>> And as I explained earlier, this is a likely occurring scenario in the >>>>> wild -- the only reason this bug isn't more prevalent /reported / >>>>> noticeable, is that it's not too likely for a user to have two JFX >>>>> applications using the same JavaFX version, on their machine. But that's >>>>> down to pure coincidence / chance. I wouldn't say the same for Electron or >>>>> Flutter, etc. If they had this bug, it would be noticed and it would be >>>>> news. >>>>> >>>>> Also, the creators of these applications would have no idea that their >>>>> application is not starting, nor would the users know why. >>>>> >>>>> By the way, the problem is not just about *signed* DLLs + checksums, >>>>> obviously. It would occur if the DLLs are different for any other >>>>> reason too, obviously, and the authors of NativeLibLoader thought this >>>>> possibility is high enough to do the checksum + delete + replace check. The >>>>> application shouldn't silently fail because of a cache management bug. >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> *Cormac Redmond* >>>>> Software Engineer, Certak Ltd. >>>>> >>>>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com >>>>> >>>>> >>>>> >>>>> On Thu, 6 Feb 2025 at 19:56, Cormac Redmond >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have found a "serious" bug, where two completely independent JFX >>>>>> applications, both with their own embedded runtime (built with jlink & >>>>>> jpackage) & using the same JavaFX version, are unable to run >>>>>> simultaneously, because of the JFX cache -- at least on Windows. >>>>>> >>>>>> When trying to run any application, NativeLibLoader does a checksum >>>>>> on DLLs in the cache (e.g.: C:\Users\xyz\.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll); >>>>>> and tries to delete any files that exist where the checksums do not match >>>>>> (in order to replace them): >>>>>> >>>>>> if (!Arrays.equals(isHash, fileHash)) { >>>>>>> Files.delete(f.toPath()); >>>>>>> } >>>>>> >>>>>> >>>>>> But a second application *fails* to start, as it is unable to delete >>>>>> these files because they're in use by the first application (see stacktrace >>>>>> below). >>>>>> >>>>>> But why are the checksums different, shouldn't they be the same? They >>>>>> are different because the DLLs are signed by the builder of the >>>>>> applications -- different authors and different timestamps. So the DLL >>>>>> checksums will be different despite the DLLs being the same, in terms of >>>>>> the JFX version. >>>>>> >>>>>> Why are these JFX DLLs signed by the authors? Because for some >>>>>> reason, they come *unsigned*, and all DLLs when packaged *should* be >>>>>> signed, including any embedded in JARs, to avoid alarming Windows Defender >>>>>> warnings and mistrust, etc. There's no point spending a small fortune on >>>>>> Windows code-signing certs and shipping with any unsigned third-party DLLs >>>>>> (including any embedded in JARs). You might sign your own binaries and any >>>>>> unsigned third-party binaries. Similarly for MacOS, everything, including >>>>>> embedded native libs in JARs, etc., needs to be signed for gatekeeper & >>>>>> notarization to allow it. >>>>>> >>>>>> So it would be better if JFX DLLs came signed, to avoid forcing >>>>>> developers to do it (which would also avoid this checksum mishap). Or, if >>>>>> developers need to sign Oracle's DLLs, then this checksum approach isn't >>>>>> suitable. Also, there should really be a proper fallback in place -- a >>>>>> cache bug should not have such a catastrophic outcome. >>>>>> >>>>>> FYI: JLink also removes signatures from a bunch of JDK DLLs when >>>>>> assembling the runtime, but leaves a bunch of Windows DLLs >>>>>> untouched. Personally, I'd prefer all DLLs to come signed, and let the >>>>>> developers re-sign if they want. Removing the signatures is adding >>>>>> unnecessary hurdles for folks, for no benefit I can see. >>>>>> >>>>>> Anyway, example stacktrace: >>>>>> >>>>>> Loading D3D native library ... >>>>>>> WARNING: java.lang.UnsatisfiedLinkError: Can't load library: >>>>>>> C:\Program Files\KafkIO\bin\prism_d3d.dll >>>>>>> Loading library prism_d3d from resource failed: >>>>>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>>>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>>>>> java.nio.file.AccessDeniedException: C:\Users\xyz >>>>>>> \.openjfx\cache\23.0.2+3\amd64\prism_d3d.dll >>>>>>> at >>>>>>> java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) >>>>>>> at >>>>>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>>>>> at >>>>>>> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) >>>>>>> at >>>>>>> java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) >>>>>>> at >>>>>>> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) >>>>>>> at java.base/java.nio.file.Files.delete(Unknown Source) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.cacheLibrary(NativeLibLoader.java:300) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:218) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:200) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:142) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>>>>> at >>>>>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>>>>> at >>>>>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>>>>> at >>>>>>> com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>>>>> at java.base/java.lang.Class.forName0(Native Method) >>>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>>> at >>>>>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>>>>> at >>>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>>>>> at >>>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>>>>> at java.base/java.lang.Thread.run(Unknown Source) >>>>>>> GraphicsPipeline.createPipeline failed for >>>>>>> com.sun.prism.d3d.D3DPipeline >>>>>>> java.lang.UnsatisfiedLinkError: no prism_d3d in java.library.path: >>>>>>> C:\Program >>>>>>> Files\KafkIO;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program >>>>>>> Files\Oculus\Support\oculus-runtime;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;c:\dev\apps\apache-maven-3.9.9\bin;C:\dev\apps\cygwin64\bin;C:\Program Files >>>>>>> (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program >>>>>>> Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\7-Zip;C:\Program >>>>>>> Files\SafeNet\Authentication\SAC\x64;C:\Program >>>>>>> Files\SafeNet\Authentication\SAC\x32;C:\Program >>>>>>> Files\Docker\Docker\resources\bin;%JAVA_HOME%\bin;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\ >>>>>>> xyz\scoop\apps\zulu-jdk\current\bin;C:\Users\xyz >>>>>>> \scoop\apps\zulu22-jdk\current\bin;C:\Users\xyz >>>>>>> \scoop\apps\zulu21-jdk\current\bin;C:\Users\xyz >>>>>>> \scoop\shims;C:\Users\xyz >>>>>>> \AppData\Local\Microsoft\WindowsApps;C:\dev\scripts;C:\Program >>>>>>> Files\JetBrains\IntelliJ IDEA 2024.2\bin;C:\Program Files\KafkIO\app;. >>>>>>> at java.base/java.lang.ClassLoader.loadLibrary(Unknown >>>>>>> Source) >>>>>>> at java.base/java.lang.Runtime.loadLibrary0(Unknown Source) >>>>>>> at java.base/java.lang.System.loadLibrary(Unknown Source) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:170) >>>>>>> at >>>>>>> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:58) >>>>>>> at >>>>>>> com.sun.prism.d3d.D3DPipeline.lambda$static$0(D3DPipeline.java:54) >>>>>>> at >>>>>>> java.base/java.security.AccessController.doPrivileged(Unknown Source) >>>>>>> at >>>>>>> com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:50) >>>>>>> at java.base/java.lang.Class.forName0(Native Method) >>>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>>> at java.base/java.lang.Class.forName(Unknown Source) >>>>>>> at >>>>>>> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218) >>>>>>> at >>>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:92) >>>>>>> at >>>>>>> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >>>>>>> at java.base/java.lang.Thread.run(Unknown Source) >>>>>> >>>>>> >>>>>> >>>>>> Kind Regards, >>>>>> Cormac >>>>>> >>>>>> >>>>>> >>> >>> -- >>> Steve Hannah >>> Web Lite Solutions Corp. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Tue Feb 11 09:13:20 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 11 Feb 2025 09:13:20 GMT Subject: RFR: 8349679: build.gradle: increase system test memory limit to 1GB In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 16:43:58 GMT, Andy Goryachev wrote: > @johanvos could this change have any negative impact on Gluon's CI? should be fine. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1701#issuecomment-2650206357 From jvos at openjdk.org Tue Feb 11 09:13:19 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 11 Feb 2025 09:13:19 GMT Subject: RFR: 8349679: build.gradle: increase system test memory limit to 1GB In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 23:19:37 GMT, Andy Goryachev wrote: > Increased max heap size for system tests from 521Mb to 1000Mb. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1701#pullrequestreview-2608097295 From jpereda at openjdk.org Tue Feb 11 11:01:16 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 11 Feb 2025 11:01:16 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode In-Reply-To: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: On Sun, 9 Feb 2025 19:10:49 GMT, Thiago Milczarek Sayao wrote: > The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. > > It's not specific to i3. > > I used `gdk_window_get_root_origin` because GTK will try harder to find the value, even if `_NET_FRAME_EXTENTS` is not supported on some Window Manager. I've tested successfully on Ubuntu, with or without i3 wm, and Fedora+Sway. It looks good, but I had to add some debug info myself for better understanding of the changes... so that's why I left one remark. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 983: > 981: geometry.y = root_y; > 982: geometry.view_x = origin_x - root_x; > 983: geometry.view_y = origin_y - root_y; Looks good, but maybe you could add a small comment about what `x/y` and `view_x/view_y` mean? ------------- PR Review: https://git.openjdk.org/jfx/pull/1702#pullrequestreview-2608366331 PR Review Comment: https://git.openjdk.org/jfx/pull/1702#discussion_r1950635001 From tsayao at openjdk.org Tue Feb 11 11:45:52 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2025 11:45:52 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v2] In-Reply-To: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: <2y966fjskRFqw16lkaTsZcdvtE8mBIUACCt3zdaQSAQ=.4dfa43b5-4389-4692-af8c-bd99579e4a41@github.com> > The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. > > It's not specific to i3. > > I used `gdk_window_get_root_origin` because GTK will try harder to find the value, even if `_NET_FRAME_EXTENTS` is not supported on some Window Manager. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Clarify the meaning of view_x and view_y. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1702/files - new: https://git.openjdk.org/jfx/pull/1702/files/b3443aef..ac68cfb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1702.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1702/head:pull/1702 PR: https://git.openjdk.org/jfx/pull/1702 From tsayao at openjdk.org Tue Feb 11 11:51:26 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2025 11:51:26 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v3] In-Reply-To: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: > The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. > > It's not specific to i3. > > I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Clarify the meaning of x and y. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1702/files - new: https://git.openjdk.org/jfx/pull/1702/files/ac68cfb3..bd12ebca Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1702.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1702/head:pull/1702 PR: https://git.openjdk.org/jfx/pull/1702 From tsayao at openjdk.org Tue Feb 11 11:51:26 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2025 11:51:26 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v3] In-Reply-To: References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: On Tue, 11 Feb 2025 10:57:04 GMT, Jose Pereda wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify the meaning of x and y. > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 983: > >> 981: geometry.y = root_y; >> 982: geometry.view_x = origin_x - root_x; >> 983: geometry.view_y = origin_y - root_y; > > Looks good, but maybe you could add a small comment about what `x/y` and `view_x/view_y` mean? Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1702#discussion_r1950700602 From tsayao at openjdk.org Tue Feb 11 12:12:15 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2025 12:12:15 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v3] In-Reply-To: References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: On Tue, 11 Feb 2025 11:51:26 GMT, Thiago Milczarek Sayao wrote: >> The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. >> >> It's not specific to i3. >> >> I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the meaning of x and y. I tested it on Ubuntu 24.04 with Xorg / Wayland (Gnome) and Xorg / Kde. Did a complete unit test run on 20.04 / Xorg (Gnome) with one unrelated failure. ![image](https://github.com/user-attachments/assets/c349a397-1a01-428b-974e-19ff4ed19f3a) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1702#issuecomment-2650622782 From jpereda at openjdk.org Tue Feb 11 12:21:15 2025 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 11 Feb 2025 12:21:15 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v3] In-Reply-To: References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: <-EkcKS8yVj69sZKoYTiD1uPEpFLU3ruJ9_J3W_YC9rw=.ba15831b-c148-4baf-a6d4-670182691058@github.com> On Tue, 11 Feb 2025 11:51:26 GMT, Thiago Milczarek Sayao wrote: >> The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. >> >> It's not specific to i3. >> >> I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the meaning of x and y. Looks good! ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1702#pullrequestreview-2608565094 From kcr at openjdk.org Tue Feb 11 15:08:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 15:08:16 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v3] In-Reply-To: References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: On Tue, 11 Feb 2025 11:51:26 GMT, Thiago Milczarek Sayao wrote: >> The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. >> >> It's not specific to i3. >> >> I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the meaning of x and y. @lukostyra Can you also review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1702#issuecomment-2651095447 From angorya at openjdk.org Tue Feb 11 15:23:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 15:23:16 GMT Subject: Integrated: 8349679: build.gradle: increase system test memory limit to 1GB In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 23:19:37 GMT, Andy Goryachev wrote: > Increased max heap size for system tests from 521Mb to 1000Mb. This pull request has now been integrated. Changeset: 50dbedb8 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/50dbedb8e5c8be3a77bf5b733f928ff941b734a8 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8349679: build.gradle: increase system test memory limit to 1GB Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1701 From angorya at openjdk.org Tue Feb 11 16:56:49 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 16:56:49 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index Message-ID: ## Root Cause Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. ## Solution Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. ------------- Commit messages: - memory leak Changes: https://git.openjdk.org/jfx/pull/1705/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1705&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349756 Stats: 45 lines in 1 file changed: 27 ins; 13 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1705.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1705/head:pull/1705 PR: https://git.openjdk.org/jfx/pull/1705 From kcr at openjdk.org Tue Feb 11 17:04:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 17:04:21 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. All my testing looks good apart from a couple of known issues that are being tracked by follow-up bugs. The CanvasPattern bug that Jay referred to is tracked as [JDK-8347937](https://bugs.openjdk.org/browse/JDK-8347937). The only other issue I've found is one I filed a few days ago: [JDK-8349561](https://bugs.openjdk.org/browse/JDK-8349561): Preview images on yahoo.com rendered incorrectly ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1703#pullrequestreview-2609413416 PR Comment: https://git.openjdk.org/jfx/pull/1703#issuecomment-2651464400 From oschmidtmer at openjdk.org Tue Feb 11 17:58:21 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Tue, 11 Feb 2025 17:58:21 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp line 1: > 1: /* I would recommend to add "fprintf(stderr, XXX NOT IMPLEMENTED\n");" outputs to the the four changed / new functions stubs, as for the older unimplemented methods. This would make issues as we had in [JDK-8337481](https://bugs.openjdk.org/browse/JDK-8337481) easier to track. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1703#discussion_r1951325661 From kcr at openjdk.org Tue Feb 11 18:31:24 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 18:31:24 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: <-cXXuyLSgAOPbnU3xs96hNsAM868Cxhld8gGKeVcDJw=.ad9a10e1-aaa0-4943-a396-e97178651a4f@github.com> On Tue, 11 Feb 2025 17:55:25 GMT, Oliver Schmidtmer wrote: >> Webkit JavaFx upgrade from 619.1 to 620.1
    >> Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). >> Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. > > modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp line 1: > >> 1: /* > > I would recommend to add "fprintf(stderr, XXX NOT IMPLEMENTED\n");" outputs to the the four changed / new functions stubs, as for the older unimplemented methods. > This would make issues as we had in [JDK-8337481](https://bugs.openjdk.org/browse/JDK-8337481) easier to track. That's a good idea. @jaybhaskar Can you either make this change or else file a follow-up issue? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1703#discussion_r1951370805 From angorya at openjdk.org Tue Feb 11 18:49:22 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 18:49:22 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v4] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Mon, 10 Feb 2025 22:30:32 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > slow down gc Please review #1705 before this one. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2651703348 From sykora at openjdk.org Tue Feb 11 18:50:20 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Tue, 11 Feb 2025 18:50:20 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. I've successfully ran a build on all platforms after installing the clang tools. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1703#pullrequestreview-2609675222 From jvos at openjdk.org Tue Feb 11 18:50:20 2025 From: jvos at openjdk.org (Johan Vos) Date: Tue, 11 Feb 2025 18:50:20 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. Marked as reviewed by jvos (Reviewer). While not relevant for adding this to the main repository, there might be an impact on backports to 17/21 (although we don't expect showstoppers). ------------- PR Review: https://git.openjdk.org/jfx/pull/1703#pullrequestreview-2609680818 PR Comment: https://git.openjdk.org/jfx/pull/1703#issuecomment-2651704416 From kcr at openjdk.org Tue Feb 11 19:08:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 19:08:14 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. @jaybhaskar Please wait for a review from @arapte before integrating ------------- PR Comment: https://git.openjdk.org/jfx/pull/1703#issuecomment-2651815333 From kcr at openjdk.org Tue Feb 11 19:53:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 19:53:13 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:46:17 GMT, Andy Goryachev wrote: > ## Root Cause > > Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. > > ## Solution > > Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. I'll review and test the fix. Speaking of which, is an automated test feasible? If not, the test included with #1698 will indirectly test it (once the System.gc is removed). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1705#issuecomment-2651913886 From angorya at openjdk.org Tue Feb 11 20:33:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 20:33:16 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:46:17 GMT, Andy Goryachev wrote: > ## Root Cause > > Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. > > ## Solution > > Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. I suppose an automated test is possible - launch a new process with lower memory limit and monitor stdout/stderr, to avoid taking down the test framework when OOME happens. But I agree with you - the kind of stress test we introduced in #1698 is probably as good as any specially developed test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1705#issuecomment-2652002160 From kcr at openjdk.org Tue Feb 11 22:14:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 22:14:16 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:46:17 GMT, Andy Goryachev wrote: > ## Root Cause > > Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. > > ## Solution > > Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. The fix looks good to me. I tested it in a couple of different ways, and everything works as expected. With this fix and the fix for PR #1698 with the call to `System.gc()` removed, the test passes with no OOM. modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 201: > 199: > 200: navigation = new NavigationControl(); > 201: navigation.initializePageIndicators(); Minor: would it make sense to move this back to the`NavigationControl` constructor (at the end)? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1705#pullrequestreview-2610114615 PR Review Comment: https://git.openjdk.org/jfx/pull/1705#discussion_r1951646931 From angorya at openjdk.org Tue Feb 11 22:22:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 22:22:59 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index [v2] In-Reply-To: References: Message-ID: > ## Root Cause > > Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. > > ## Solution > > Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: back to constructor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1705/files - new: https://git.openjdk.org/jfx/pull/1705/files/fc222966..66c0b2ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1705&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1705&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1705.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1705/head:pull/1705 PR: https://git.openjdk.org/jfx/pull/1705 From angorya at openjdk.org Tue Feb 11 22:22:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 22:22:59 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 21:39:19 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> back to constructor > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/PaginationSkin.java line 201: > >> 199: >> 200: navigation = new NavigationControl(); >> 201: navigation.initializePageIndicators(); > > Minor: would it make sense to move this back to the`NavigationControl` constructor (at the end)? good point, thanks! fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1705#discussion_r1951688218 From kcr at openjdk.org Tue Feb 11 22:35:18 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Feb 2025 22:35:18 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 22:22:59 GMT, Andy Goryachev wrote: >> ## Root Cause >> >> Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. >> >> ## Solution >> >> Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > back to constructor Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1705#pullrequestreview-2610227477 From angorya at openjdk.org Tue Feb 11 22:40:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 22:40:15 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 22:22:59 GMT, Andy Goryachev wrote: >> ## Root Cause >> >> Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. >> >> ## Solution >> >> Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > back to constructor @arapte or @aghaisas could one of you be the second reviewer to unblock https://github.com/openjdk/jfx/pull/1698 please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1705#issuecomment-2652219647 From john.hendrikx at gmail.com Tue Feb 11 22:47:52 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 11 Feb 2025 23:47:52 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) Message-ID: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> Hi list, I've done a little proof of concept where I've made some minor modifications to CssStyleHelper to allow the CSS engine to offer styleable properties on children, but defined by the container class. What this means is that we can make it appear that direct children of a container like GridPane, HBox and VBox have properties like: `vgrow`, `hgrow`, `column-index`, `margin`, `halignment`, `fill-width` etc.? The exact names can be chosen by the container in question.? For example, I could style a child of an HBox like this: .text-field { ??? -fx-background-color: yellow; ??? -fx-hbox-hgrow: ALWAYS; ??? -fx-hbox-margin: 5px; } This will make it possible to do far more visual styling directly in CSS.? As usual, unrecognized properties are ignored, so if you put this text field in a VBox, nothing will happen. How does it work? - Containers that wish to add additional styleable properties to their direct descendants implement this interface: publicinterfaceChildStyleProvider { List> getChildCssMetaData(Node child); } - The CssMetaData they provide for these properties looks like this for example: newCssMetaData<>("-fx-hbox-hgrow", StyleConverter.getEnumConverter(Priority.class)) { @Override publicbooleanisSettable(Styleable styleable) { returntrue; } @Override publicStyleableProperty getStyleableProperty(Styleable styleable) { returnChildStyleProvider.createProp(this, "hbox-hgrow", child); } } - A special StyleableProperty is created as the "receiver" of CSS styling that will store the value in the Node#getProperties map (where normally these values are already stored when using the static methods like HBox.setHGrow(Node, Priority) type methods).? This property is cached as part of the same getProperties map, so it is only created once. - The CssStyleHelper will see if the parent of the Node being styled implements?ChildStyleProvider, and if so will also?process these additional CssMetaData properties when any are present; this seems to be fairly safe to do, as changing a Node's parent will reset all its styling already. Some more tests are needed here, if moving this forward. That is basically the change in a nutshell.? Not only does setting a property like `-fx-hbox-hgrow` on a child now act as if you called `HBox.setHGrow`, changing the style of the child can also change these settings and HBox will instantly respond to the change.? When the style is completely removed, it will also?null the hgrow value which is translated as removing that key from the Node#getProperties map. If people think this proposal has some merit, I can flesh it out further and make it into a PR. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Feb 11 23:25:43 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 23:25:43 GMT Subject: RFR: 8349758: Memory leak in TreeTableView Message-ID: ## Root Cause An event handler was installed on the root property without removing it when the root changes. ## Solution Replaced the weak parts with a change listener to the root property to ensure correct handling of the root value changes. ------------- Commit messages: - cleanup - remove weak listener Changes: https://git.openjdk.org/jfx/pull/1706/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1706&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349758 Stats: 105 lines in 1 file changed: 41 ins; 57 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1706.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1706/head:pull/1706 PR: https://git.openjdk.org/jfx/pull/1706 From angorya at openjdk.org Tue Feb 11 23:33:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 23:33:42 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v5] In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. 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 eight additional commits since the last revision: - Merge branch '8349756.pagination.leak' into 8349105.thread.safety.pagination - back to constructor - memory leak - remove gc - slow down gc - gc - Merge branch 'master' into 8349105.thread.safety.pagination - postpone animation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1698/files - new: https://git.openjdk.org/jfx/pull/1698/files/3256957e..eba7b350 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=03-04 Stats: 218 lines in 43 files changed: 94 ins; 38 del; 86 mod Patch: https://git.openjdk.org/jfx/pull/1698.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1698/head:pull/1698 PR: https://git.openjdk.org/jfx/pull/1698 From angorya at openjdk.org Tue Feb 11 23:33:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 11 Feb 2025 23:33:42 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v4] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Mon, 10 Feb 2025 22:30:32 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > slow down gc For testing purposes, merged this PR with the memory leak fix https://github.com/openjdk/jfx/pull/1705 . Once the latter is integrated, unrelated changes will disappear. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2652292591 From duke at openjdk.org Wed Feb 12 08:27:27 2025 From: duke at openjdk.org (Helly Guo) Date: Wed, 12 Feb 2025 08:27:27 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: <6h92wcAuDOGILVtAJXeCTe5Zql_2R9AfH5SIX-9ohjg=.026e59d5-eeeb-4d1d-812e-84493f80d1f1@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 Thanks @tsayao , @beldenfox , and other peoples. Thank you. You did it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2652971012 From arapte at openjdk.org Wed Feb 12 09:03:16 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 12 Feb 2025 09:03:16 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. Verified the build and sanity testing on mac and windows. LGTM. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1703#pullrequestreview-2611235150 From kizune at openjdk.org Wed Feb 12 10:02:17 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 12 Feb 2025 10:02:17 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> Message-ID: On Fri, 7 Feb 2025 18:43:32 GMT, Andy Goryachev wrote: >> Root Cause: >> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. >> >> I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. >> >> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. >> >> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. >> >> With this change, it is safe to create and populate charts with data in a background thread. >> >> --- >> >> ## NOTES >> >> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. >> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' into 8349091.charts.thread.safety > - whitespace > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - cleanup > - tests pass > - chart tests only > - more jitter > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - skip tests > - jiggler > - ... and 9 more: https://git.openjdk.org/jfx/compare/2cf9779b...4b6089e4 Marked as reviewed by kizune (Author). Ok, changes look good and they seems to work on Mac OS. I am curious why do we make labels in charts focus traversable when a11y is switched on? May be something to do with accessibility on Windows? I haven't tested this patch on Windows yet. On Mac OS user can move accessibility cursor to non-focusable elements such as text labels and images so we should not have a problem navigating to the chart labels. Needs to be investigated more. ------------- PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2611391786 PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2653202615 From jbhaskar at openjdk.org Wed Feb 12 10:04:23 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 12 Feb 2025 10:04:23 GMT Subject: RFR: 8340322: Update WebKit to 620.1 In-Reply-To: <-cXXuyLSgAOPbnU3xs96hNsAM868Cxhld8gGKeVcDJw=.ad9a10e1-aaa0-4943-a396-e97178651a4f@github.com> References: <-cXXuyLSgAOPbnU3xs96hNsAM868Cxhld8gGKeVcDJw=.ad9a10e1-aaa0-4943-a396-e97178651a4f@github.com> Message-ID: On Tue, 11 Feb 2025 18:29:08 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp line 1: >> >>> 1: /* >> >> I would recommend to add "fprintf(stderr, XXX NOT IMPLEMENTED\n");" outputs to the the four changed / new functions stubs, as for the older unimplemented methods. >> This would make issues as we had in [JDK-8337481](https://bugs.openjdk.org/browse/JDK-8337481) easier to track. > > That's a good idea. > > @jaybhaskar Can you either make this change or else file a follow-up issue? We have created a follow up bug to track https://bugs.openjdk.org/browse/JDK-8349891 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1703#discussion_r1952337090 From michaelstrau2 at gmail.com Wed Feb 12 12:48:16 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 12 Feb 2025 13:48:16 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> Message-ID: This looks like a nice enhancement. The syntax is similar to CSS features like Grid Layout [0] ("grid-column" and "grid-row" are properties on children of a grid container). We need to figure out how these extension properties work with transitions. They should follow the same transition rules as regular properties. [0] https://www.w3.org/TR/css-grid-1/ From john.hendrikx at gmail.com Wed Feb 12 14:27:00 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 12 Feb 2025 15:27:00 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> Message-ID: <9893e816-d9c9-4924-8ddb-a54730230918@gmail.com> Thanks, I may need some?help with the transition part when the time arrives. In CssStyleHelper these parent defined properties are treated no different from any other properties, but I think some of the transition logic is part of the properties themselves and I didn't implement that so far. How I've implemented them currently is with just-in-time properties that only implement StyleableProperty (so it's not a full property that could be bound).? The actual storage is in the properties map associated with all Nodes. I'll see if I can work this up as a PR over the weekend.? It works already, but needs some polishing and perhaps some optimization as its part of CSS code. --John On 12/02/2025 13:48, Michael Strau? wrote: > This looks like a nice enhancement. The syntax is similar to CSS > features like Grid Layout [0] ("grid-column" and "grid-row" are > properties on children of a grid container). We need to figure out how > these extension properties work with transitions. They should follow > the same transition rules as regular properties. > > [0] https://www.w3.org/TR/css-grid-1/ From jbhaskar at openjdk.org Wed Feb 12 14:56:25 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 12 Feb 2025 14:56:25 GMT Subject: Integrated: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: <4lPMA6mWe8-S-F4ZAJi-4iiS_2o9zBawEkcGWxVjNOg=.f797c9f1-1cc2-4008-94ad-e92d150d81b5@github.com> On Mon, 10 Feb 2025 15:27:49 GMT, Jay Bhaskar wrote: > Webkit JavaFx upgrade from 619.1 to 620.1
    > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen, except one observed CanvasPattern test where it works only on Linux but failed on Mac/Windows (WIP). > Windows build is using clang-cl compiler because Webkit has dropped MSVC compiler support. This pull request has now been integrated. Changeset: 1e691573 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/1e6915738d654e6cf7a547e47b8b020117db6bc3 Stats: 773682 lines in 8157 files changed: 644444 ins; 72180 del; 57058 mod 8340322: Update WebKit to 620.1 Reviewed-by: kcr, sykora, jvos, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1703 From angorya at openjdk.org Wed Feb 12 15:31:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 15:31:19 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> Message-ID: On Wed, 12 Feb 2025 09:59:30 GMT, Alexander Zuev wrote: > I am curious why do we make labels in charts focus traversable when a11y is switched on? I think the reason is to announce the axis values for each data point (that's what the VoiceOver announces on macOS for me) - you can readily try it in the MonkeyTester. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2654058952 From angorya at openjdk.org Wed Feb 12 17:39:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 17:39:57 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v3] In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: > Root Cause: > (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. > > I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. > > Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. > > The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. > > With this change, it is safe to create and populate charts with data in a background thread. > > --- > > ## NOTES > > 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. > 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - enabled pie chart test - Merge branch 'master' into 8349091.charts.thread.safety - Merge branch 'master' into 8349091.charts.thread.safety - whitespace - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - cleanup - tests pass - chart tests only - more jitter - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - ... and 11 more: https://git.openjdk.org/jfx/compare/1e691573...93fc7b93 ------------- Changes: https://git.openjdk.org/jfx/pull/1697/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=02 Stats: 305 lines in 11 files changed: 165 ins; 101 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1697.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697 PR: https://git.openjdk.org/jfx/pull/1697 From angorya at openjdk.org Wed Feb 12 17:43:22 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 17:43:22 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v3] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Wed, 12 Feb 2025 17:39:57 GMT, Andy Goryachev wrote: >> Root Cause: >> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. >> >> I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. >> >> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. >> >> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. >> >> With this change, it is safe to create and populate charts with data in a background thread. >> >> --- >> >> ## NOTES >> >> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. >> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - enabled pie chart test > - Merge branch 'master' into 8349091.charts.thread.safety > - Merge branch 'master' into 8349091.charts.thread.safety > - whitespace > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - cleanup > - tests pass > - chart tests only > - more jitter > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - ... and 11 more: https://git.openjdk.org/jfx/compare/1e691573...93fc7b93 Sorry, forgot to enable the pie chart test. On a positive note, I've tested the last commit in the cumulative branch https://github.com/andy-goryachev-oracle/jfx/tree/ag.thread.safe.init which includes all the fixes, the heap size lowered from 1g to 128m, and the test duration increased 3x to 15 seconds. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2654425798 From michaelstrau2 at gmail.com Wed Feb 12 19:10:10 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 12 Feb 2025 20:10:10 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: <9893e816-d9c9-4924-8ddb-a54730230918@gmail.com> References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> <9893e816-d9c9-4924-8ddb-a54730230918@gmail.com> Message-ID: Maybe we can expand static properties to complete JavaFX properties. Right now, static properties are implemented with a getter and setter on the declaring class. We can add an additional property getter like so: class HBox { public static ObjectProperty marginProperty(Node child); public static void setMargin(Node child, Insets value); public static Insets getMargin(Node child); } Instead of storing the value directly in the properties map, we would store the ObjectProperty instead. In doing that, we can use the Styleable{Double,Object,...}Property implementations, which gives us access to the transition machinery. On Wed, Feb 12, 2025 at 3:27?PM John Hendrikx wrote: > > Thanks, > > I may need some help with the transition part when the time arrives. In > CssStyleHelper these parent defined properties are treated no different > from any other properties, but I think some of the transition logic is > part of the properties themselves and I didn't implement that so far. > > How I've implemented them currently is with just-in-time properties that > only implement StyleableProperty (so it's not a full property that could > be bound). The actual storage is in the properties map associated with > all Nodes. > > I'll see if I can work this up as a PR over the weekend. It works > already, but needs some polishing and perhaps some optimization as its > part of CSS code. From dlemmermann at gmail.com Wed Feb 12 19:31:13 2025 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Wed, 12 Feb 2025 20:31:13 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> Message-ID: <5AAC2AD4-04DE-491F-BF0F-BADF75A4CF2F@gmail.com> I would love to be able to do this. Dirk > Am 11.02.2025 um 23:47 schrieb John Hendrikx : > > Hi list, > > I've done a little proof of concept where I've made some minor modifications to CssStyleHelper to allow the CSS engine to offer styleable properties on children, but defined by the container class. > > What this means is that we can make it appear that direct children of a container like GridPane, HBox and VBox have properties like: `vgrow`, `hgrow`, `column-index`, `margin`, `halignment`, `fill-width` etc. The exact names can be chosen by the container in question. For example, I could style a child of an HBox like this: > > .text-field { > -fx-background-color: yellow; > -fx-hbox-hgrow: ALWAYS; > -fx-hbox-margin: 5px; > } > > This will make it possible to do far more visual styling directly in CSS. As usual, unrecognized properties are ignored, so if you put this text field in a VBox, nothing will happen. > > How does it work? > > - Containers that wish to add additional styleable properties to their direct descendants implement this interface: > > public interface ChildStyleProvider { > List> getChildCssMetaData(Node child); > } > - The CssMetaData they provide for these properties looks like this for example: > > > new CssMetaData<>("-fx-hbox-hgrow", StyleConverter.getEnumConverter(Priority.class)) { > @Override > public boolean isSettable(Styleable styleable) { > return true; > } > > @Override > public StyleableProperty getStyleableProperty(Styleable styleable) { > return ChildStyleProvider.createProp(this, "hbox-hgrow", child); > } > } > - A special StyleableProperty is created as the "receiver" of CSS styling that will store the value in the Node#getProperties map (where normally these values are already stored when using the static methods like HBox.setHGrow(Node, Priority) type methods). This property is cached as part of the same getProperties map, so it is only created once. > > - The CssStyleHelper will see if the parent of the Node being styled implements ChildStyleProvider, and if so will also process these additional CssMetaData properties when any are present; this seems to be fairly safe to do, as changing a Node's parent will reset all its styling already. Some more tests are needed here, if moving this forward. > > That is basically the change in a nutshell. Not only does setting a property like `-fx-hbox-hgrow` on a child now act as if you called `HBox.setHGrow`, changing the style of the child can also change these settings and HBox will instantly respond to the change. When the style is completely removed, it will also null the hgrow value which is translated as removing that key from the Node#getProperties map. > > If people think this proposal has some merit, I can flesh it out further and make it into a PR. > > --John > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Feb 12 19:49:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 19:49:59 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread Message-ID: ## Root Cause Animation was started in the background thread, causing concurrent access. ## Solution Disable animation if not the fx app thread. ------------- Commit messages: - the fix - Merge branch 'master' into 8349255.thread.safe.titled.pane - Merge branch 'master' into 8349255.thread.safe.titled.pane - get parent - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - review comments - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - more jitter - disabled titled pane test - ... and 15 more: https://git.openjdk.org/jfx/compare/1e691573...8426f326 Changes: https://git.openjdk.org/jfx/pull/1707/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1707&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349255 Stats: 28 lines in 3 files changed: 11 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1707.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1707/head:pull/1707 PR: https://git.openjdk.org/jfx/pull/1707 From angorya at openjdk.org Wed Feb 12 19:49:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 19:49:59 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread In-Reply-To: References: Message-ID: <39f5wlb5NdV3XQ4D8QCJhHocpvN_wFIlsSTjjqc8Sz0=.a9dfcaac-3111-4765-bd0b-fae7d7dccb06@github.com> On Wed, 12 Feb 2025 19:07:19 GMT, Andy Goryachev wrote: > ## Root Cause > > Animation was started in the background thread, causing concurrent access. > > ## Solution > > Disable animation if not the fx app thread. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1442: > 1440: // of this node, since visibility affects bounds of the > 1441: // parent node > 1442: p.childVisibilityChanged(Node.this); it was a part of an earlier attempt, but I think this code is better. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1707#discussion_r1953255378 From angorya at openjdk.org Wed Feb 12 20:21:28 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 20:21:28 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread Message-ID: ## Root Cause Focus is being requested in show(), even a background thread. ## Solution Do not request focus if in a background thread. ------------- Commit messages: - date picker fix Changes: https://git.openjdk.org/jfx/pull/1708/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1708&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349004 Stats: 32 lines in 2 files changed: 13 ins; 14 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1708.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1708/head:pull/1708 PR: https://git.openjdk.org/jfx/pull/1708 From angorya at openjdk.org Wed Feb 12 20:32:30 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 20:32:30 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread Message-ID: ## Root Cause The ContextMenu (PopupWindow) cannot be shown in a background thread. ## Solution Bail out of `show()` if in a background thread. ------------- Commit messages: - split / menu button fix Changes: https://git.openjdk.org/jfx/pull/1709/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1709&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349096 Stats: 13 lines in 2 files changed: 4 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1709.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1709/head:pull/1709 PR: https://git.openjdk.org/jfx/pull/1709 From kcr at openjdk.org Wed Feb 12 22:01:28 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 22:01:28 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 03:00:17 GMT, Alexander Matveev wrote: > - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. > - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. > - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. > - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. The code looks reasonable. I left a few minor questions / comments. I'll reapprove if you make any changes. All my testing looks good (I only tested on Windows, since this is in Windows-only code). modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfgstbuffer.cpp line 215: > 213: return E_INVALIDARG; > 214: > 215: // If we have GStreamer get buffer cllback set, then call it to get Minor typo: `cllback` --> `callback` modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfgstbuffer.cpp line 242: > 240: } > 241: // Lock can be called multiple times, so if we have GStreamer buffer > 242: // allocated just return it. Is it actually possible that Lock can be called multiple times? If it is, then I see that you don't keep track of the number of calls to Lock, so is it correct to assume that the caller does not match Lock / Unlock calls, but rather calls Unlock only once regardless of the number of calls to Lock? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfgstbuffer.h line 69: > 67: HRESULT AllocateOrGetBuffer(BYTE **ppbBuffer); > 68: > 69: private: Minor: isn't this redundant? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 911: > 909: > 910: // Gets max length of configured media buffer we using for final rendering from > 911: // decoder ot color convert. Minor: "ot" --> "of" ? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1695#pullrequestreview-2613223582 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953422605 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953457463 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953409208 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953447469 From kcr at openjdk.org Wed Feb 12 22:52:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 22:52:15 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:45:32 GMT, Andy Goryachev wrote: > ## Root Cause > > Focus is being requested in show(), even a background thread. > > ## Solution > > Do not request focus if in a background thread. Reviewers: @kevinrushforth @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2655012247 From mstrauss at openjdk.org Wed Feb 12 23:06:13 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 12 Feb 2025 23:06:13 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: References: Message-ID: <4xfaCh_7si5PoT3AzJZaeZ1fsqX3rsFljAKJPrdnJBY=.aaa57ce8-f47c-4973-8fcf-8c1312449f7f@github.com> On Wed, 12 Feb 2025 20:15:03 GMT, Andy Goryachev wrote: > ## Root Cause > > The ContextMenu (PopupWindow) cannot be shown in a background thread. > > ## Solution > > Bail out of `show()` if in a background thread. I'm not convinced that this is the right solution. `Node` says: * Node objects may be constructed and modified on any thread as long they are * not yet attached to a {@link Scene} in a {@link Window} that is * {@link Window#isShowing showing}. It's not clear to me that invoking actions on a node should count as "modifying", and there is no specification that says it's okay to invoke actions on a non-UI thread. I'd rather have actions throw an exception if they are invoked on a background thread, rather than silently not doing anything at all. It's one thing to configure (i.e. modify) properties of a node, and then show it in the scene graph; it's another thing to tell it to do something it can't do in its current state. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1709#issuecomment-2655033677 From kcr at openjdk.org Wed Feb 12 23:13:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:13:14 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:45:32 GMT, Andy Goryachev wrote: > ## Root Cause > > Focus is being requested in show(), even a background thread. > > ## Solution > > Do not request focus if in a background thread. I'm not sure this fix is sufficient in all cases. As I mentioned in the bug report, I think we need to consider disallowing calling `ComboBoxBaseSkin::show` (including the overridden methods in the subclasses) from a background thread. At a minimum, we need to ensure that the `ComboBoxBaseSkin::show` implementations never call any of the `PopupWindow::show` method. In looking at the code, it seems possible that there are some cases where it might. It is already a documented (and enforced) error to call Window::show -- and by extension, the various `PopupWindow::show` methods on a background thread. I note that the `PopupWindow::show` methods are not documented to throw, but they do throw when they call the no-arg `Window::show` method, which they do if the parent Window is visible, so a documented, fail-fast exception check is best. So I think we need to do one of two things in each of the three overridden `ComboBoxBaseSkin::show` methods (`ComboBoxPopupControl`, `ColorPickerSkin`, `DatePickerSkin`). 1. Change the spec and implementation to throw an exception if `ComboBoxBaseSkin::show` is called on a thread other than the FX Application Thread 2. Go with the currently proposed fix, but also ensure that our implementations of`ComboBoxBaseSkin::show` don't call any of the `PopupWindow::show` methods on a background thread II lean toward option 1, since I can't think of a good reason for an app to call show() from a background thread. Either way, I want to see a follow-up bug filed to document that the three `PopupWindow::show` methods must be called on the FX app thread (with a check to fail fast if they don't so that it is caught in all cases). ------------- PR Review: https://git.openjdk.org/jfx/pull/1708#pullrequestreview-2613431873 From kcr at openjdk.org Wed Feb 12 23:21:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:21:17 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: <0fR1tTYmR8Q4oweYIGRI_rm8nE-3qXmRu3s4jzR_dr0=.d1832448-caf3-42e9-b95f-63287aee5d19@github.com> On Wed, 12 Feb 2025 19:45:32 GMT, Andy Goryachev wrote: > ## Root Cause > > Focus is being requested in show(), even a background thread. > > ## Solution > > Do not request focus if in a background thread. I took a quick look at PR #1709 which has a similar problem with its show method, and there is a third option we should consider: 3. Change the implementation of all skin show methods to do nothing (bail out early) if not on the FX application thread. If we do this, I would want to see it documented. In any case, I'd like to pause the reviews of the individual PRs that touch the skin's `show` method until we resolve the larger question of what to do about `*Skin::show`. One thing that would help inform the discussion: Why did you call show in the first place in your NodeInitStressTest (for that matter, why directly call _any_ skin methods, since apps generally don't)? Was it just something you did to stress it, or is it reflective of a normal operation that an app might do during initialization of a node on a background thread? I have a feeling it's the former, but maybe I'm missing something. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2655054885 From john.hendrikx at gmail.com Wed Feb 12 23:21:57 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 13 Feb 2025 00:21:57 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> <9893e816-d9c9-4924-8ddb-a54730230918@gmail.com> Message-ID: Yeah, it may be possible to do this; as said, I'm already storing a StyleableProperty in the map (as it is needed to track the style origin for the CSS system, otherwise it will never reset it when styles changes), and exposing this property via a static property method would certainly be trivial to do.?? Currently I'm storing the property and actual value in separate keys, but I suppose there is no reason to have a separate key if the property would hold the value.? I think that storing only a property would be a better solution, perhaps with some code to avoid creating the property similar to how lazy properties are done currently. This sounds promising, I'll look into it and see if I can get this incorporated in the PoC. --John On 12/02/2025 20:10, Michael Strau? wrote: > Maybe we can expand static properties to complete JavaFX properties. > > Right now, static properties are implemented with a getter and setter > on the declaring class. We can add an additional property getter like > so: > > class HBox { > public static ObjectProperty marginProperty(Node child); > public static void setMargin(Node child, Insets value); > public static Insets getMargin(Node child); > } > > Instead of storing the value directly in the properties map, we would > store the ObjectProperty instead. In doing that, we can use the > Styleable{Double,Object,...}Property implementations, which gives us > access to the transition machinery. > > > On Wed, Feb 12, 2025 at 3:27?PM John Hendrikx wrote: >> Thanks, >> >> I may need some help with the transition part when the time arrives. In >> CssStyleHelper these parent defined properties are treated no different >> from any other properties, but I think some of the transition logic is >> part of the properties themselves and I didn't implement that so far. >> >> How I've implemented them currently is with just-in-time properties that >> only implement StyleableProperty (so it's not a full property that could >> be bound). The actual storage is in the properties map associated with >> all Nodes. >> >> I'll see if I can work this up as a PR over the weekend. It works >> already, but needs some polishing and perhaps some optimization as its >> part of CSS code. From kcr at openjdk.org Wed Feb 12 23:23:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:23:16 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 20:15:03 GMT, Andy Goryachev wrote: > ## Root Cause > > The ContextMenu (PopupWindow) cannot be shown in a background thread. > > ## Solution > > Bail out of `show()` if in a background thread. Let's resolve the general question regarding what to do about the various `*Skin::show` methods before reviewing this particular PR. See #1708 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1709#issuecomment-2655058326 From kcr at openjdk.org Wed Feb 12 23:29:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:29:16 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:45:32 GMT, Andy Goryachev wrote: > ## Root Cause > > Focus is being requested in show(), even a background thread. > > ## Solution > > Do not request focus if in a background thread. Even after considering option 3, I prefer option 1. I can't think of a good reason to allow a show method that will fail in some case (because it is documented that an app can't show a window on a background thread). A clear exception seems better than silently making it a no-op. @mstr2 said something similar in #1709 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2655065374 From angorya at openjdk.org Wed Feb 12 23:38:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 23:38:16 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: <0fR1tTYmR8Q4oweYIGRI_rm8nE-3qXmRu3s4jzR_dr0=.d1832448-caf3-42e9-b95f-63287aee5d19@github.com> References: <0fR1tTYmR8Q4oweYIGRI_rm8nE-3qXmRu3s4jzR_dr0=.d1832448-caf3-42e9-b95f-63287aee5d19@github.com> Message-ID: On Wed, 12 Feb 2025 23:18:37 GMT, Kevin Rushforth wrote: > Why did you call show in the first place in your NodeInitStressTest (for that matter, why directly call _any_ skin methods, since apps generally don't) 1. `show()` javadoc says "display the popup _**aspect**_ of the user interface", which I interpreted as something that could in theory be an acceptable operation. For example, ColorPicker does not fail in its `show()`. 2. `show()` is not a skin method (see `ComboBoxBase`). The reason the skin is explicitly set in the test is because (in theory) we ought to support custom controls and/or custom skins. In other words, calling `Control.setSkin()` from a background thread is also an acceptable operation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2655077467 From angorya at openjdk.org Wed Feb 12 23:41:14 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 23:41:14 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 23:11:08 GMT, Kevin Rushforth wrote: > 1. Change the spec and implementation to throw an exception if `ComboBoxBaseSkin::show` is called on a thread other than the FX Application Thread I like this option! Does it mean ColorPicker.show() should also throw? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2655082072 From kcr at openjdk.org Wed Feb 12 23:46:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:46:16 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: <9OUvQzK-wpbhokaLoF8Xpn-_DrPA3hcMw1uUHBd3iOU=.09e3d0bc-38a2-4666-a0f5-f35852d01130@github.com> On Wed, 12 Feb 2025 23:39:07 GMT, Andy Goryachev wrote: > > 1. Change the spec and implementation to throw an exception if `ComboBoxBaseSkin::show` is called on a thread other than the FX Application Thread > > I like this option! > > Does it mean ColorPicker.show() should also throw? Yes. If we do this -- and I think we should strongly consider it -- all of the `show` methods in Control, PopupWindow, and Skin should throw on a background thread. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2655091487 From angorya at openjdk.org Wed Feb 12 23:51:12 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Feb 2025 23:51:12 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: <4xfaCh_7si5PoT3AzJZaeZ1fsqX3rsFljAKJPrdnJBY=.aaa57ce8-f47c-4973-8fcf-8c1312449f7f@github.com> References: <4xfaCh_7si5PoT3AzJZaeZ1fsqX3rsFljAKJPrdnJBY=.aaa57ce8-f47c-4973-8fcf-8c1312449f7f@github.com> Message-ID: <030QNBlJUNVI_g146ARTjX-1arlCBnj5yt-azrhT2Qk=.2bdb8e23-fa25-4560-a7a5-acc556a03f20@github.com> On Wed, 12 Feb 2025 23:03:45 GMT, Michael Strau? wrote: > It's not clear to me that invoking actions on a node should count as "modifying" I agree with this statement. What threw me off is the way javadoc for `show()` is currently phrased: "popup aspects" implies something else beyond the simple aspect, for example, it could be a visible property on a detail pane or selected tab/page. Should we also remove the word "aspects" from `ComboBoxBase::show` then? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1709#issuecomment-2655096199 From kcr at openjdk.org Wed Feb 12 23:51:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:51:13 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: References: Message-ID: <-rqSF1FVdDEKgBHrhR-CEEpUDZdMqnrlXRw8rj-2b-0=.028c3af7-27f7-4f28-9f01-7a5fd2c8949c@github.com> On Wed, 12 Feb 2025 20:15:03 GMT, Andy Goryachev wrote: > ## Root Cause > > The ContextMenu (PopupWindow) cannot be shown in a background thread. > > ## Solution > > Bail out of `show()` if in a background thread. One more reason to disallow show in this case is that ContextMenu is a descendent of PopupWindow, and whatever else we do, we need to disallow calling `PopupWindow::show` from a background thread. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1709#issuecomment-2655097696 From kcr at openjdk.org Wed Feb 12 23:51:14 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Feb 2025 23:51:14 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: <030QNBlJUNVI_g146ARTjX-1arlCBnj5yt-azrhT2Qk=.2bdb8e23-fa25-4560-a7a5-acc556a03f20@github.com> References: <4xfaCh_7si5PoT3AzJZaeZ1fsqX3rsFljAKJPrdnJBY=.aaa57ce8-f47c-4973-8fcf-8c1312449f7f@github.com> <030QNBlJUNVI_g146ARTjX-1arlCBnj5yt-azrhT2Qk=.2bdb8e23-fa25-4560-a7a5-acc556a03f20@github.com> Message-ID: <_jSpUxeC21MW11Zjef7b0UE5X-xSiuuVOpkWXMLwZuI=.cab0daab-ad73-413c-a97e-4967a120a5ee@github.com> On Wed, 12 Feb 2025 23:45:55 GMT, Andy Goryachev wrote: > What threw me off is the way javadoc for show() is currently phrased: "popup aspects" implies something else beyond the simple aspect, for example, it could be a visible property on a detail pane or selected tab/page. > > Should we also remove the word "aspects" from ComboBoxBase::show then? Yeah, maybe this could be made clearer at the same time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1709#issuecomment-2655101665 From almatvee at openjdk.org Thu Feb 13 03:11:20 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 13 Feb 2025 03:11:20 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 21:25:15 GMT, Kevin Rushforth wrote: >> - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. >> - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. >> - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. >> - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. > > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfgstbuffer.cpp line 215: > >> 213: return E_INVALIDARG; >> 214: >> 215: // If we have GStreamer get buffer cllback set, then call it to get > > Minor typo: `cllback` --> `callback` Fixed. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfgstbuffer.cpp line 242: > >> 240: } >> 241: // Lock can be called multiple times, so if we have GStreamer buffer >> 242: // allocated just return it. > > Is it actually possible that Lock can be called multiple times? If it is, then I see that you don't keep track of the number of calls to Lock, so is it correct to assume that the caller does not match Lock / Unlock calls, but rather calls Unlock only once regardless of the number of calls to Lock? Yes, based on documentation Lock() can be called multiple times to acquire pointer and it should be valid until last Unlock() is called. The caller is responsible to match Lock / Unlock calls. So, current implementation is not correct. I will fixed it. Also, based on documentation Lock() can be called from separate threads, so it should be thread safe. I will fix it as well. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfgstbuffer.h line 69: > >> 67: HRESULT AllocateOrGetBuffer(BYTE **ppbBuffer); >> 68: >> 69: private: > > Minor: isn't this redundant? Yes, fixed. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 911: > >> 909: >> 910: // Gets max length of configured media buffer we using for final rendering from >> 911: // decoder ot color convert. > > Minor: "ot" --> "of" ? Should be "or". Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953718149 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953719959 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953718066 PR Review Comment: https://git.openjdk.org/jfx/pull/1695#discussion_r1953718323 From almatvee at openjdk.org Thu Feb 13 03:51:28 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 13 Feb 2025 03:51:28 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] In-Reply-To: References: Message-ID: > - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. > - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. > - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. > - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1695/files - new: https://git.openjdk.org/jfx/pull/1695/files/4bc76966..0cf270ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1695&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1695&range=00-01 Stats: 110 lines in 3 files changed: 60 ins; 12 del; 38 mod Patch: https://git.openjdk.org/jfx/pull/1695.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1695/head:pull/1695 PR: https://git.openjdk.org/jfx/pull/1695 From almatvee at openjdk.org Thu Feb 13 03:51:28 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 13 Feb 2025 03:51:28 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 03:00:17 GMT, Alexander Matveev wrote: > - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. > - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. > - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. > - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] - Fixed typos. - Lock / Unlock is now thread safe and last Unlock will unmap buffer. - AllocateOrGetBuffer() is updated to remap unmapped buffer and split into two logical sections. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1695#issuecomment-2655410557 From arapte at openjdk.org Thu Feb 13 06:51:16 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 13 Feb 2025 06:51:16 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 18:42:01 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Skip the animation. >> >> The fix is similar to https://github.com/openjdk/jfx/pull/1698 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349098.thread.safe.tabpane > - skip animation LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1699#pullrequestreview-2614009900 From azvegint at openjdk.org Thu Feb 13 11:58:38 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 13 Feb 2025 11:58:38 GMT Subject: RFR: 8349256: Update PipeWire to 1.3.81 Message-ID: This changeset updates the pipewire headers to the 1.3.81, and it is the same as for the [OpenJDK](https://github.com/openjdk/jdk/pull/23426) It contains the minimum set of required header files needed to build the JFX. The updated headers are a direct copy from the https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the \t -> replacement) ------------- Commit messages: - initial Changes: https://git.openjdk.org/jfx/pull/1710/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349256 Stats: 2369 lines in 72 files changed: 1728 ins; 59 del; 582 mod Patch: https://git.openjdk.org/jfx/pull/1710.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1710/head:pull/1710 PR: https://git.openjdk.org/jfx/pull/1710 From arapte at openjdk.org Thu Feb 13 12:48:20 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 13 Feb 2025 12:48:20 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 18:42:01 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Skip the animation. >> >> The fix is similar to https://github.com/openjdk/jfx/pull/1698 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349098.thread.safe.tabpane > - skip animation modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 523: > 521: }; > 522: > 523: if (Platform.isFxApplicationThread() && (closeTabAnimation.get() == TabAnimation.GROW)) { With this check, non Application thread cannot play the animation but in else block the `cleanup` is executed on the same thread. Can there still be a situation when, this non-Application thread and Application thread be concurrently modifying the tab? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1699#discussion_r1954431776 From kcr at openjdk.org Thu Feb 13 13:58:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 13:58:17 GMT Subject: RFR: 8349256: Update PipeWire to 1.3.81 In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 11:54:01 GMT, Alexander Zvegintsev wrote: > This changeset updates the pipewire headers to the 1.3.81, and it is the same as for the [OpenJDK](https://github.com/openjdk/jdk/pull/23426) > > It contains the minimum set of required header files needed to build the JFX. > > The updated headers are a direct copy from the > https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the \t -> replacement) Reviewers: @kevinrushforth @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/1710#issuecomment-2656674090 From lkostyra at openjdk.org Thu Feb 13 14:49:21 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 13 Feb 2025 14:49:21 GMT Subject: RFR: 8349256: Update PipeWire to 1.3.81 In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 11:54:01 GMT, Alexander Zvegintsev wrote: > This changeset updates the pipewire headers to the 1.3.81, and it is the same as for the [OpenJDK](https://github.com/openjdk/jdk/pull/23426) > > It contains the minimum set of required header files needed to build the JFX. > > The updated headers are a direct copy from the > https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the \t -> replacement) Looks good - builds and runs fine. Did a quick random media test with Ensemble8 on 24.04 and did not notice any issues. ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1710#pullrequestreview-2615225705 From arapte at openjdk.org Thu Feb 13 14:52:24 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 13 Feb 2025 14:52:24 GMT Subject: RFR: 8349756: Memory leak in PaginationSkin when setting page count / index [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 22:22:59 GMT, Andy Goryachev wrote: >> ## Root Cause >> >> Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. >> >> ## Solution >> >> Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > back to constructor LGTM too.. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1705#pullrequestreview-2615236964 From angorya at openjdk.org Thu Feb 13 15:24:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 13 Feb 2025 15:24:19 GMT Subject: Integrated: 8349756: Memory leak in PaginationSkin when setting page count / index In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:46:17 GMT, Andy Goryachev wrote: > ## Root Cause > > Each time a `PaginationSkin.IndicatorButton` gets created it adds two listeners (to the control's `styleClass` property and to the skin's tooltipVisible property) via `ListenerHelper`. This was not detected by the `SkinMemoryLeakTest` because all listeners got removed correctly upon skin change. > > ## Solution > > Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing. This pull request has now been integrated. Changeset: 167e1ee5 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/167e1ee5513a7d769b24f2c74aebdd57c0d93722 Stats: 45 lines in 1 file changed: 27 ins; 13 del; 5 mod 8349756: Memory leak in PaginationSkin when setting page count / index Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1705 From kcr at openjdk.org Thu Feb 13 17:24:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 17:24:16 GMT Subject: RFR: 8349256: Update PipeWire to 1.3.81 In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 11:54:01 GMT, Alexander Zvegintsev wrote: > This changeset updates the pipewire headers to the 1.3.81, and it is the same as for the [OpenJDK](https://github.com/openjdk/jdk/pull/23426) > > It contains the minimum set of required header files needed to build the JFX. > > The updated headers are a direct copy from the > https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the \t -> replacement) I confirmed that the files are identical to their recently-updated counterparts in the JDK. Sanity test looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1710#pullrequestreview-2615745900 From mstrauss at openjdk.org Thu Feb 13 18:29:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Feb 2025 18:29:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v48] 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 62 commits: - Merge branch 'master' into feature/extended-window - Remove HeaderBarBase - Added HeaderBarBase.prefButtonHeight, removed Stage.initDefaultHeaderButtons - add "maximized" pseudo-class for custom maximize button - move StageTester to Tools menu - macOS bugfixes, default button behavior - added StageTester to MonkeyTester - small MonkeyTester refactor - add samples in MonkeyTester - typo - ... and 52 more: https://git.openjdk.org/jfx/compare/167e1ee5...00b9be76 ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=47 Stats: 6430 lines in 73 files changed: 5764 ins; 499 del; 167 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 Thu Feb 13 18:38:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 18:38:15 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:07:19 GMT, Andy Goryachev wrote: > ## Root Cause > > Animation was started in the background thread, causing concurrent access. > > ## Solution > > Disable animation if not the fx app thread. The fix looks good. I'll test it later. I left one comment about the change in Parent that I think should be reverted (it's a minor cleanup in a file that you otherwise aren't touching). ------------- PR Review: https://git.openjdk.org/jfx/pull/1707#pullrequestreview-2615916401 From kcr at openjdk.org Thu Feb 13 18:38:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 18:38:16 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread In-Reply-To: <39f5wlb5NdV3XQ4D8QCJhHocpvN_wFIlsSTjjqc8Sz0=.a9dfcaac-3111-4765-bd0b-fae7d7dccb06@github.com> References: <39f5wlb5NdV3XQ4D8QCJhHocpvN_wFIlsSTjjqc8Sz0=.a9dfcaac-3111-4765-bd0b-fae7d7dccb06@github.com> Message-ID: <3r8oriMxXKMRbPx1hXm8px5-KZLIWNvBaK_b3abeBeg=.108ceb6c-3f91-4b2a-a303-5029af2ffa64@github.com> On Wed, 12 Feb 2025 19:10:30 GMT, Andy Goryachev wrote: >> ## Root Cause >> >> Animation was started in the background thread, causing concurrent access. >> >> ## Solution >> >> Disable animation if not the fx app thread. > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1442: > >> 1440: // of this node, since visibility affects bounds of the >> 1441: // parent node >> 1442: p.childVisibilityChanged(Node.this); > > it was a part of an earlier attempt, but I think this code is better. I'd still revert it, since it is unrelated to the fix under review and is in a file that is otherwise untouched. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1707#discussion_r1955033058 From mstrauss at openjdk.org Thu Feb 13 18:45:26 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Feb 2025 18:45:26 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v48] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 18:29:08 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 62 commits: > > - Merge branch 'master' into feature/extended-window > - Remove HeaderBarBase > - Added HeaderBarBase.prefButtonHeight, removed Stage.initDefaultHeaderButtons > - add "maximized" pseudo-class for custom maximize button > - move StageTester to Tools menu > - macOS bugfixes, default button behavior > - added StageTester to MonkeyTester > - small MonkeyTester refactor > - add samples in MonkeyTester > - typo > - ... and 52 more: https://git.openjdk.org/jfx/compare/167e1ee5...00b9be76 I've simplified and fine-tuned the API a bit: 1. `HeaderBarBase` is removed, and its functionality is rolled into `HeaderBar`. The rationale for the base class was that it allows developers to create new header bar implementations, but I now think that it is easier to just use the fully-featured `HeaderBar` class as a starting point, and drop any custom implementation into its `center` slot. 2. `HeaderBar.setPrefHeaderButtonHeight(Stage, double)` is added, which allows applications to explicitly express a preference how tall the header buttons should be. This makes it possible to control the appearance of header buttons (for example, have the header buttons match the height of the title bar). 3. `Stage.initDefaultHeaderButtons()` is removed. Instead, set `HeaderBar.setPrefHeaderButtonHeight` to zero in order to remove the system-provided header buttons. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2657442887 From mstrauss at openjdk.org Thu Feb 13 18:48:22 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Feb 2025 18:48:22 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:58:37 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> add "maximized" pseudo-class for custom maximize button > > modules/javafx.base/src/test/java/test/util/ReflectionUtils.java line 41: > >> 39: * The field can be declared on any of the object's inherited classes. >> 40: */ >> 41: @SuppressWarnings("unchecked") > > is this annotation still needed (the build gives no warnings when it's removed)? My IDE shows a warning for L58: `Unchecked cast: java.lang.Object to T`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1955048459 From mstrauss at openjdk.org Thu Feb 13 18:54:22 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Feb 2025 18:54:22 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 20:51:59 GMT, Andy Goryachev wrote: > I wonder if the header bar needs to get clipped somehow: I don't think that's possible, layout containers never visually clip their contents (i.e. prevent pixels from being drawn). > (also weird padding around buttons in the left content area) Yes, it's a bit strange. I think these are bugs in `SplitPane`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2657459334 From mstrauss at openjdk.org Thu Feb 13 19:10:15 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Feb 2025 19:10:15 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] 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 two additional commits since the last revision: - typo - update copyright headers ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/00b9be76..1f95e9db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=48 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=47-48 Stats: 32 lines in 31 files changed: 0 ins; 0 del; 32 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 Thu Feb 13 19:34:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 19:34:16 GMT Subject: RFR: 8349373: Support JavaFX preview features [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 09:16:54 GMT, Michael Strau? wrote: >> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. > > Michael Strau? has updated the pull request incrementally with four additional commits since the last revision: > > - javadoc > - remove supporting documentation > - warning can't be suppressed > - initialize PreviewFeature early The changes look good. I thought of one more option we might consider to check that the version of the preview API that the app compiled against matches the runtime version of the JavaFX runtime. Whether it is worth doing is something we can discuss. ------------- PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2615933747 From kcr at openjdk.org Thu Feb 13 19:34:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 19:34:17 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: <8RHKVr7d8HBbmtIJkXTx10wybGBgE3kU2gnKpDxB71U=.0d7575a4-48d1-4404-a20a-dc8e5adae9bf@github.com> References: <8RHKVr7d8HBbmtIJkXTx10wybGBgE3kU2gnKpDxB71U=.0d7575a4-48d1-4404-a20a-dc8e5adae9bf@github.com> Message-ID: <3EApAYPluGigRhXwLEIZHSblmg4GSmmghdJe2ECiyHM=.2dbe6910-509d-4d0b-a6dc-ba15a06cdd6b@github.com> On Fri, 7 Feb 2025 15:07:26 GMT, Michael Strau? wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 52: >> >>> 50: private static final String SUPPRESS_WARNING_PROPERTY = "javafx.suppressPreviewBanner"; >>> 51: >>> 52: private static final boolean enabled = Boolean.getBoolean(ENABLE_PREVIEW_PROPERTY); >> >> The JDK requires that you opt into preview features _for a specific version_. That is, rather than a boolean, the JDK uses an integer feature release value that must match the current release. They do this by using the `--release` option (in connection with the `--enable-preview`), and compiling that into the class file, which we can't directly use. Maybe we can do something similar, though? > > This is only done at compilation time, not at runtime. JEP 12 elaborates on this: > >> --enable-preview itself does not take a version number because it would be easy to misinterpret. For example, on JDK 18, the (hypothetical) flag --enable-preview 19 would appear to suggest support for the preview features of JDK 19, but those features are not known at the time of JDK 18's release. Yeah, that's what I came to realize as well. So our property should remain boolean. The only other thing I could think of is for us to provide a new utility method (in some class in javafx.base) that an application must call to register the version of JavaFX API that are compiling against. For example, imagine a `java.javafx.util.PreviewFeatures` class with the following method: public void setVersion(int featureVersion) {} An application would need to call `PreviewFeatures.setVersion(25)` to use JavaFX preview features from JavaFX 25. That method would unlock preview features only if the version passed in matches the runtime feature version. This would be in addition to the boolean system property. The question is whether it is worth the additional complexity (not for us to implement, that's trivial unless I'm missing something), but rather than documentation and burden on the app developer using a preview feature. The docs for each new preview feature would need to link to the PreviewFeatures utility class to describe how to unlock the features. On the plus side, it would provide a common place to document how to unlock preview features -- "call this method from the application and set that system property on the command line when running the app". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1955043411 From duke at openjdk.org Thu Feb 13 21:34:19 2025 From: duke at openjdk.org (duke) Date: Thu, 13 Feb 2025 21:34:19 GMT Subject: Withdrawn: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup In-Reply-To: References: Message-ID: <9SytJBMB089ZzMz7A7eLvhs14oFlyt-sL8nYChDSSt8=.a6aa415e-ca17-4319-8e3c-4eabdc11237f@github.com> On Fri, 22 Nov 2024 20:31:08 GMT, Marius Hanl wrote: > This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. > > While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. > > It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). > Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1645 From mstrauss at openjdk.org Thu Feb 13 21:56:19 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Feb 2025 21:56:19 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: <3EApAYPluGigRhXwLEIZHSblmg4GSmmghdJe2ECiyHM=.2dbe6910-509d-4d0b-a6dc-ba15a06cdd6b@github.com> References: <8RHKVr7d8HBbmtIJkXTx10wybGBgE3kU2gnKpDxB71U=.0d7575a4-48d1-4404-a20a-dc8e5adae9bf@github.com> <3EApAYPluGigRhXwLEIZHSblmg4GSmmghdJe2ECiyHM=.2dbe6910-509d-4d0b-a6dc-ba15a06cdd6b@github.com> Message-ID: On Thu, 13 Feb 2025 18:41:21 GMT, Kevin Rushforth wrote: >> This is only done at compilation time, not at runtime. JEP 12 elaborates on this: >> >>> --enable-preview itself does not take a version number because it would be easy to misinterpret. For example, on JDK 18, the (hypothetical) flag --enable-preview 19 would appear to suggest support for the preview features of JDK 19, but those features are not known at the time of JDK 18's release. > > Yeah, that's what I came to realize as well. So our property should remain boolean. > > The only other thing I could think of is for us to provide a new utility method (in some class in javafx.base) that an application must call to register the version of JavaFX API that are compiling against. For example, imagine a `java.javafx.util.PreviewFeatures` class with the following method: > > > public void setVersion(int featureVersion) {} > > > An application would need to call `PreviewFeatures.setVersion(25)` to use JavaFX preview features from JavaFX 25. That method would unlock preview features only if the version passed in matches the runtime feature version. This would be in addition to the boolean system property. > > The question is whether it is worth the additional complexity (not for us to implement, that's trivial unless I'm missing something), but rather than documentation and burden on the app developer using a preview feature. The docs for each new preview feature would need to link to the PreviewFeatures utility class to describe how to unlock the features. On the plus side, it would provide a common place to document how to unlock preview features -- "call this method from the application and set that system property on the command line when running the app". I wouldn't be in favor of requiring application developers to call a method to unlock a preview API. It seems a bit too cumbersome and intrusive to me, since it requires you to embed build information into your source code. I've also never seen this in other libraries or frameworks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1955264014 From kcr at openjdk.org Thu Feb 13 23:30:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 23:30:15 GMT Subject: RFR: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 20:15:03 GMT, Andy Goryachev wrote: > ## Root Cause > > The ContextMenu (PopupWindow) cannot be shown in a background thread. > > ## Solution > > Bail out of `show()` if in a background thread. I took another look today, and I am convinced that we need to change the spec and implementation of all `show` and `hide` methods to enforce the threading restriction that they must only be called on the JavaFX Application thread. I filed the following bug to do this: [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048): Enforce threading restrictions for show and hide methods in Window, Control, and Skin Therefore, this PR should be withdrawn and the bug should be closed as a Duplicate of JDK-8350048. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1709#issuecomment-2657919263 From kcr at openjdk.org Thu Feb 13 23:30:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 23:30:15 GMT Subject: RFR: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:45:32 GMT, Andy Goryachev wrote: > ## Root Cause > > Focus is being requested in show(), even a background thread. > > ## Solution > > Do not request focus if in a background thread. I took another look today, and I am convinced that we need to change the spec and implementation of all `show` and `hide` methods to enforce the threading restriction that they must only be called on the JavaFX Application thread. I filed the following bug to do this: [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048): Enforce threading restrictions for show and hide methods in Window, Control, and Skin Therefore, this PR should be withdrawn and the bug should be closed as a Duplicate of JDK-8350048. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1708#issuecomment-2657918889 From kcr at openjdk.org Thu Feb 13 23:42:17 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 23:42:17 GMT Subject: RFR: 8349373: Support JavaFX preview features [v2] In-Reply-To: References: <8RHKVr7d8HBbmtIJkXTx10wybGBgE3kU2gnKpDxB71U=.0d7575a4-48d1-4404-a20a-dc8e5adae9bf@github.com> <3EApAYPluGigRhXwLEIZHSblmg4GSmmghdJe2ECiyHM=.2dbe6910-509d-4d0b-a6dc-ba15a06cdd6b@github.com> Message-ID: On Thu, 13 Feb 2025 21:53:25 GMT, Michael Strau? wrote: >> Yeah, that's what I came to realize as well. So our property should remain boolean. >> >> The only other thing I could think of is for us to provide a new utility method (in some class in javafx.base) that an application must call to register the version of JavaFX API that are compiling against. For example, imagine a `java.javafx.util.PreviewFeatures` class with the following method: >> >> >> public void setVersion(int featureVersion) {} >> >> >> An application would need to call `PreviewFeatures.setVersion(25)` to use JavaFX preview features from JavaFX 25. That method would unlock preview features only if the version passed in matches the runtime feature version. This would be in addition to the boolean system property. >> >> The question is whether it is worth the additional complexity (not for us to implement, that's trivial unless I'm missing something), but rather than documentation and burden on the app developer using a preview feature. The docs for each new preview feature would need to link to the PreviewFeatures utility class to describe how to unlock the features. On the plus side, it would provide a common place to document how to unlock preview features -- "call this method from the application and set that system property on the command line when running the app". > > I wouldn't be in favor of requiring application developers to call a method to unlock a preview API. It seems a bit too cumbersome and intrusive to me, since it requires you to embed build information into your source code. I've also never seen this in other libraries or frameworks. > I wouldn't be in favor ... since it requires you to embed build information into your source code That seems reason enough to abandon this idea. > I've also never seen this in other libraries or frameworks. True. Significantly, I didn't propose anything like this for the incubator modules, which can have the same problem. So I think this is a good minimal solution that provide a clue to the developer that they are relying on API that is unstable and will change in the future (meaning that using such API is a risk they need to be willing to take). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1955355086 From kcr at openjdk.org Thu Feb 13 23:50:18 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Feb 2025 23:50:18 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 03:51:28 GMT, Alexander Matveev wrote: >> - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. >> - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. >> - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. >> - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] This looks good to me now with the updated lock/unlock now handling multiple matched lock/unlock. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1695#pullrequestreview-2616452448 From jbhaskar at openjdk.org Fri Feb 14 03:47:29 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 14 Feb 2025 03:47:29 GMT Subject: RFR: 8349891: Not implemented function should have printf Message-ID: Some newly added, unimplemented functions in FileSystemJava.cpp during the WebKit upgrade to version 620.1 should include print statements to indicate at runtime when these functions are invoked. ------------- Commit messages: - 8349891: Not implemented function should have printf Changes: https://git.openjdk.org/jfx/pull/1711/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1711&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349891 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1711.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1711/head:pull/1711 PR: https://git.openjdk.org/jfx/pull/1711 From jbhaskar at openjdk.org Fri Feb 14 10:32:42 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 14 Feb 2025 10:32:42 GMT Subject: [jfx24u] RFR: 8340322: Update WebKit to 620.1 Message-ID: A clean backport to jfx24u. The update is related to webkit upgrae up to 2.46.5. ------------- Commit messages: - Backport 1e6915738d654e6cf7a547e47b8b020117db6bc3 Changes: https://git.openjdk.org/jfx24u/pull/4/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8340322 Stats: 773682 lines in 8157 files changed: 644444 ins; 72180 del; 57058 mod Patch: https://git.openjdk.org/jfx24u/pull/4.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/4/head:pull/4 PR: https://git.openjdk.org/jfx24u/pull/4 From lkostyra at openjdk.org Fri Feb 14 11:30:16 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 14 Feb 2025 11:30:16 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v3] In-Reply-To: References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: <0-t7CjjpM5t1ITxrlZVMvtLOT82A5IBqbQ1RMANSjrw=.40c56b80-6be5-4f5e-853d-1652905869e8@github.com> On Tue, 11 Feb 2025 11:51:26 GMT, Thiago Milczarek Sayao wrote: >> The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. >> >> It's not specific to i3. >> >> I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Clarify the meaning of x and y. Can you merge the latest master? Web tests are failing on my end but I suspect it's because of WebKit upgrade that just happened (latest master works fine and this branch does not have it) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1702#issuecomment-2659062586 From azvegint at openjdk.org Fri Feb 14 13:01:25 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 14 Feb 2025 13:01:25 GMT Subject: Integrated: 8349256: Update PipeWire to 1.3.81 In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 11:54:01 GMT, Alexander Zvegintsev wrote: > This changeset updates the pipewire headers to the 1.3.81, and it is the same as for the [OpenJDK](https://github.com/openjdk/jdk/pull/23426) > > It contains the minimum set of required header files needed to build the JFX. > > The updated headers are a direct copy from the > https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the \t -> replacement) This pull request has now been integrated. Changeset: 53fe8f1a Author: Alexander Zvegintsev URL: https://git.openjdk.org/jfx/commit/53fe8f1a03f7e5c386a3341315834751c17b8514 Stats: 2369 lines in 72 files changed: 1728 ins; 59 del; 582 mod 8349256: Update PipeWire to 1.3.81 Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1710 From azvegint at openjdk.org Fri Feb 14 13:09:31 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 14 Feb 2025 13:09:31 GMT Subject: [jfx24u] RFR: 8349256: Update PipeWire to 1.3.81 Message-ID: Hi all, This pull request contains a backport of commit [53fe8f1a](https://github.com/openjdk/jfx/commit/53fe8f1a03f7e5c386a3341315834751c17b8514) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Alexander Zvegintsev on 14 Feb 2025 and was reviewed by Lukasz Kostyra and Kevin Rushforth. Thanks! ------------- Commit messages: - Backport 53fe8f1a03f7e5c386a3341315834751c17b8514 Changes: https://git.openjdk.org/jfx24u/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349256 Stats: 2369 lines in 72 files changed: 1728 ins; 59 del; 582 mod Patch: https://git.openjdk.org/jfx24u/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx24u/pull/5 From tsayao at openjdk.org Fri Feb 14 13:31:04 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 14 Feb 2025 13:31:04 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v4] In-Reply-To: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: > The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. > > It's not specific to i3. > > I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into 8348095 - Clarify the meaning of x and y. - Clarify the meaning of view_x and view_y. - Forgot debug print - 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1702/files - new: https://git.openjdk.org/jfx/pull/1702/files/bd12ebca..c2b56ab6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1702&range=02-03 Stats: 776269 lines in 8272 files changed: 646268 ins; 72273 del; 57728 mod Patch: https://git.openjdk.org/jfx/pull/1702.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1702/head:pull/1702 PR: https://git.openjdk.org/jfx/pull/1702 From lkostyra at openjdk.org Fri Feb 14 14:05:20 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 14 Feb 2025 14:05:20 GMT Subject: RFR: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode [v4] In-Reply-To: References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: On Fri, 14 Feb 2025 13:31:04 GMT, Thiago Milczarek Sayao wrote: >> The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. >> >> It's not specific to i3. >> >> I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into 8348095 > - Clarify the meaning of x and y. > - Clarify the meaning of view_x and view_y. > - Forgot debug print > - 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode Everything works fine now. LGTM ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1702#pullrequestreview-2617883340 From tsayao at openjdk.org Fri Feb 14 14:11:22 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 14 Feb 2025 14:11:22 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 19:10:15 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 two additional commits since the last revision: > > - typo > - update copyright headers Does the name `EXTENDED` accurately reflect its functionality? I have a feeling there's a better name for it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2659430587 From mstrauss at openjdk.org Fri Feb 14 14:54:28 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 14 Feb 2025 14:54:28 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 14:08:34 GMT, Thiago Milczarek Sayao wrote: > Does the name `EXTENDED` accurately reflect its functionality? I have a feeling there's a better name for it. Here are some alternatives: * `FULL_SIZE`, like in AppKit's `NSWindowStyleMaskFullSizeContentView` * `COMBINED`, meaning that non-client and client areas are combined * `UNIFIED` already exists, but is non-functional; we could repurpose it ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2659531910 From jbhaskar at openjdk.org Fri Feb 14 15:29:32 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 14 Feb 2025 15:29:32 GMT Subject: [jfx24u] Integrated: 8340322: Update WebKit to 620.1 In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 10:19:13 GMT, Jay Bhaskar wrote: > A clean backport to jfx24u. The update is related to webkit upgrae up to 2.46.5. This pull request has now been integrated. Changeset: 33907ec4 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx24u/commit/33907ec4daa6c9d79caab99787ee29428788e66e Stats: 773682 lines in 8157 files changed: 644444 ins; 72180 del; 57058 mod 8340322: Update WebKit to 620.1 Backport-of: 1e6915738d654e6cf7a547e47b8b020117db6bc3 ------------- PR: https://git.openjdk.org/jfx24u/pull/4 From angorya at openjdk.org Fri Feb 14 15:38:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 15:38:19 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v3] In-Reply-To: References: Message-ID: <80Pvzu6BGZ5_Y33WO-H8hQNN3r6URopfPWMhAk637O4=.4c13bd65-f5dc-43d3-9c5a-63397c53def7@github.com> On Thu, 6 Feb 2025 13:18:35 GMT, Marius Hanl wrote: >> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. >> >> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. >> >> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). >> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge and adjust logic to master > - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup > - Call getFixedCellSize() once > - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup Now that https://github.com/openjdk/jfx/pull/1644 has been merged, should this PR be re-opened? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1645#issuecomment-2659645800 From angorya at openjdk.org Fri Feb 14 15:44:23 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 15:44:23 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v47] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 18:51:22 GMT, Michael Strau? wrote: > layout containers never visually clip their contents see `PaginationSkin.install()` Although in Pane:94: * Pane does not clip its content by default, so it is possible that children's * bounds may extend outside its own bounds, either if children are positioned * at negative coordinates or the pane is resized smaller than its preferred size.

    BorderPane:120, FlowPane:146, ... Can the application set the clip rectangle easily if needed? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2659659703 From kcr at openjdk.org Fri Feb 14 16:05:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 16:05:16 GMT Subject: RFR: 8349891: Not implemented function should have printf In-Reply-To: References: Message-ID: <4vb0nWuolCoCRuiBN2dWWS3H61ru9WdXGp_y_P-j8Lw=.4b7a3494-cddf-4d11-a60b-6ae93feaa7c5@github.com> On Fri, 14 Feb 2025 03:43:25 GMT, Jay Bhaskar wrote: > Some newly added, unimplemented functions in FileSystemJava.cpp during the WebKit upgrade to version 620.1 should include print statements to indicate at runtime when these functions are invoked. LGTM. Please wait 24 hours in case there are other comments. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1711#pullrequestreview-2618212105 From kcr at openjdk.org Fri Feb 14 16:15:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 16:15:15 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 12:45:20 GMT, Ambarish Rapte wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8349098.thread.safe.tabpane >> - skip animation > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 523: > >> 521: }; >> 522: >> 523: if (Platform.isFxApplicationThread() && (closeTabAnimation.get() == TabAnimation.GROW)) { > > With this check, non Application thread cannot play the animation but in else block the `cleanup` is executed on the same thread. > Can there still be a situation when, this non-Application thread and Application thread be concurrently modifying the tab? If you mean two threads accessing this same TabPaneSkin instance, then that's not a valid case. JavaFX objects are not thread-safe when accessed from multiple threads. This bug (and the other related bugs fixed or under review) is about making sure that multiple threads, including the JavaFX application thread, each concurrently accessing their own instance, don't interfere with each other. So it would only be a problem if "cleanup" attempted some animation or touched static state or similar, which is doesn't look like it does. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1699#discussion_r1956397152 From kcr at openjdk.org Fri Feb 14 16:23:24 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 16:23:24 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:12:27 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 523: >> >>> 521: }; >>> 522: >>> 523: if (Platform.isFxApplicationThread() && (closeTabAnimation.get() == TabAnimation.GROW)) { >> >> With this check, non Application thread cannot play the animation but in else block the `cleanup` is executed on the same thread. >> Can there still be a situation when, this non-Application thread and Application thread be concurrently modifying the tab? > > If you mean two threads accessing this same TabPaneSkin instance, then that's not a valid case. JavaFX objects are not thread-safe when accessed from multiple threads. This bug (and the other related bugs fixed or under review) is about making sure that multiple threads, including the JavaFX application thread, each concurrently accessing their own instance, don't interfere with each other. > > So it would only be a problem if "cleanup" attempted some animation or touched static state or similar, which is doesn't look like it does. Although, having said that, the purpose of the cleanup is to clean up after the animation. So a better fix might be to put the entire if-else inside an `if (Platform.isFxApplicationThread())` test. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1699#discussion_r1956407884 From kcr at openjdk.org Fri Feb 14 16:26:20 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 16:26:20 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:20:33 GMT, Kevin Rushforth wrote: >> If you mean two threads accessing this same TabPaneSkin instance, then that's not a valid case. JavaFX objects are not thread-safe when accessed from multiple threads. This bug (and the other related bugs fixed or under review) is about making sure that multiple threads, including the JavaFX application thread, each concurrently accessing their own instance, don't interfere with each other. >> >> So it would only be a problem if "cleanup" attempted some animation or touched static state or similar, which is doesn't look like it does. > > Although, having said that, the purpose of the cleanup is to clean up after the animation. So a better fix might be to put the entire if-else inside an `if (Platform.isFxApplicationThread())` test. Actually, no. It also calls requestLayout. I think the fix is correct as is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1699#discussion_r1956412231 From kcr at openjdk.org Fri Feb 14 16:30:13 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 16:30:13 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 18:42:01 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Skip the animation. >> >> The fix is similar to https://github.com/openjdk/jfx/pull/1698 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8349098.thread.safe.tabpane > - skip animation The fix looks good. I confirm that the newly-enabled test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1699#pullrequestreview-2618275147 From tsayao at openjdk.org Fri Feb 14 16:37:25 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 14 Feb 2025 16:37:25 GMT Subject: Integrated: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode In-Reply-To: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> References: <8gcoNAZDclgkubQ8mF7Za-h92uqEfg7a6lFursPmn28=.02f801f4-cfd8-4bb1-a4b3-34c4b104f5a1@github.com> Message-ID: <_VNErfOmCJFG2Ri4cz0d2FFFT4hBTNroWbmg2CyMa6Q=.c4544727-9167-4996-a3fb-55e67e3e1db9@github.com> On Sun, 9 Feb 2025 19:10:49 GMT, Thiago Milczarek Sayao wrote: > The issue was with the view's position, specifically the content's X and Y coordinates relative to the window, including its decorations. When in fullscreen mode, the window remains decorated, but the decorations are hidden. As a result, the content's position needs to be recalculated to account for the window's adjusted layout. > > It's not specific to i3. > > I used `gdk_window_get_root_origin` because GTK provides a more robust mechanism to determine the value, even in cases where _NET_FRAME_EXTENTS is not supported by the window manager. This pull request has now been integrated. Changeset: b267340b Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/b267340b9f472aea291a30d00de73096e4949f04 Stats: 22 lines in 3 files changed: 6 ins; 0 del; 16 mod 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode Reviewed-by: jpereda, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1702 From angorya at openjdk.org Fri Feb 14 17:43:28 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 17:43:28 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 19:10:15 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 two additional commits since the last revision: > > - typo > - update copyright headers modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 715: > 713: > 714: protected abstract boolean _supportsExtendedWindows(); > 715: public final boolean supportsExtendedWindows() { missing newline after L714? modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonMetrics.java line 39: > 37: * @param minHeight the minimum height of the window buttons > 38: */ > 39: public record HeaderButtonMetrics(Dimension2D leftInset, Dimension2D rightInset, double minHeight) { would it make more sense to use Insets instead of Dimension2D? What if the app calls for asymmetrical padding? modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 153: > 151: > 152: private static final CssMetaData BUTTON_DEFAULT_HEIGHT_METADATA = > 153: new CssMetaData<>("-fx-button-default-height", StyleConverter.getSizeConverter()) { The new styleables need to be documented in cssref.html as a part of this PR, right? (The javadoc for this class will not be visible in the API specification). modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 209: > 207: > 208: private static final List> METADATA = > 209: Stream.concat(getClassCssMetaData().stream(), `RichUtils.combine()` L419 avoids creating intermediary objects. modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 283: > 281: */ > 282: private final StyleableBooleanProperty allowRtl = > 283: new SimpleStyleableBooleanProperty(ALLOW_RTL_METADATA, this, "allowRtl", true) { what is the rationale for this property? Instead, I think, it should look at the `Node::getEffectiveNodeOrientation()` which either inherits the value from the parent or allows the app to override for a specific component (in other words, we already have this functionality for free). Or am I missing something? modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 328: > 326: > 327: var updateStylesheetSubscription = sceneProperty() > 328: .flatMap(Scene::fillProperty) will this work if the value of scene is `null`? modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 405: > 403: } : null; > 404: > 405: if (type == MouseEvent.ENTER || type == MouseEvent.MOVE || type == MouseEvent.DRAG) { minor: would it be clearer to use a `switch(type)` here instead? modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 406: > 404: > 405: if (type == MouseEvent.ENTER || type == MouseEvent.MOVE || type == MouseEvent.DRAG) { > 406: handleMouseOver(node); could there be a situation when node is null but we pass it on to the method? also L410, L412 modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 586: > 584: totalHeight = snapSizeY(getEffectiveButtonHeight()); > 585: } else { > 586: totalHeight = snapSizeY(Math.max(button1Height, Math.max(button2Height, button3Height))); +1 for correct snapping! modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 632: > 630: } > 631: > 632: private static double boundedSize(double min, double pref, double max) { minor: it would be nice to move this to some common utilities class (there is already such a method in c.s.j.scene.control.skin.Utils class). along with two previous methods. modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 678: > 676: orderedButtons.add(this); > 677: buttonOrder.set(order); > 678: glyph.getStyleClass().setAll("glyph"); "glyph": though apt, the name might be somewhat confusing. maybe "icon"? modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 299: > 297: } > 298: > 299: /** since the majority of windows is expected to be DECORATED, would it make more sense to move these properties into a separate container akin to `Node.getMiscProperties()` ? modules/javafx.graphics/src/main/java/javafx/application/ConditionalFeature.java line 163: > 161: */ > 162: EXTENDED_WINDOW, > 163: Is this PR blocked by the Preview Feature Support #1359? modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 323: > 321: minHeightProperty(); > 322: > 323: ObservableValue stage = sceneProperty() will this handle `null` scene? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956349123 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956353096 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956357334 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956364194 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956372516 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956374877 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956464424 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956462896 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956484613 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956488129 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956491008 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956495596 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956505679 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956507647 From angorya at openjdk.org Fri Feb 14 17:43:30 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 17:43:30 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v21] In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: <9Z6zLyGyKWrr6QQ8q02E8H1EmATT7E2sDTnFgeTT6DU=.4aaee131-e9a9-4965-8516-c3b9a6ea8dc4@github.com> On Tue, 5 Nov 2024 19:10:01 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> stylistic changes > > modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 125: > >> 123: >> 124: .close-button > .glyph { >> 125: -fx-shape: "m 8.1464844,8.1464844 a 0.5,0.5 0 0 0 0,0.7070312 L 11.292969,12 8.1464844,15.146484 a 0.5,0.5 0 0 0 0,0.707032 0.5,0.5 0 0 0 0.7070312,0 L 12,12.707031 l 3.146484,3.146485 a 0.5,0.5 0 0 0 0.707032,0 0.5,0.5 0 0 0 0,-0.707032 L 12.707031,12 15.853516,8.8535156 a 0.5,0.5 0 0 0 0,-0.7070312 0.5,0.5 0 0 0 -0.707032,0 L 12,11.292969 8.8535156,8.1464844 a 0.5,0.5 0 0 0 -0.7070312,0 z"; > > minor: we could probably minimize the path by rounding to 2 or 3 decimal points > (same comment for all .css changes) any response on this? > modules/javafx.graphics/src/main/resources/com/sun/glass/ui/win/WindowDecoration.css line 107: > >> 105: >> 106: .maximize-button.restore > .glyph { >> 107: -fx-shape: "m 7.6491699,2.5192871 q 0,-0.3444824 -0.1369629,-0.6495361 Q 7.3752441,1.5646973 7.1407471,1.338501 6.90625,1.1123047 6.5970459,0.98156738 6.2878418,0.85083008 5.9475098,0.85083008 H 1.7722168 Q 1.838623,0.65991211 1.9589844,0.50219727 2.0793457,0.34448242 2.2370605,0.23242188 2.3947754,0.12036133 2.5836182,0.06018066 2.7724609,0 2.9758301,0 H 5.9475098 Q 6.4746094,0 6.9394531,0.20129395 7.4042969,0.40258789 7.7508545,0.74707031 8.0974121,1.0915527 8.2987061,1.5563965 8.5,2.0212402 8.5,2.5483398 V 5.5241699 Q 8.5,5.7275391 8.4398193,5.9163818 8.3796387,6.1052246 8.2675781,6.2629395 8.1555176,6.4206543 7.9978027,6.5410156 7.8400879,6.661377 7.6491699,6.7277832 Z M 1.253418,8.5 Q 1.0043945,8.5 0.77612305,8.3983154 0.54785156,8.2966309 0.37561035,8.1243896 0.20336914,7.9521484 0.10168457,7.723877 0,7.4956055 0,7.246582 V 2.9550781 Q 0,2.7019043 0.10168457,2.475708 0.20336914,2.2495117 0.37561035,2.0772705 0.54785156,1.9050293 0.77404785,1.8033447 1.0002441,1.7016 602 1.253418,1.7016602 h 4.2915039 q 0.2531738,0 0.4814453,0.1016845 0.2282715,0.1016846 0.3984375,0.2718506 0.170166,0.170166 0.2718506,0.3984375 0.1016845,0.2282715 0.1016845,0.4814453 V 7.246582 q 0,0.2531739 -0.1016845,0.4793701 Q 6.5949707,7.9521484 6.4227295,8.1243896 6.2504883,8.2966309 6.024292,8.3983154 5.7980957,8.5 5.5449219,8.5 Z M 5.5241699,7.6491699 q 0.087158,0 0.1639405,-0.033203 0.076782,-0.033203 0.1369628,-0.091309 0.060181,-0.058105 0.093384,-0.1348877 0.033203,-0.076782 0.033203,-0.1639404 v -4.25 q 0,-0.087158 -0.033203,-0.1660156 Q 5.8852539,2.730957 5.8271484,2.6728516 5.769043,2.6147461 5.6901855,2.581543 5.6113281,2.5483398 5.5241699,2.5483398 h -4.25 q -0.087158,0 -0.1639404,0.033203 -0.076782,0.033203 -0.1348877,0.093384 -0.0581055,0.060181 -0.0913086,0.1369628 -0.0332031,0.076782 -0.0332031,0.1639405 v 4.25 q 0,0.087158 0.0332031,0.1639404 0.0332031,0.076782 0.0913086,0.1348877 0.0581055,0.058105 0.1348877,0.091309 0.076782,0.033203 0.1639404,0.033203 z" ; > > ... especially here ... response? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956510916 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956511237 From angorya at openjdk.org Fri Feb 14 17:49:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 17:49:16 GMT Subject: RFR: 8349098: TabPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:23:58 GMT, Kevin Rushforth wrote: >> Although, having said that, the purpose of the cleanup is to clean up after the animation. So a better fix might be to put the entire if-else inside an `if (Platform.isFxApplicationThread())` test. > > Actually, no. It also calls requestLayout. I think the fix is correct as is. Right. The change prevents from _starting_ the animation if these code paths are entered in a background thread. With the change, the code follows an animation-off path. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1699#discussion_r1956518465 From angorya at openjdk.org Fri Feb 14 17:49:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 17:49:17 GMT Subject: Integrated: 8349098: TabPane: exception initializing in a background thread In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 23:20:30 GMT, Andy Goryachev wrote: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Skip the animation. > > The fix is similar to https://github.com/openjdk/jfx/pull/1698 This pull request has now been integrated. Changeset: d1f5ea81 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/d1f5ea81f8cc1e11889da73d343e72270a5559a4 Stats: 18 lines in 2 files changed: 2 ins; 5 del; 11 mod 8349098: TabPane: exception initializing in a background thread Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1699 From angorya at openjdk.org Fri Feb 14 17:55:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 17:55:17 GMT Subject: RFR: 8349373: Support JavaFX preview features [v3] In-Reply-To: References: Message-ID: <08hrjikF2cGxP_kqp2FhIM7CIGxddgBYj2XC8Utrct4=.e4fb11a9-426a-445f-8f31-cbad99b0140f@github.com> On Fri, 7 Feb 2025 09:16:54 GMT, Michael Strau? wrote: >> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features. > > Michael Strau? has updated the pull request incrementally with four additional commits since the last revision: > > - javadoc > - remove supporting documentation > - warning can't be suppressed > - initialize PreviewFeature early > That method would unlock preview features only if the version passed in matches the runtime feature version. what would happen if we don't add this logic? the app will exit with `ClassNotFoundException` or some runtime error? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1359#issuecomment-2659938528 From angorya at openjdk.org Fri Feb 14 17:57:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 17:57:16 GMT Subject: RFR: 8349758: Memory leak in TreeTableView In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 21:16:32 GMT, Andy Goryachev wrote: > ## Root Cause > > An event handler was installed on the root property without removing it when the root changes. > > ## Solution > > Replaced the weak parts with a change listener to the root property to ensure correct handling of the root value changes. @arapte or @aghaisas could one of you be the second reviewer please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1706#issuecomment-2659941281 From angorya at openjdk.org Fri Feb 14 18:20:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 18:20:53 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: > ## Root Cause > > Animation was started in the background thread, causing concurrent access. > > ## Solution > > Disable animation if not the fx app thread. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - revert - Merge remote-tracking branch 'origin/master' into 8349255.thread.safe.titled.pane - the fix - Merge branch 'master' into 8349255.thread.safe.titled.pane - Merge branch 'master' into 8349255.thread.safe.titled.pane - get parent - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - review comments - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils - ... and 17 more: https://git.openjdk.org/jfx/compare/d1f5ea81...2c9740e9 ------------- Changes: https://git.openjdk.org/jfx/pull/1707/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1707&range=01 Stats: 24 lines in 2 files changed: 10 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1707.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1707/head:pull/1707 PR: https://git.openjdk.org/jfx/pull/1707 From angorya at openjdk.org Fri Feb 14 18:20:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 18:20:53 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread [v2] In-Reply-To: <3r8oriMxXKMRbPx1hXm8px5-KZLIWNvBaK_b3abeBeg=.108ceb6c-3f91-4b2a-a303-5029af2ffa64@github.com> References: <39f5wlb5NdV3XQ4D8QCJhHocpvN_wFIlsSTjjqc8Sz0=.a9dfcaac-3111-4765-bd0b-fae7d7dccb06@github.com> <3r8oriMxXKMRbPx1hXm8px5-KZLIWNvBaK_b3abeBeg=.108ceb6c-3f91-4b2a-a303-5029af2ffa64@github.com> Message-ID: <-_IBMzJCtAUJjfTRhigpqEninxvq78xSZpvGXMJOGj0=.b782d745-9ab4-4579-b7be-a759d935de52@github.com> On Thu, 13 Feb 2025 18:32:58 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1442: >> >>> 1440: // of this node, since visibility affects bounds of the >>> 1441: // parent node >>> 1442: p.childVisibilityChanged(Node.this); >> >> it was a part of an earlier attempt, but I think this code is better. > > I'd still revert it, since it is unrelated to the fix under review and is in a file that is otherwise untouched. reverted ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1707#discussion_r1956555210 From kcr at openjdk.org Fri Feb 14 18:21:19 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 18:21:19 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v5] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Tue, 11 Feb 2025 23:33:42 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > 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 eight additional commits since the last revision: > > - Merge branch '8349756.pagination.leak' into 8349105.thread.safety.pagination > - back to constructor > - memory leak > - remove gc > - slow down gc > - gc > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation > For testing purposes, merged this PR with the memory leak fix #1705 . Once the latter is integrated, unrelated changes will disappear. Can you merge master so this will be realized? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2659987368 From angorya at openjdk.org Fri Feb 14 18:26:31 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 18:26:31 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v6] In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge remote-tracking branch 'origin/master' into 8349105.thread.safety.pagination - Merge branch '8349756.pagination.leak' into 8349105.thread.safety.pagination - back to constructor - memory leak - remove gc - slow down gc - gc - Merge branch 'master' into 8349105.thread.safety.pagination - postpone animation ------------- Changes: https://git.openjdk.org/jfx/pull/1698/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1698&range=05 Stats: 14 lines in 2 files changed: 6 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1698.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1698/head:pull/1698 PR: https://git.openjdk.org/jfx/pull/1698 From angorya at openjdk.org Fri Feb 14 18:26:31 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 18:26:31 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v5] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 14 Feb 2025 18:18:59 GMT, Kevin Rushforth wrote: > Can you merge master so this will be realized? done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2659998222 From kcr at openjdk.org Fri Feb 14 18:37:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 18:37:21 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v6] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 14 Feb 2025 18:26:31 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge remote-tracking branch 'origin/master' into 8349105.thread.safety.pagination > - Merge branch '8349756.pagination.leak' into 8349105.thread.safety.pagination > - back to constructor > - memory leak > - remove gc > - slow down gc > - gc > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation All good now. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1698#pullrequestreview-2618549321 From kcr at openjdk.org Fri Feb 14 18:40:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Feb 2025 18:40:23 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:20:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> >> Animation was started in the background thread, causing concurrent access. >> >> ## Solution >> >> Disable animation if not the fx app thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - revert > - Merge remote-tracking branch 'origin/master' into 8349255.thread.safe.titled.pane > - the fix > - Merge branch 'master' into 8349255.thread.safe.titled.pane > - Merge branch 'master' into 8349255.thread.safe.titled.pane > - get parent > - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils > - review comments > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils > - ... and 17 more: https://git.openjdk.org/jfx/compare/d1f5ea81...2c9740e9 Looks good. The fix is similar to #1698 and #1699. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1707#pullrequestreview-2618553722 From angorya at openjdk.org Fri Feb 14 19:28:16 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 19:28:16 GMT Subject: Withdrawn: 8349096: Split/MenuButton: exception initializing in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 20:15:03 GMT, Andy Goryachev wrote: > ## Root Cause > > The ContextMenu (PopupWindow) cannot be shown in a background thread. > > ## Solution > > Bail out of `show()` if in a background thread. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1709 From angorya at openjdk.org Fri Feb 14 19:36:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 19:36:17 GMT Subject: Withdrawn: 8349004: DatePicker: NPE in show() when initialized in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:45:32 GMT, Andy Goryachev wrote: > ## Root Cause > > Focus is being requested in show(), even a background thread. > > ## Solution > > Do not request focus if in a background thread. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1708 From mstrauss at openjdk.org Fri Feb 14 21:50:18 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 14 Feb 2025 21:50:18 GMT Subject: RFR: 8349255: TitledPane: exception initializing in a background thread [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:20:53 GMT, Andy Goryachev wrote: >> ## Root Cause >> >> Animation was started in the background thread, causing concurrent access. >> >> ## Solution >> >> Disable animation if not the fx app thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - revert > - Merge remote-tracking branch 'origin/master' into 8349255.thread.safe.titled.pane > - the fix > - Merge branch 'master' into 8349255.thread.safe.titled.pane > - Merge branch 'master' into 8349255.thread.safe.titled.pane > - get parent > - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils > - review comments > - Merge remote-tracking branch 'origin/master' into 8348423.node.thread.safety > - Merge branch '8348423.node.thread.safety' into 8347392.thread.safe.utils > - ... and 17 more: https://git.openjdk.org/jfx/compare/d1f5ea81...2c9740e9 Looks good. ------------- Marked as reviewed by mstrauss (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1707#pullrequestreview-2618863816 From mstrauss at openjdk.org Fri Feb 14 21:50:19 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 14 Feb 2025 21:50:19 GMT Subject: RFR: 8349105: Pagination: exception initializing in a background thread [v6] In-Reply-To: References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Fri, 14 Feb 2025 18:26:31 GMT, Andy Goryachev wrote: >> ## Root Cause >> Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). >> >> ## Solution >> Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge remote-tracking branch 'origin/master' into 8349105.thread.safety.pagination > - Merge branch '8349756.pagination.leak' into 8349105.thread.safety.pagination > - back to constructor > - memory leak > - remove gc > - slow down gc > - gc > - Merge branch 'master' into 8349105.thread.safety.pagination > - postpone animation Looks good. ------------- Marked as reviewed by mstrauss (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1698#pullrequestreview-2618866520 From angorya at openjdk.org Fri Feb 14 21:50:19 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 21:50:19 GMT Subject: Integrated: 8349255: TitledPane: exception initializing in a background thread In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:07:19 GMT, Andy Goryachev wrote: > ## Root Cause > > Animation was started in the background thread, causing concurrent access. > > ## Solution > > Disable animation if not the fx app thread. This pull request has now been integrated. Changeset: 01059d4f Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/01059d4f6f9112c25252e3ac8311b50c19800f6d Stats: 24 lines in 2 files changed: 10 ins; 10 del; 4 mod 8349255: TitledPane: exception initializing in a background thread Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1707 From angorya at openjdk.org Fri Feb 14 21:57:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 14 Feb 2025 21:57:20 GMT Subject: Integrated: 8349105: Pagination: exception initializing in a background thread In-Reply-To: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> References: <8-51RC7O8zlCMS8GUbT3aU09N2KdOaxn2VgRxfEjzPE=.09bf9adb-3941-46de-a509-ee058823fe6d@github.com> Message-ID: On Thu, 6 Feb 2025 20:43:54 GMT, Andy Goryachev wrote: > ## Root Cause > Animation gets started in a background thread, which causes the animation handler to run in the FX application thread, thus creating simultaneous access to the control's fields (list of children in this case). > > ## Solution > Postpone the animation unless running in the FX application thread. There is no functional difference if the component is created/used in the FX application thread. This pull request has now been integrated. Changeset: d07d5cc6 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/d07d5cc684e68615fd0cec154a4e4c18810af1eb Stats: 14 lines in 2 files changed: 6 ins; 6 del; 2 mod 8349105: Pagination: exception initializing in a background thread Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1698 From mstrauss at openjdk.org Sat Feb 15 01:19:04 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 15 Feb 2025 01:19:04 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v50] 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: minify button glyphs ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/1f95e9db..cd9c2a94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=49 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=48-49 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 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 Sat Feb 15 01:19:10 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 15 Feb 2025 01:19:10 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 15:43:38 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - typo >> - update copyright headers > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 715: > >> 713: >> 714: protected abstract boolean _supportsExtendedWindows(); >> 715: public final boolean supportsExtendedWindows() { > > missing newline after L714? Yeah, doesn't look nice, but I wanted to match the style of the surrounding methods. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonMetrics.java line 39: > >> 37: * @param minHeight the minimum height of the window buttons >> 38: */ >> 39: public record HeaderButtonMetrics(Dimension2D leftInset, Dimension2D rightInset, double minHeight) { > > would it make more sense to use Insets instead of Dimension2D? What if the app calls for asymmetrical padding? This class is not API, so it doesn't matter here. However, it matters in `HeaderBar.leftSystemInset/rightSystemInset`, which are both of type `Dimension2D`. The system insets are not arbitrary rectangles, they are always aligned with the top-left and top-right edges of the window. As such, the only necessary information is their spatial extent, which is best represented as a `Dimension2D`. I'm not sure what you mean by asymmetrical padding. Can you elaborate? > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 153: > >> 151: >> 152: private static final CssMetaData BUTTON_DEFAULT_HEIGHT_METADATA = >> 153: new CssMetaData<>("-fx-button-default-height", StyleConverter.getSizeConverter()) { > > The new styleables need to be documented in cssref.html as a part of this PR, right? > (The javadoc for this class will not be visible in the API specification). `HeaderButtonOverlay` is not API, it's an internal implementation detail. The javadoc is just informational for future JavaFX developers. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 209: > >> 207: >> 208: private static final List> METADATA = >> 209: Stream.concat(getClassCssMetaData().stream(), > > `RichUtils.combine()` L419 avoids creating intermediary objects. Needs to wait until we have something like this in an accessible place... > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 283: > >> 281: */ >> 282: private final StyleableBooleanProperty allowRtl = >> 283: new SimpleStyleableBooleanProperty(ALLOW_RTL_METADATA, this, "allowRtl", true) { > > what is the rationale for this property? > Instead, I think, it should look at the `Node::getEffectiveNodeOrientation()` which either inherits the value from the parent or allows the app to override for a specific component (in other words, we already have this functionality for free). > > Or am I missing something? `HeaderButtonOverlay` inherits its node orientation from the scene, which is under the control of the application developer. On the other hand, `allowRtl` is under the control of JavaFX developers (that's us), specifying whether the selected header button implementation supports RTL layouts at all. Currently, all header button implementations do. The property is there to make all aspects of `HeaderButtonOverlay` styleable, so that future JavaFX developers can add other header button styles that may have fixed locations (i.e. don't move from one side to the other in RTL mode). > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 328: > >> 326: >> 327: var updateStylesheetSubscription = sceneProperty() >> 328: .flatMap(Scene::fillProperty) > > will this work if the value of scene is `null`? Yes! > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 405: > >> 403: } : null; >> 404: >> 405: if (type == MouseEvent.ENTER || type == MouseEvent.MOVE || type == MouseEvent.DRAG) { > > minor: would it be clearer to use a `switch(type)` here instead? I've tried, but the additional conditions make it end up more verbose and funny-looking. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 406: > >> 404: >> 405: if (type == MouseEvent.ENTER || type == MouseEvent.MOVE || type == MouseEvent.DRAG) { >> 406: handleMouseOver(node); > > could there be a situation when node is null but we pass it on to the method? also L410, L412 Yes, that's a very common situation. It happens when the cursor is on the header bar, but not on a header button. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 632: > >> 630: } >> 631: >> 632: private static double boundedSize(double min, double pref, double max) { > > minor: > it would be nice to move this to some common utilities class (there is already such a method in c.s.j.scene.control.skin.Utils class). > > along with two previous methods. We can also consider exposing this as API (not with this PR, though). If it's useful for us, it might also be useful for application developers. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 299: > >> 297: } >> 298: >> 299: /** > > since the majority of windows is expected to be DECORATED, would it make more sense to move these properties into a separate container akin to `Node.getMiscProperties()` ? Sure, but the downside is that everything gets more bloated for little benefit. Right now, these properties are accessed in derived classes without any checks, since they are final and non-null. In this case, I think ease of use is more important. > modules/javafx.graphics/src/main/java/javafx/application/ConditionalFeature.java line 163: > >> 161: */ >> 162: EXTENDED_WINDOW, >> 163: > > Is this PR blocked by the Preview Feature Support #1359? Yes, it is. Once we get preview features in, I'll annotate the new API elements. > modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 323: > >> 321: minHeightProperty(); >> 322: >> 323: ObservableValue stage = sceneProperty() > > will this handle `null` scene? Yes, it will. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968295 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968317 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968351 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968405 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968436 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968452 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968485 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968472 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968540 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968558 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968567 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956968572 From mstrauss at openjdk.org Sat Feb 15 01:24:20 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 15 Feb 2025 01:24:20 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v21] In-Reply-To: <9Z6zLyGyKWrr6QQ8q02E8H1EmATT7E2sDTnFgeTT6DU=.4aaee131-e9a9-4965-8516-c3b9a6ea8dc4@github.com> References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> <9Z6zLyGyKWrr6QQ8q02E8H1EmATT7E2sDTnFgeTT6DU=.4aaee131-e9a9-4965-8516-c3b9a6ea8dc4@github.com> Message-ID: On Fri, 14 Feb 2025 17:38:48 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 125: >> >>> 123: >>> 124: .close-button > .glyph { >>> 125: -fx-shape: "m 8.1464844,8.1464844 a 0.5,0.5 0 0 0 0,0.7070312 L 11.292969,12 8.1464844,15.146484 a 0.5,0.5 0 0 0 0,0.707032 0.5,0.5 0 0 0 0.7070312,0 L 12,12.707031 l 3.146484,3.146485 a 0.5,0.5 0 0 0 0.707032,0 0.5,0.5 0 0 0 0,-0.707032 L 12.707031,12 15.853516,8.8535156 a 0.5,0.5 0 0 0 0,-0.7070312 0.5,0.5 0 0 0 -0.707032,0 L 12,11.292969 8.8535156,8.1464844 a 0.5,0.5 0 0 0 -0.7070312,0 z"; >> >> minor: we could probably minimize the path by rounding to 2 or 3 decimal points >> (same comment for all .css changes) > > any response on this? I asked ChatGPT to make the numbers shorter, and it did. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1956972354 From john.hendrikx at gmail.com Sun Feb 16 11:43:06 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 16 Feb 2025 12:43:06 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> <9893e816-d9c9-4924-8ddb-a54730230918@gmail.com> Message-ID: I took a bit of a closer look.? Although I think I can provide real properties, there will likely be quite a lot of edge cases with properties created on demand, and which only should exist while a Node lives under a certain Parent.? So, I think for an initial version, it would be best NOT to expose a static property providing method on HBox/VBox/GridPane as this would allow users to add listeners and bind to them, making an already complex life cycle even more so.??I think the feature will be incredibly useful even without this functionality. Exposing the properties, and providing support for full binding/listening will likely result in a disproportional amount of time invested there for something that is very niche at best. Although you can currently listen to (and modify)?these properties via the Observable properties map, the keys and stored data used by the various implementations are not part of any public API, so I feel that we can change how this works without restriction. That said, transitions will probably work now, however, looking at the type of properties, none of these seem suitable candidates for any reasonable form of transition (most are booleans or enums, a few margins, and a few integers for row/column indices/spans). TLDR; I will be going for?(transitionable) properties internally, but without exposing them as part of this feature, with a warning that if ever exposed, the impact of binding/listening needs to be thoroughly investigated --John On 13/02/2025 00:21, John Hendrikx wrote: > Yeah, it may be possible to do this; as said, I'm already storing a > StyleableProperty in the map (as it is needed to track the style origin > for the CSS system, otherwise it will never reset it when styles > changes), and exposing this property via a static property method would > certainly be trivial to do.?? > > Currently I'm storing the property and actual value in separate keys, > but I suppose there is no reason to have a separate key if the property > would hold the value.? I think that storing only a property would be a > better solution, perhaps with some code to avoid creating the property > similar to how lazy properties are done currently. > > This sounds promising, I'll look into it and see if I can get this > incorporated in the PoC. > > --John > > On 12/02/2025 20:10, Michael Strau? wrote: >> Maybe we can expand static properties to complete JavaFX properties. >> >> Right now, static properties are implemented with a getter and setter >> on the declaring class. We can add an additional property getter like >> so: >> >> class HBox { >> public static ObjectProperty marginProperty(Node child); >> public static void setMargin(Node child, Insets value); >> public static Insets getMargin(Node child); >> } >> >> Instead of storing the value directly in the properties map, we would >> store the ObjectProperty instead. In doing that, we can use the >> Styleable{Double,Object,...}Property implementations, which gives us >> access to the transition machinery. >> >> >> On Wed, Feb 12, 2025 at 3:27?PM John Hendrikx wrote: >>> Thanks, >>> >>> I may need some help with the transition part when the time arrives. In >>> CssStyleHelper these parent defined properties are treated no different >>> from any other properties, but I think some of the transition logic is >>> part of the properties themselves and I didn't implement that so far. >>> >>> How I've implemented them currently is with just-in-time properties that >>> only implement StyleableProperty (so it's not a full property that could >>> be bound). The actual storage is in the properties map associated with >>> all Nodes. >>> >>> I'll see if I can work this up as a PR over the weekend. It works >>> already, but needs some polishing and perhaps some optimization as its >>> part of CSS code. From michaelstrau2 at gmail.com Sun Feb 16 14:28:05 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 16 Feb 2025 15:28:05 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> <9893e816-d9c9-4924-8ddb-a54730230918@gmail.com> Message-ID: > I took a bit of a closer look. Although I think I can provide real > properties, there will likely be quite a lot of edge cases with > properties created on demand, and which only should exist while a Node > lives under a certain Parent. I think this is the wrong framing of what these properties actually are. Attached properties should be like regular properties, except that their API is declared in another class. Everything else should be the same; most crucially, they should have the same lifetime as the object to which they are attached. I would be astonished to learn that a property that I've set on a node suddently disappears just because I've moved the node around. In addition to that, attached properties should not be limited to container configuration; they are also suitable for rarely-used or special-purpose API. While it is true that attaching a HBox.margin property to a node is only relevant when the node is placed into a HBox, this doesn't mean that the node and its parent container are now eternally entangled. Doing that creates lots of problems for basically no benefit at all. Attaching HBox.margin to a node should be interpreted as: "if this node is placed in a HBox, then the following margin should apply". Attached properties should also not be implemented such that they hold a reference to their parent container, they should only add state to the object to which they are attached. With this in mind, I think the edge cases you're hinting at disappear. > That said, transitions will probably work now, however, looking at the > type of properties, none of these seem suitable candidates for any > reasonable form of transition (most are booleans or enums, a few > margins, and a few integers for row/column indices/spans). I don't think that it matters much if the transitions are reasonable, what matters is that they are consistent with normal properties. From nlisker at openjdk.org Mon Feb 17 01:32:20 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 17 Feb 2025 01:32:20 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing I've tested 9 cases before and after and I've just received an odd result in one of them. var property = new SimpleIntegerProperty(0); ChangeListener listenerA = (obs, ov, nv) -> { System.out.println("A got " + ov + "->" + nv + " (" + property.get() + ")"); System.out.println("A set->5"); property.set(5); }; ChangeListener listenerB = (obs, ov, nv) -> { System.out.println("B got " + ov + "->" + nv + " (" + property.get() + ")"); System.out.println("B removes A"); property.removeListener(listenerA); System.out.println("B set->6"); property.set(6); }; property.addListener(listenerA); property.addListener(listenerB); property.set(1); This prints A got 0->1 (1) A set->5 A got 1->5 (5) A set->5 B got 0->5 (5) B removes A B set->6 B got 5->null (6) B removes A B set->6 I don't think that `null` should be there, I'll give a more detailed report later, but wanted to point to this early. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2661758582 From nlisker at openjdk.org Mon Feb 17 02:01:17 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 17 Feb 2025 02:01:17 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing I'd say that the biggest surprise a user would have is about the nested addition of listeners. By the way, your table says that added listeners don't receive any event, but the "The PR" section says that they do. I've observed that they don't. I think that not receiving events for added listeners is confusing (we discussed this briefly under https://github.com/openjdk/jfx/pull/837). Is there a good reason for this? It prevents SO exceptions in some cases, but I would say that that's the user's fault. I need to think about this more, but was wondering what you concluded. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2661784907 From jhendrikx at openjdk.org Mon Feb 17 04:57:20 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 04:57:20 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing Thanks for taking a look again! > I'd say that the biggest surprise a user would have is about the nested addition of listeners. By the way, your table says that added listeners don't receive any event, but the "The PR" section says that they do. I've observed that they don't. I think that not receiving events for added listeners is confusing (we discussed this briefly under #837). Is there a good reason for this? It prevents SO exceptions in some cases, but I would say that that's the user's fault. I need to think about this more, but was wondering what you concluded. What part in the PR section? I found this: > Added listeners are only called when a new non-nested (top level) notification starts Both `ExpressionHelper` and this implementation will not notify an added listener within a callback for the same notification. `ExpressionHelper` will notify the newly added listener though if a *nested* change occurs before the original notification completes, while this implementation considers this to be integral with the first change. These are rare cases, and to observe this you would, as part of a single notification, have to a) add a listener, and b) change the value again. This is currently just an artifact of the implementation and is not specified anywhere. But let's see what we could do. For example, if I have 5 listeners, the top level notification would be A, B, C, D, E. If C decides to change the value, then it would for `ExpressionHelper` look like: ExpressionHelper | time -----------------------------> change 1: A B C D E (the last two with incorrect old values) change 2: A B C D E (the last two with incorrect old values) For this implementation it would look like: PR implementation | time -----------------------------> change 1: A B C D E change 2: A B C Now, if you added a new listener `F` in `B`, then it would change nothing in the current PR. `ExpressionHelper` however would look like: ExpressionHelper | time -----------------------------> change 1: A B C D E (the last two with incorrect old values) change 2: A B C D E F (the last three with incorrect old values) `F` gets called as part of the nested change, but it then continues notifying listeners from the original chain, but not again `F`. So, for the current implementation, you can clearly see that the notifications for the 2nd change only involve the listeners notified so far (A, B and C). In that 2nd change there is no logical place to call the newly added `F`; trying to fit it in there would break most of the logic that ensures correct old values, or would require something nasty like inserting `F` in a specific spot instead of at the end of the listener list... But perhaps we can call it where it does seem to fit nicely, after `E`. You would get: change 1: A B C D E F change 2: A B C Since `F` is now the last listener, and the last listener is in this implementation always called only as part of the top level change (unless it makes another modification), the only place where we could reasonably call it is at the top level (even if the listener was added during a deeper nested notification). Let's say we indeed implement this, then there are some consequences: - It still won't match `ExpressionHelper` :) - Even in non-nested cases, a newly added `F` would get notified as part of the ongoing notification (I won't be able to distinguish at what level it was added, nor if there was a nested change made) - The most common case (listener added as part of notification, but no nested change done) now differs significantly from `ExpressionHelper` as the newly added listener is called immediately, while `ExpressionHelper` only does that if there was a nested change Let me know what you think. I did not look if this viable to implement, but I'm pretty sure it could be done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2662001787 From arapte at openjdk.org Mon Feb 17 06:51:14 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 17 Feb 2025 06:51:14 GMT Subject: RFR: 8349758: Memory leak in TreeTableView In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 21:16:32 GMT, Andy Goryachev wrote: > ## Root Cause > > An event handler was installed on the root property without removing it when the root changes. > > ## Solution > > Replaced the weak parts with a change listener to the root property to ensure correct handling of the root value changes. Looks good... ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1706#pullrequestreview-2620159768 From azvegint at openjdk.org Mon Feb 17 13:03:33 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 17 Feb 2025 13:03:33 GMT Subject: [jfx24u] Integrated: 8349256: Update PipeWire to 1.3.81 In-Reply-To: References: Message-ID: <27vkjih0IYr61L5v0AloNs7qSGCpvKMEa7HlC-el6ug=.8f27c2aa-83fd-4652-a16c-5dadeb5849d5@github.com> On Fri, 14 Feb 2025 13:02:44 GMT, Alexander Zvegintsev wrote: > Hi all, > > This pull request contains a backport of commit [53fe8f1a](https://github.com/openjdk/jfx/commit/53fe8f1a03f7e5c386a3341315834751c17b8514) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Alexander Zvegintsev on 14 Feb 2025 and was reviewed by Lukasz Kostyra and Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: e8dcce30 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jfx24u/commit/e8dcce30a2785dd00d5114b2a7cb9eb88dae966b Stats: 2369 lines in 72 files changed: 1728 ins; 59 del; 582 mod 8349256: Update PipeWire to 1.3.81 Backport-of: 53fe8f1a03f7e5c386a3341315834751c17b8514 ------------- PR: https://git.openjdk.org/jfx24u/pull/5 From jhendrikx at openjdk.org Mon Feb 17 13:19:23 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 13:19:23 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <1rn8AodzxRhpNHOxO7vE20NZ06-9O-jUVapw_z2rAtM=.3206e2b1-46a0-4975-a747-6024b0501185@github.com> On Sat, 1 Feb 2025 12:57:34 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... > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Clean-up and add tests > - Pass in listener data directly for fireValueChanged calls > - Fix documentation in a few places > - Remove unused interface > - Update copyrights and add missing > ```java > var property = new SimpleIntegerProperty(0); > > ChangeListener listenerA = (obs, ov, nv) -> { > System.out.println("A got " + ov + "->" + nv + " (" + property.get() + ")"); > System.out.println("A set->5"); > property.set(5); > }; > > ChangeListener listenerB = (obs, ov, nv) -> { > System.out.println("B got " + ov + "->" + nv + " (" + property.get() + ")"); > System.out.println("B removes A"); > property.removeListener(listenerA); > System.out.println("B set->6"); > property.set(6); > }; > > property.addListener(listenerA); > property.addListener(listenerB); > > property.set(1); > ``` Thanks, I'm looking into this bug. You can remove the `property.set(5)` in listenerA and it still fails. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2663112914 From jhendrikx at openjdk.org Mon Feb 17 14:52:01 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 14:52:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v4] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # 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... John Hendrikx has updated the pull request incrementally with four additional commits since the last revision: - Documentation improvements - Clarification - Formatting - Fix edge case when first listener was removed during nested notification ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/139c2aa4..698cc3c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=02-03 Stats: 116 lines in 4 files changed: 65 ins; 17 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Mon Feb 17 14:55:20 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 14:55:20 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 01:58:34 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: >> >> - Clean-up and add tests >> - Pass in listener data directly for fireValueChanged calls >> - Fix documentation in a few places >> - Remove unused interface >> - Update copyrights and add missing > > I'd say that the biggest surprise a user would have is about the nested addition of listeners. By the way, your table says that added listeners don't receive any event, but the "The PR" section says that they do. I've observed that they don't. > I think that not receiving events for added listeners is confusing (we discussed this briefly under https://github.com/openjdk/jfx/pull/837). Is there a good reason for this? It prevents SO exceptions in some cases, but I would say that that's the user's fault. I need to think about this more, but was wondering what you concluded. @nlisker I found the problem, it was a slight ordering problem in the "optimized" code in `ListenerList`. It is supposed to obtain the current value from the observable in two cases; when it is the first time in the loop, or when a nested notification just completed. However, if the first listener was `null`d, then it skips the first iteration of the loop, and the logic that was supposed to get the current value on the first iteration is also skipped. The current value variable was then left `null`. I've added a regression test to guard for this and some explanatory comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2663354032 From jhendrikx at openjdk.org Mon Feb 17 15:37:56 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 15:37:56 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # 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... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix fix for regression :) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/698cc3c4..7affce77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=03-04 Stats: 18 lines in 1 file changed: 8 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From nlisker at openjdk.org Mon Feb 17 16:22:18 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 17 Feb 2025 16:22:18 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 04:53:41 GMT, John Hendrikx wrote: > What part in the PR section? I found this: > > > Added listeners are only called when a new non-nested (top level) notification starts Maybe I misunderstood what that section says. When I look at the list of differences it's written from the point of view of the new code: > * Provides correct old/new values to ChangeListeners under all circumstances > * Unnecessary change events are never sent > * Single invalidation or change listeners are inlined directly into the observable class (in other words, properties with only a single listener don't take up any extra space at all) > ... > * Added listeners are only called when a new non-nested (top level) notification starts But the table says "New listeners are never called during the current notification regardless of nesting". This is the mismatch I noticed. I think that that bullet point talks about the old code. > Both `ExpressionHelper` and this implementation will not notify an added listener within a callback for the same notification. `ExpressionHelper` will notify the newly added listener though if a _nested_ change occurs before the original notification completes, while this implementation considers this to be integral with the first change. This is what I observed, along with the example you give later. I also agree that the only place to add the listener in this implementation would be at the end of the top level in order to avoid the incorrect old value nested notifications. Let's look at 2 cases where a listener is added inside another, one before a nested change happens and one without a nested change. In the case where a nested change happens: * old code: the new listener will receive an incorrect value in the nested level. * current new code: the new listener will not receive a notification. * prospective new code: the new listener will receive a correct value in the top-level. In the case where an addition happens without a nested change: * old code: the new listener will not receive a notification. * current new code: same as above. * prospective new code: the new listener will receive a correct value in the top-level. So in the first case, the value is corrected. I would say that the current code removing the (incorrect) notification of the new listener is a behavioral change. In the second case, the prospective code's new notification is a behavioral change. Looks like we'll have to decide where the divergence is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2663570744 From mhanl at openjdk.org Mon Feb 17 20:41:14 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 17 Feb 2025 20:41:14 GMT Subject: RFR: 8349758: Memory leak in TreeTableView In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 21:16:32 GMT, Andy Goryachev wrote: > ## Root Cause > > An event handler was installed on the root property without removing it when the root changes. > > ## Solution > > Replaced the weak parts with a change listener to the root property to ensure correct handling of the root value changes. Looks good to me too, but a test would be nice as well ------------- PR Comment: https://git.openjdk.org/jfx/pull/1706#issuecomment-2664031836 From mstrauss at openjdk.org Mon Feb 17 21:13:19 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 17 Feb 2025 21:13:19 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <-6hrDlnujMjO2xf4JQAHRFjFnOOV0eKQRcYXlLvCGPg=.0d3526e7-9f0c-498c-ab0e-113cf7bc26a9@github.com> On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) Do you have any ideas on how to make `ChangeListener` also work sensibly for `ListProperty`, `SetProperty`, and `MapProperty`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664081310 From jhendrikx at openjdk.org Mon Feb 17 22:27:20 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 22:27:20 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: <-6hrDlnujMjO2xf4JQAHRFjFnOOV0eKQRcYXlLvCGPg=.0d3526e7-9f0c-498c-ab0e-113cf7bc26a9@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <-6hrDlnujMjO2xf4JQAHRFjFnOOV0eKQRcYXlLvCGPg=.0d3526e7-9f0c-498c-ab0e-113cf7bc26a9@github.com> Message-ID: On Mon, 17 Feb 2025 21:11:01 GMT, Michael Strau? wrote: > Do you have any ideas on how to make `ChangeListener` also work sensibly for `ListProperty`, `SetProperty`, and `MapProperty`? Well, I don't think it is reasonable or desired to have correct old values for these, as it would basically mean we'd need to clone the collection involved to give you a correct old value. The purpose of the old value here would be so you could do a diff and see what's changed, but these properties have their own callbacks for exactly that purpose. IMHO, it was a mistake to base these on properties; at most they should have provided invalidation + their custom diff-style callback. A big problem with `ListProperty` (versus just exposing say `ObservableList`) is that there are now two ways you can change the list. I can either replace it completely by doing `listProperty.set(list)` or I can do it with `listProperty.get().setAll(list)`. In the first case, a sensible old value is possible (you're using the `ListProperty` as a property, replacing its value with a new value). In the 2nd case however, there is no 2nd list involved, and both the old and new value can only refer to the same list. Cloning here would be too unreasonable to even consider. So, if it becomes a problem, I'd be in favor of marking the change listener methods on these as deprecated, as they're only useful to get a slightly more convenient form of invalidation listener where you don't have to call "get" but can just use the `newValue` parameter provided directly (ignoring the `oldValue` as it will contain nonsense). We could even still provide `subscribe(Consumer)` but implement it via invalidation + get for these properties. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664164237 From mhanl at openjdk.org Mon Feb 17 22:50:36 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 17 Feb 2025 22:50:36 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v4] In-Reply-To: References: Message-ID: <7qWGiPFlOw9ffqybN0V5r_Wo_23lOU-nOFUwJbYbG9k=.62e8c8ac-f4d2-484e-8847-a387108947c2@github.com> > This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. > > While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. > > It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). > Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Use virtualFlow directly ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1645/files - new: https://git.openjdk.org/jfx/pull/1645/files/e6595b8f..9b12fbf7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1645.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/jfx/pull/1645 From mhanl at openjdk.org Mon Feb 17 22:50:37 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 17 Feb 2025 22:50:37 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 13:18:35 GMT, Marius Hanl wrote: >> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. >> >> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. >> >> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). >> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge and adjust logic to master > - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup > - Call getFixedCellSize() once > - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup > Now that https://github.com/openjdk/jfx/pull/1644 has been merged, should this PR be re-opened? Yes! I wanted to check everything first before I reopen it. Should be good now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1645#issuecomment-2664186880 From mstrauss at openjdk.org Mon Feb 17 22:52:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 17 Feb 2025 22:52:17 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <-6hrDlnujMjO2xf4JQAHRFjFnOOV0eKQRcYXlLvCGPg=.0d3526e7-9f0c-498c-ab0e-113cf7bc26a9@github.com> Message-ID: On Mon, 17 Feb 2025 22:25:04 GMT, John Hendrikx wrote: > Well, I don't think it is reasonable or desired to have correct old values for these, as it would basically mean we'd need to clone the collection involved to give you a correct old value. The purpose of the old value here would be so you could do a diff and see what's changed, but these properties have their own callbacks for exactly that purpose. IMHO, it was a mistake to base these on properties; at most they should have provided invalidation + their custom diff-style callback. We could have `ChangeListener` only be called when the list instance is changed via `listProperty.set(list)`, but not when the content is replaced with `listProperty.get().setAll(list)`. I don't think that the current behavior makes any sense at all. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664188636 From mhanl at openjdk.org Mon Feb 17 22:56:56 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 17 Feb 2025 22:56:56 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v5] In-Reply-To: References: Message-ID: > This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. > > While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. > > It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). > Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Add as javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1645/files - new: https://git.openjdk.org/jfx/pull/1645/files/9b12fbf7..bb79066a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=03-04 Stats: 22 lines in 2 files changed: 12 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1645.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/jfx/pull/1645 From mhanl at openjdk.org Mon Feb 17 22:59:20 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 17 Feb 2025 22:59:20 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen [v10] In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 22:02:29 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> ~Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called.~ >> See below for more information. To recover the UI (and in general nested nested event loops ;) we need to set a flag for the `InvokeLaterDispatcher`. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [x] Adjust copyright >> - [x] Write Systemtest >> - [x] Document the new behaviour - in general, there should be more information what to expect > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? > > # Conflicts: > # tests/system/src/test/java/test/javafx/stage/NestedEventLoopTest.java > - Fix javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? > - Integrate changes as outline by beldenfox > - test for multiple nested event loops > - try leave outer loop after finishing inner loop > - update copyright > - trigger an outer nested event loop leave attempt > - do not attempt to leave eventloop after leaving another eventloop > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? > - ... and 3 more: https://git.openjdk.org/jfx/compare/076b4018...d0964880 Will convert this to a draft for now. I have no better idea right now. It would still be nice if we can improve the situation, as it is pretty bad right now that the event loop can jam and a dialog will render completely white (Had this multiple times in the past because I was showing a dialog on top of a dialog). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-2664195351 From jhendrikx at openjdk.org Mon Feb 17 23:50:17 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 17 Feb 2025 23:50:17 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <5YhVdMTYezOE0IUYhi7sCouGlF3i8d9lNP1IbxyM33Y=.73c8bd42-c29f-4871-983e-472e2c01611d@github.com> On Mon, 17 Feb 2025 16:19:29 GMT, Nir Lisker wrote: > > What part in the PR section? I found this: > > > Added listeners are only called when a new non-nested (top level) notification starts > > Maybe I misunderstood what that section says. When I look at the list of differences it's written from the point of view of the new code: > > > * Provides correct old/new values to ChangeListeners under all circumstances > > * Unnecessary change events are never sent > > * Single invalidation or change listeners are inlined directly into the observable class (in other words, properties with only a single listener don't take up any extra space at all) > > ... > > * Added listeners are only called when a new non-nested (top level) notification starts > > But the table says "New listeners are never called during the current notification regardless of nesting". This is the mismatch I noticed. I think that that bullet point talks about the old code. I don't quite see the mismatch (but I'm not a native speaker, so I may be missing something obvious). Both are supposed to be talking about the new code: "Added listeners are only called when a new non-nested (top level) notification starts" With that I mean that when you add a listener to a property during its own notification, that listener will not be called until a change occurs after the notification completes (ie. the change must be triggered by some 3rd party, not during the fire value changed callback). When the addition occurs in a nested notification for the same property, then it will not be called until the nested notifications have all completed, the top level notification completes, and **then** another change is made triggering a new notification. You could see it as the new listener is put on hold in a pending list, and this list is only updated when the property is in an "idle" state (ie. no notifications are ongoing). "New listeners are never called during the current notification regardless of nesting" I think this sort of says the same. Any new listeners added to a property are not called when a notification (nested or not) is still ongoing. The property must become idle before the new listener will participate. > > Both `ExpressionHelper` and this implementation will not notify an added listener within a callback for the same notification. `ExpressionHelper` will notify the newly added listener though if a _nested_ change occurs before the original notification completes, while this implementation considers this to be integral with the first change. > > This is what I observed, along with the example you give later. I also agree that the only place to add the listener in this implementation would be at the end of the top level in order to avoid the incorrect old value nested notifications. > > Let's look at 2 cases where a listener is added inside another, one before a nested change happens and one without a nested change. In the case where a nested change happens: > > * old code: the new listener will receive an incorrect value in the nested level. > * current new code: the new listener will not receive a notification. > * prospective new code: the new listener will receive a correct value in the top-level. > > In the case where an addition happens without a nested change: > > * old code: the new listener will not receive a notification. > * current new code: same as above. > * prospective new code: the new listener will receive a correct value in the top-level. Yes, this is pretty much spot on. > So in the first case, the value is corrected. I'm unsure what you mean by corrected here, A listener has no notion of a current value that must be corrected. If you want your listener to immediately receive the current value, then use `subscribe(Consumer)` -- `addListener(ChangeListener)` does not do an immediate callback, and always required a 2nd piece of code that does its own `get` if that was important (which it usually is, which is why I was very happy to see `subscribe(Consumer)` make it into FX). > I would say that the current code removing the (incorrect) notification of the new listener is a behavioral change. In the second case, the prospective code's new notification is a behavioral change. Looks like we'll have to decide where the divergence is. But is it a specified behavior or just an implementation artifact of `ExpressionHelper`? `ExpressionHelper` could conceivably be modified to not copy lists either, and just track an index to avoid copies for "performance reasons"; the small behavioral change would be mostly dismissed as "within specification". This change proves that it can be done, and with this concept as a template (especially the `progress` field trick) `ExpressionHelper` could be optimized to avoid copies (and I suppose with some more work, also provide correct old values). I think we can go either way here, as none of this is specified anywhere. JavaFX is full of listeners, and yet it builds and all tests run, so it seems at least not much is relying on this (unspecified) behavioral change. `ExpressionHelper` itself has had several detectable behavioral changes over the course of its existence as well. For me, the main question would be: "Does it make sense for a listener added during a notification to immediately partake in the notification that added it?". `ExpressionHelper` does not notify newly added listeners in the overwhelming majority of cases. It only happens when adding a new listener during a notification, and then making another change (which is discouraged see `InvalidationListener#invalidated`) I see only two options: - Notify new listeners near the end (because they're appended, not for any other reason) as part of a higher level (top level?) change in all cases, nested or not - This means a newly added listener even in the simple case gets the notification of the one that added it (this may be quite surprising, and we'll have to see if FX even builds if I do this :)) - Never notify new listeners when an ongoing change is going on (ie. while the property is "busy" in a callback) - This is the current implementation, and will probably do exactly what `ExpressionHelper` does in 99.9% of the cases I've tried getting my head around an option that would more closely do what `ExpressionHelper` does, but I don't see how I could make it work without major fundamental changes (and without sacrificing old value correctness again). We'd probably have to go to a system then where all listeners are notified of the first change first, and any further changes are queue'd up, to be executed in a 2nd (full) pass (and so on), so something like this: Value is set to from 4 to 5. A gets 4 -> 5 B gets 4 -> 5; adds listener F C gets 4 -> 5; changes value to 6, but we finish the current notification first D gets 4 -> 5 E gets 4-> 5 -- check is done if value was unchanged; we expected 5 but see 6, so another round is triggered -- A gets 5 -> 6 B gets 5 -> 6 (does not add another listener) C gets 5 -> 6 (does not change value again) D gets 5 -> 6 E gets 5 -> 6 F gets 5 -> 6 That can't be done with the current implementation though, it would basically be a new implementation, one that basically disallows nested changes of the same property by processing changes one by one (I'm not entirely sure what the consequences of that could be during say a complex layout, aside from shorter stacktraces) One immediate problem however is that the `newValue` received may differ from a direct `get` (D receives 4 -> 5 while the value is already 6) -- it's not easily fixed, and the solution for this problem chosen by `ExpressionHelper` (always send the latest value) basically means you can't rely on old/new value combinations, which is the whole reason for this PR in the first place ;-) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664241252 From jhendrikx at openjdk.org Tue Feb 18 00:03:19 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 18 Feb 2025 00:03:19 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <-6hrDlnujMjO2xf4JQAHRFjFnOOV0eKQRcYXlLvCGPg=.0d3526e7-9f0c-498c-ab0e-113cf7bc26a9@github.com> Message-ID: On Mon, 17 Feb 2025 22:49:48 GMT, Michael Strau? wrote: > > Well, I don't think it is reasonable or desired to have correct old values for these, as it would basically mean we'd need to clone the collection involved to give you a correct old value. The purpose of the old value here would be so you could do a diff and see what's changed, but these properties have their own callbacks for exactly that purpose. IMHO, it was a mistake to base these on properties; at most they should have provided invalidation + their custom diff-style callback. > > We could have `ChangeListener` only be called when the list instance is changed via `listProperty.set(list)`, but not when the content is replaced with `listProperty.get().setAll(list)`. I don't think that the current behavior makes any sense at all. Hm, yeah, I think I could get behind that, as it would actually make some more sense. Not sure if that would ever be accepted as a change though. At least one public API (that I could find in a few minutes) documents explicitly that change listeners will be called for content changes (and I'm sure there is code out there relying on it). In `ListPropertyBase`: /** * Sends notifications to all attached * {@link javafx.beans.InvalidationListener InvalidationListeners}, * {@link javafx.beans.value.ChangeListener ChangeListeners}, and * {@link javafx.collections.ListChangeListener}. * * This method is called when the content of the list changes. * * @param change the change that needs to be propagated */ protected void fireValueChangedEvent(ListChangeListener.Change change) { ListExpressionHelper.fireValueChangedEvent(helper, change); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664251427 From nlisker at openjdk.org Tue Feb 18 00:41:16 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 18 Feb 2025 00:41:16 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: <5YhVdMTYezOE0IUYhi7sCouGlF3i8d9lNP1IbxyM33Y=.73c8bd42-c29f-4871-983e-472e2c01611d@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <5YhVdMTYezOE0IUYhi7sCouGlF3i8d9lNP1IbxyM33Y=.73c8bd42-c29f-4871-983e-472e2c01611d@github.com> Message-ID: On Mon, 17 Feb 2025 23:47:57 GMT, John Hendrikx wrote: > With that I mean that when you add a listener to a property during its own notification, that listener will not be called until a change occurs after the notification completes (ie. the change must be triggered by some 3rd party, not during the fire value changed callback). OK, now I understand. > > So in the first case, the value is corrected. > > I'm unsure what you mean by corrected here I mean compared to the old behavior. In the old behavior, the listener was notified with an incorrect old value, while with the prospective new code (with added listeners) the listener will be notified with a correct value. With the current new code the listener isn't notified at all. So, the behavioral change, instead of incorrect->nothing, will be incorrect->correct. In the second case I listed, instead of the current nothing->nothing (no behavioral change), it will be nothing->correct. > But is it a specified behavior or just an implementation artifact of `ExpressionHelper`? No, thankfully, very little is specified. This allows us to implement a more sensible behavior... > For me, the main question would be: "Does it make sense for a listener added during a notification to immediately partake in the notification that added it?". > ... > * Notify new listeners near the end (because they're appended, not for any other reason) as part of a higher level (top level?) change in all cases, nested or not > * This means a newly added listener even in the simple case gets the notification of the one that added it (this may be quite surprising, and we'll have to see if FX even builds if I do this :)) > * Never notify new listeners when an ongoing change is going on (ie. while the property is "busy" in a callback) > * This is the current implementation, and will probably do exactly what ExpressionHelper does in 99.9% of the cases I'm not sure myself if it makes sense since I've never done this and cared about the behavior. I suppose it could go either way. If the first way is too complicated, the second one (this PR) is also reasonable. > One immediate problem however is that the `newValue` received may differ from a direct `get` I think it should be specified that these are the same, no? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664284987 From nlisker at openjdk.org Tue Feb 18 00:56:17 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 18 Feb 2025 00:56:17 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) Regarding vetoing, I noticed that only the first registered listener can veto since it overrides any subsequent value set. Suppose listener A changes the value to 5, B changes it to 6, C changes it to 7, and Z does nothing, then upon setting a value from 0 to 1 we will see: A sees 0->1; sets to 5 A sees 1->5 B sees 0->5; sets to 6 A sees 5->6; sets to 5 A sees 6->5 C got 0->5; sets to 7 A sees 5->7; sets to 5 A sees 7->5 Z sees 0->5 Is this intended? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664306130 From jhendrikx at openjdk.org Tue Feb 18 01:26:19 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 18 Feb 2025 01:26:19 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <5YhVdMTYezOE0IUYhi7sCouGlF3i8d9lNP1IbxyM33Y=.73c8bd42-c29f-4871-983e-472e2c01611d@github.com> Message-ID: On Tue, 18 Feb 2025 00:38:14 GMT, Nir Lisker wrote: > > > So in the first case, the value is corrected. > > > > I'm unsure what you mean by corrected here > > I mean compared to the old behavior. In the old behavior, the listener was notified with an incorrect old value, while with the prospective new code (with added listeners) the listener will be notified with a correct value. With the current new code the listener isn't notified at all. So, the behavioral change, instead of incorrect->nothing, will be incorrect->correct. Well, it is not truly an incorrect old value for a **new** listener (in `ExpressionHelper`), as it is only notified that one time, so there is no basis for comparison. I mean, the first call is always sort of correct (and `F` was only called one time in the nested notification, and was not called a 2nd time in the top level one). Only from the 2nd call is where it starts to get interesting, where users will expect that the old value will be the new value of the previous call... but I think I see what you're saying. > In the second case I listed, instead of the current nothing->nothing (no behavioral change), it will be nothing->correct. Yes, and I thought this would be quite a common case... but see below. > > But is it a specified behavior or just an implementation artifact of `ExpressionHelper`? > > No, thankfully, very little is specified. This allows us to implement a more sensible behavior... If there is one :) > I'm not sure myself if it makes sense since I've never done this and cared about the behavior. I suppose it could go either way. If the first way is too complicated, the second one (this PR) is also reasonable. I don't think that notifying a listener that was added during a notification of the same property would be too hard to implement. I also think I misevaluated the risks involved (I feared FX wouldn't even build). You'd only get an immediate notification if you add a listener to the **same** property that just notified you -- that's likely to be an exceedingly rare situation (after all, you already have a listener). I mixed this up with the pattern where you use the old and new values to unregister/reregister listeners -- but those are different properties, and so would not be subject to this change that gives you immediate notification. So, I now don't have a real preference anymore. Whether we should immediately notify a listener added during notification of the **same** property seems to be a very hypothetical case -- one which we're likely to leave unspecified no matter which solution we pick here. > > One immediate problem however is that the `newValue` received may differ from a direct `get` > > I think it should be specified that these are the same, no? It's not specified currently (couldn't find it on `ObservableValue` or `ChangeListener` docs) -- however, I think it is strongly expected by users that this is the case :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664346858 From jhendrikx at openjdk.org Tue Feb 18 01:38:18 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 18 Feb 2025 01:38:18 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 18 Feb 2025 00:53:59 GMT, Nir Lisker wrote: > Regarding vetoing, I noticed that only the first registered listener can veto since it overrides any subsequent value set. > > Suppose listener A changes the value to 5, B changes it to 6, C changes it to 7, and Z does nothing, then upon setting a value from 0 to 1 we will see: > > ``` > A sees 0->1; sets to 5 > A sees 1->5 > B sees 0->5; sets to 6 > A sees 5->6; sets to 5 > A sees 6->5 > C got 0->5; sets to 7 > A sees 5->7; sets to 5 > A sees 7->5 > Z sees 0->5 > ``` > > Is this intended? That's an interesting case. B is not notified that the value reverted to 5, as it was already previously notified with 5 (the call would be `5 -> 5` which is skipped). If we did however, we'd have an infinite loop which such unconditional vetoing going on. There can however be conditional vetoing. A case where A allows only positive values and B allows only uneven values would run like this: Value is set from 0 to -4. A sees 0 -> -4; changes it to 4 A sees -4 -> 4; does nothing B sees 0 -> 4; changes it to uneven 5 A sees 4 -> 5; does nothing B sees 4 -> 5; does nothing C sees 0 -> 5 I'm not sure what to think of this, and whether it needs a fix, and if so, what that fix should be... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664361246 From jbhaskar at openjdk.org Tue Feb 18 13:34:19 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 18 Feb 2025 13:34:19 GMT Subject: Integrated: 8349891: Not implemented function should have printf In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 03:43:25 GMT, Jay Bhaskar wrote: > Some newly added, unimplemented functions in FileSystemJava.cpp during the WebKit upgrade to version 620.1 should include print statements to indicate at runtime when these functions are invoked. This pull request has now been integrated. Changeset: 065548d0 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/065548d09dd4909137343e7e9eb2d25a336a34dd Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8349891: Not implemented function should have printf Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1711 From nlisker at openjdk.org Tue Feb 18 14:27:22 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 18 Feb 2025 14:27:22 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 18 Feb 2025 01:35:17 GMT, John Hendrikx wrote: > I'm not sure what to think of this, and whether it needs a fix, and if so, what that fix should be... Again I'm ill-equipped to answer this because I don't have experience using these nested changes. I'd say that controls that do vetoing need to be able to work correctly according to their indented use, and that should be the minimum. Hopefully others can weigh in regarding both the vetoing and the behavior of notifying an added listener. >>>One immediate problem however is that the newValue received may differ from a direct get >> >>I think it should be specified that these are the same, no? > >It's not specified currently (couldn't find it on ObservableValue or ChangeListener docs) -- however, I think it is strongly expected by users that this is the case :) I meant that we should specify it, not that it currently is :) I don't see a reason not to. I'll continue with the testing for now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2665866910 From mstrauss at openjdk.org Tue Feb 18 19:07:33 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 19:07:33 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) Should we document somewhere that safe vetoing is only possible with the first `InvalidationListener`, and not with a `ChangeListener`? This would also require us to specify that invalidation listeners are always invoked before change listeners. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2666518316 From angorya at openjdk.org Tue Feb 18 19:07:43 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:07:43 GMT Subject: RFR: 8349758: Memory leak in TreeTableView In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 20:38:30 GMT, Marius Hanl wrote: > Looks good to me too, but a test would be nice as well Similarly to https://github.com/openjdk/jfx/pull/1705#issuecomment-2652002160 , the `NodeInitializationStressTest` _is_ the test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1706#issuecomment-2666180967 From angorya at openjdk.org Tue Feb 18 19:07:43 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:07:43 GMT Subject: Integrated: 8349758: Memory leak in TreeTableView In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 21:16:32 GMT, Andy Goryachev wrote: > ## Root Cause > > An event handler was installed on the root property without removing it when the root changes. > > ## Solution > > Replaced the weak parts with a change listener to the root property to ensure correct handling of the root value changes. This pull request has now been integrated. Changeset: ae5864c2 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/ae5864c28a8e16aaf9887f7a2f2f10dfa323f9a3 Stats: 105 lines in 1 file changed: 41 ins; 57 del; 7 mod 8349758: Memory leak in TreeTableView Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1706 From angorya at openjdk.org Tue Feb 18 19:27:28 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:27:28 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 01:14:12 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonMetrics.java line 39: >> >>> 37: * @param minHeight the minimum height of the window buttons >>> 38: */ >>> 39: public record HeaderButtonMetrics(Dimension2D leftInset, Dimension2D rightInset, double minHeight) { >> >> would it make more sense to use Insets instead of Dimension2D? What if the app calls for asymmetrical padding? > > This class is not API, so it doesn't matter here. However, it matters in `HeaderBar.leftSystemInset/rightSystemInset`, which are both of type `Dimension2D`. The system insets are not arbitrary rectangles, they are always aligned with the top-left and top-right edges of the window. As such, the only necessary information is their spatial extent, which is best represented as a `Dimension2D`. > I'm not sure what you mean by asymmetrical padding. Can you elaborate? The word "inset" confused me. Could you use some other word here, if it is referring to a dimension? Like maybe explain where exactly these are used? >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 153: >> >>> 151: >>> 152: private static final CssMetaData BUTTON_DEFAULT_HEIGHT_METADATA = >>> 153: new CssMetaData<>("-fx-button-default-height", StyleConverter.getSizeConverter()) { >> >> The new styleables need to be documented in cssref.html as a part of this PR, right? >> (The javadoc for this class will not be visible in the API specification). > > `HeaderButtonOverlay` is not API, it's an internal implementation detail. The javadoc is just informational for future JavaFX developers. Let me clarify: I think the css properties must be listed in `cssref.html` as the component can be styled via CSS. I don't see the `cssref.html` file modified in this PR. >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 283: >> >>> 281: */ >>> 282: private final StyleableBooleanProperty allowRtl = >>> 283: new SimpleStyleableBooleanProperty(ALLOW_RTL_METADATA, this, "allowRtl", true) { >> >> what is the rationale for this property? >> Instead, I think, it should look at the `Node::getEffectiveNodeOrientation()` which either inherits the value from the parent or allows the app to override for a specific component (in other words, we already have this functionality for free). >> >> Or am I missing something? > > `HeaderButtonOverlay` inherits its node orientation from the scene, which is under the control of the application developer. On the other hand, `allowRtl` is under the control of JavaFX developers (that's us), specifying whether the selected header button implementation supports RTL layouts at all. Currently, all header button implementations do. > > The property is there to make all aspects of `HeaderButtonOverlay` styleable, so that future JavaFX developers can add other header button styles that may have fixed locations (i.e. don't move from one side to the other in RTL mode). should it have a different name then? `fixedPosition` or something like that? >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 632: >> >>> 630: } >>> 631: >>> 632: private static double boundedSize(double min, double pref, double max) { >> >> minor: >> it would be nice to move this to some common utilities class (there is already such a method in c.s.j.scene.control.skin.Utils class). >> >> along with two previous methods. > > We can also consider exposing this as API (not with this PR, though). If it's useful for us, it might also be useful for application developers. my earlier PR was shut down under the rubric "we could do better" but "we" never did. >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 299: >> >>> 297: } >>> 298: >>> 299: /** >> >> since the majority of windows is expected to be DECORATED, would it make more sense to move these properties into a separate container akin to `Node.getMiscProperties()` ? > > Sure, but the downside is that everything gets more bloated for little benefit. Right now, these properties are accessed in derived classes without any checks, since they are final and non-null. In this case, I think ease of use is more important. ease of use for whom? bloated code: a few bytes in extra methods bloated data: thousand of bytes added per instance Since we are adding properties to Window, it's probably ok because the number of instances is relatively low (a real app won't have hundreds of windows). Still, I would like to recommend investigating the alternative: the memory is not an unlimited resource, and in my experience, it's worth thinking about it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960289720 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960283225 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960278499 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960276809 PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960274585 From angorya at openjdk.org Tue Feb 18 19:27:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:27:32 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v21] In-Reply-To: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> <9Z6zLyGyKWrr6QQ8q02E8H1EmATT7E2sDTnFgeTT6DU=.4aaee131-e9a9-4965-8516-c3b9a6ea8dc4@github.com> Message-ID: <2FrvvGzRlgjLJhTua65RrGZv-FDDcMll1W-z3MKY_fI=.6d20d4cd-959c-489b-a89b-9f81cc8e80e6@github.com> On Sat, 15 Feb 2025 01:21:43 GMT, Michael Strau? wrote: >> any response on this? > > I asked ChatGPT to make the numbers shorter, and it did. Not a lawyer, but I am not entirely sure chatGPT contributions are compatible with OCA. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960348873 From angorya at openjdk.org Tue Feb 18 19:27:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:27:38 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v50] In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 01:19:04 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: > > minify button glyphs modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 126: > 124: > 125: .close-button > .glyph { > 126: -fx-shape: "m 8.1465,8.1465 a 0.5,0.5 0 0 0 0,0.707 L 11.293,12 8.1465,15.1465 a 0.5,0.5 0 0 0 0,0.707 0.5,0.5 0 0 0 0.707,0 L 12,12.707 l 3.1465,3.1465 a 0.5,0.5 0 0 0 0.707,0 0.5,0.5 0 0 0 0,-0.707 L 12.707,12 15.8535,8.8535 a 0.5,0.5 0 0 0 0,-0.707 0.5,0.5 0 0 0 -0.707,0 L 12,11.293 8.8535,8.1465 a 0.5,0.5 0 0 0 -0.707,0 z"; Not sure I like the idea of using chatGPT. The changes look inconsistent - some are rounded to 3 places after the decimal, some to 4 (3 should be sufficient, I think even 2 will suffice) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960264009 From mstrauss at openjdk.org Tue Feb 18 19:36:38 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 19:36:38 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 18:22:58 GMT, Andy Goryachev wrote: >> `HeaderButtonOverlay` is not API, it's an internal implementation detail. The javadoc is just informational for future JavaFX developers. > > Let me clarify: > I think the css properties must be listed in `cssref.html` as the component can be styled via CSS. I don't see the `cssref.html` file modified in this PR. `cssref.html` is the normative reference for the JavaFX CSS API. `HeaderButtonOverlay` is not API, it can't be styled by developers, it's completely inaccessible, and therefore must not be specified anywhere. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960455562 From mstrauss at openjdk.org Tue Feb 18 19:43:14 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 19:43:14 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v50] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 18:08:47 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> minify button glyphs > > modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 126: > >> 124: >> 125: .close-button > .glyph { >> 126: -fx-shape: "m 8.1465,8.1465 a 0.5,0.5 0 0 0 0,0.707 L 11.293,12 8.1465,15.1465 a 0.5,0.5 0 0 0 0,0.707 0.5,0.5 0 0 0 0.707,0 L 12,12.707 l 3.1465,3.1465 a 0.5,0.5 0 0 0 0.707,0 0.5,0.5 0 0 0 0,-0.707 L 12.707,12 15.8535,8.8535 a 0.5,0.5 0 0 0 0,-0.707 0.5,0.5 0 0 0 -0.707,0 L 12,11.293 8.8535,8.1465 a 0.5,0.5 0 0 0 -0.707,0 z"; > > Not sure I like the idea of using chatGPT. > The changes look inconsistent - some are rounded to 3 places after the decimal, some to 4 (3 should be sufficient, I think even 2 will suffice) There's no original work here that wasn't there before. I've checked the rounding, it's correct and consistent. There are three decimal places only when the fourth would be a zero. In any case, tweaking this further is a side-quest with no value. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960475268 From mstrauss at openjdk.org Tue Feb 18 19:46:18 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 19:46:18 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 18:16:26 GMT, Andy Goryachev wrote: >> Sure, but the downside is that everything gets more bloated for little benefit. Right now, these properties are accessed in derived classes without any checks, since they are final and non-null. In this case, I think ease of use is more important. > > ease of use for whom? > > bloated code: a few bytes in extra methods > bloated data: thousand of bytes added per instance > > Since we are adding properties to Window, it's probably ok because the number of instances is relatively low (a real app won't have hundreds of windows). > Still, I would like to recommend investigating the alternative: the memory is not an unlimited resource, and in my experience, it's worth thinking about it. Ease of use for JavaFX developers. Easily maintainable code is one of the most important aspects, miles ahead of chasing bytes and chasing nanoseconds. There's no tangible value in spending any considerable amount of time on thinking how to shave 150 bytes off of a window. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960480122 From angorya at openjdk.org Tue Feb 18 19:55:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:55:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: <0eUs6fno5ob_x1JGgJpeRTkkCj9NsH7EO9wqgV4wE3M=.290c2080-aa7e-442d-9384-bc39012ebd4c@github.com> On Tue, 18 Feb 2025 19:43:15 GMT, Michael Strau? wrote: >> ease of use for whom? >> >> bloated code: a few bytes in extra methods >> bloated data: thousand of bytes added per instance >> >> Since we are adding properties to Window, it's probably ok because the number of instances is relatively low (a real app won't have hundreds of windows). >> Still, I would like to recommend investigating the alternative: the memory is not an unlimited resource, and in my experience, it's worth thinking about it. > > Ease of use for JavaFX developers. Easily maintainable code is one of the most important aspects, miles ahead of chasing bytes and chasing nanoseconds. There's no tangible value in spending any considerable amount of time on thinking how to shave 150 bytes off of a window. a) we are _constantly_ adding runtime bytes, we have to be aware of the cost b) I think we should rather focus on the application developers, and they do not see the complexity behind the API. And moving a rarely used stuff into a rarely initialized object should not be a problem for any JavaFX developer, or am I mistaken? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960496373 From angorya at openjdk.org Tue Feb 18 19:59:05 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 19:59:05 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 19:33:48 GMT, Michael Strau? wrote: >> Let me clarify: >> I think the css properties must be listed in `cssref.html` as the component can be styled via CSS. I don't see the `cssref.html` file modified in this PR. > > `cssref.html` is the normative reference for the JavaFX CSS API. `HeaderButtonOverlay` is not API, it can't be styled by developers, it's completely inaccessible, and therefore must not be specified anywhere. > > It's even unspecified whether `HeaderButtonOverlay` is used _at all_. For example, on macOS it's never used. `cssref.html` **_IS_** a part of normative reference for JavaFX API. And my comment is not limited to a single class, it applies to every new CSS property added here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960500377 From mstrauss at openjdk.org Tue Feb 18 20:07:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 20:07:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 18:26:22 GMT, Andy Goryachev wrote: >> This class is not API, so it doesn't matter here. However, it matters in `HeaderBar.leftSystemInset/rightSystemInset`, which are both of type `Dimension2D`. The system insets are not arbitrary rectangles, they are always aligned with the top-left and top-right edges of the window. As such, the only necessary information is their spatial extent, which is best represented as a `Dimension2D`. >> I'm not sure what you mean by asymmetrical padding. Can you elaborate? > > The word "inset" confused me. Could you use some other word here, if it is referring to a dimension? Like maybe explain where exactly these are used? Are we talking about the specification of the system-reserved insets in `HeaderBar`? Or do you suggest to link from `HeaderButtonMetrics` to `HeaderBar`? /** * Describes the size of the left system-reserved inset, which is an area reserved for the iconify, maximize, * and close window buttons. If there are no window buttons on the left side of the window, the returned area * is an empty {@code Dimension2D}. *

    * Note that the left system inset refers to the left side of the window, independent of layout orientation. */ private final ReadOnlyObjectWrapper leftSystemInset = ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960518088 From mstrauss at openjdk.org Tue Feb 18 20:10:04 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 20:10:04 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: <1w_cPPX4G9JhHRGzNIdfFKR0MnEOw8Ldsjyix9M-Slc=.b52be0f3-310b-46b6-9507-267acb42bbb3@github.com> On Tue, 18 Feb 2025 19:55:58 GMT, Andy Goryachev wrote: >> `cssref.html` is the normative reference for the JavaFX CSS API. `HeaderButtonOverlay` is not API, it can't be styled by developers, it's completely inaccessible, and therefore must not be specified anywhere. >> >> It's even unspecified whether `HeaderButtonOverlay` is used _at all_. For example, on macOS it's never used. > > `cssref.html` **_IS_** a part of normative reference for JavaFX API. > > And my comment is not limited to a single class, it applies to every new CSS property added here. It seems we're going in circles here. You want me to specify something which I've repeatedly explained is not API. I can't specify something which is not API. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960521256 From angorya at openjdk.org Tue Feb 18 20:19:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 20:19:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: <1gCLAZmFlVtGLqR6BQBkLXp_FmxSXSVyLX8kdiPz8g4=.1cf10656-6621-44c0-99f0-bc751c549756@github.com> On Tue, 18 Feb 2025 20:04:37 GMT, Michael Strau? wrote: >> The word "inset" confused me. Could you use some other word here, if it is referring to a dimension? Like maybe explain where exactly these are used? > > Are we talking about the specification of the system-reserved insets in `HeaderBar`? Or do you suggest to link from `HeaderButtonMetrics` to `HeaderBar`? > > > /** > * Describes the size of the left system-reserved inset, which is an area reserved for the iconify, maximize, > * and close window buttons. If there are no window buttons on the left side of the window, the returned area > * is an empty {@code Dimension2D}. > *

    > * Note that the left system inset refers to the left side of the window, independent of layout orientation. > */ > private final ReadOnlyObjectWrapper leftSystemInset = a link would be nice, yes (for javafx developers) :-) it could be just me - the word "inset" confused me ("insets" -> `Insets`, "inset" -> `Dimension2D`), but I guess it does describe the concept correctly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960533763 From angorya at openjdk.org Tue Feb 18 20:24:10 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 20:24:10 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: <1w_cPPX4G9JhHRGzNIdfFKR0MnEOw8Ldsjyix9M-Slc=.b52be0f3-310b-46b6-9507-267acb42bbb3@github.com> References: <1w_cPPX4G9JhHRGzNIdfFKR0MnEOw8Ldsjyix9M-Slc=.b52be0f3-310b-46b6-9507-267acb42bbb3@github.com> Message-ID: On Tue, 18 Feb 2025 20:07:12 GMT, Michael Strau? wrote: >> `cssref.html` **_IS_** a part of normative reference for JavaFX API. >> >> And my comment is not limited to a single class, it applies to every new CSS property added here. > > It seems we're going in circles here. You want me to specify something which I've repeatedly explained is not API. I can't specify something which is not API. Are you saying not a single styleable property can be set with an application CSS, only internally? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960538741 From angorya at openjdk.org Tue Feb 18 20:24:11 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 20:24:11 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v50] In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 01:19:04 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: > > minify button glyphs modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 341: > 339: * @param trailing the trailing node > 340: */ > 341: public HeaderBar(Node leading, Node center, Node trailing) { here you refer to "leading" and "trailing", but the system insets are "left" and "right", why is that? When the platform goes RTL, don't the buttons flip as well? Should the system insets be referred to as leading/trailing? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960536558 From mstrauss at openjdk.org Tue Feb 18 20:45:03 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 20:45:03 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: <1w_cPPX4G9JhHRGzNIdfFKR0MnEOw8Ldsjyix9M-Slc=.b52be0f3-310b-46b6-9507-267acb42bbb3@github.com> Message-ID: On Tue, 18 Feb 2025 20:21:07 GMT, Andy Goryachev wrote: >> It seems we're going in circles here. You want me to specify something which I've repeatedly explained is not API. I can't specify something which is not API. > > Are you saying not a single styleable property can be set with an application CSS, only internally? It's a bit like using deep reflection to access internals. It's technically possible, but explicitly unsupported. Much in the same way, any attempt to style header buttons can stop working at any time (because we're free to change the implementation in any way without prior notice). If we were to even mention the internal structure of `HeaderButtonOverlay`, we'd sign up for all of the compatibility guarantees that users expect from public API. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960564289 From angorya at openjdk.org Tue Feb 18 20:50:07 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Feb 2025 20:50:07 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: <1w_cPPX4G9JhHRGzNIdfFKR0MnEOw8Ldsjyix9M-Slc=.b52be0f3-310b-46b6-9507-267acb42bbb3@github.com> Message-ID: On Tue, 18 Feb 2025 20:42:41 GMT, Michael Strau? wrote: >> Are you saying not a single styleable property can be set with an application CSS, only internally? > > It's a bit like using deep reflection to access internals. It's technically possible, but explicitly unsupported. Much in the same way, any attempt to style header buttons can stop working at any time (because we're free to change the implementation in any way without prior notice). If we were to even mention the internal structure of `HeaderButtonOverlay`, we'd sign up for all of the compatibility guarantees that users expect from public API. got it, thanks! maybe add a not pointing to the css where the styles are being defined? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960569562 From mstrauss at openjdk.org Tue Feb 18 20:53:06 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 18 Feb 2025 20:53:06 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v50] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 20:19:06 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> minify button glyphs > > modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 341: > >> 339: * @param trailing the trailing node >> 340: */ >> 341: public HeaderBar(Node leading, Node center, Node trailing) { > > here you refer to "leading" and "trailing", but the system insets are "left" and "right", why is that? > > When the platform goes RTL, don't the buttons flip as well? Should the system insets be referred to as leading/trailing? On most platforms, the header buttons will switch sides when using RTL orientation, but it doesn't necessarily have to do that. For example, if you switch the layout orientation after the window has been shown, the header buttons will stay where they are. I'm using "leading" and "trailing" when I'm referring to JavaFX layout, which can change at any time. On the other hand, I'm using "left" and "right" to refer to the physical placement of window buttons, which may be different from JavaFX layout. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1960572904 From nlisker at openjdk.org Wed Feb 19 00:25:59 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 19 Feb 2025 00:25:59 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) Another scenario I want to bring to attention: Listener B does nothing, listener A sets the value to 5 and then removes listener B. Listener A is registered first. Setting the property value from 0 to 1 to trigger the chain. A got 0->1; A set->5 A got 1->5; does nothing A removes B A removes B B does not have time to react to either change. It does not react to the `1->5` nested change because these were trimmed so that it won't have a `1->5` incorrect old value notification. It also doesn't react to the `0->5` event at the top level because it was removed in the nested event. I'm not sure if this is the expected behavior from a user. Should B never have a chance to react? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2667218580 From jhendrikx at openjdk.org Wed Feb 19 01:18:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 19 Feb 2025 01:18:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Wed, 19 Feb 2025 00:22:59 GMT, Nir Lisker wrote: > Another scenario I want to bring to attention: Listener B does nothing, listener A sets the value to 5 and then removes listener B. Listener A is registered first. Setting the property value from 0 to 1 to trigger the chain. > > ``` > A got 0->1; A set->5 > A got 1->5; does nothing > A removes B > A removes B > ``` > > B does not have time to react to either change. It does not react to the `1->5` nested change because these were trimmed so that it won't have a `1->5` incorrect old value notification. It also doesn't react to the `0->5` event at the top level because it was removed in the nested event. > > I'm not sure if this is the expected behavior from a user. Should B never have a chance to react? I'm going to assume that A and B are aware of each other, and are somehow working together, as this scenario makes little sense otherwise. The code that is using these two listeners is then likely coming from the same implementation (how else would A have a reference to B). So, given that, if an implementation decides to remove B, no matter when that happens exactly (outside a notification call, or within one), would it be reasonable to expect a callback still? A removal may have entailed cleaning up of other resources. Having to code listeners defensively "just in case" it was called still after removal seems to me not something you should need to do. So, I think the least surprising scenario would be to have removals take immediate effect. It is however up to the system as a whole to decide this. The rules governing the system IMHO should be: - When listener is first added, the system has leeway in deciding when it will be called first, but at a minimum should call it for the next top-level change - When a listener has been called once, it **must** be called for every subsequent change after the first (with the exception of callbacks that are not changes, ie. `5 -> 5`, which can only happen if earlier listeners modify the value) - When a listener is removed, the system has leeway in deciding when its last notification will be, but at a minimum should not call a removed listener for a new top-level change Given that: - a top-level action is an action that is not happening in a notification callback of the same property; ie. the property is currently "idle" and not processing a notification - a nested action is an action that occurs in a notification of the **same** property Here is a comparison table: | |When?|ExpressionHelper|ListenerManager (new)| |---|---|---|---| |Listener addition|Top-level|Called on next top-level change|Called on next top-level change| | |Nested|Called on next top-level change, unless value changes|Called on next top-level change(*)| |Value Changes|Top-level|Calls always with correct old value|Calls always with correct old value| | |Nested|Calls always but possibly with an old value not matching previous new value|Calls only if value changed to ensure it does not have to send a bogus old value| |Listener removal|Top-level|No further calls|No further calls| | |Nested|May still be called **after** removal if registered later|Never, removal is immediate| (*) subject to debate I feel I also should point out that such dependencies between listeners (where listener A removes B, or adds C or whatever) can only happen in code that is aware of these other listeners. There is no way to obtain a reference to a listener from the system, and so all of these scenario's have perfect knowledge of what each listener does and their life cycles. There can be no surprises here, listeners can't be added or removed by some other class or 3rd party dependency without a reference to them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2667270380 From jbhaskar at openjdk.org Wed Feb 19 01:24:46 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 19 Feb 2025 01:24:46 GMT Subject: [jfx24u] RFR: 8349891: Not implemented function should have printf Message-ID: A clean backport to jfx24u. The change is a follow-up fix for newly implemented functions, ensuring that print statements are included where necessary. ------------- Commit messages: - Backport 065548d09dd4909137343e7e9eb2d25a336a34dd Changes: https://git.openjdk.org/jfx24u/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349891 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx24u/pull/6.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/6/head:pull/6 PR: https://git.openjdk.org/jfx24u/pull/6 From nlisker at openjdk.org Wed Feb 19 01:44:02 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 19 Feb 2025 01:44:02 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Wed, 19 Feb 2025 01:09:59 GMT, John Hendrikx wrote: > I'm going to assume that A and B are aware of each other, and are somehow working together, as this scenario makes little sense otherwise. The code that is using these two listeners is then likely coming from the same implementation (how else would A have a reference to B). Yes, here is an example: var property = new SimpleIntegerProperty(0); ChangeListener listenerB = (obs, ov, nv) -> { }; ChangeListener listenerA = (obs, ov, nv) -> { property.set(5); property.removeListener(listenerB); }; property.addListener(listenerA); property.addListener(listenerB); property.set(1); > So, given that, if an implementation decides to remove B, no matter when that happens exactly (outside a notification call, or within one), would it be reasonable to expect a callback still? Here is how I walked through this in my head: A gets 0->1; sets 5 A gets 1->5; setting 5 does nothing B gets 0->5 A removes B (in the 1->5 event) A removes B (in the 0->1 event) That is, after A reacts to the new value 5, it's B's turn to react *before* it's removed. It could be just me though. > Here is a comparison table: It looks good, but it doesn't strictly contradict the example. A listener should stop receiving notifications immediately when it's removed, but here it's not removed yet and still doesn't receive notifications. >I feel I also should point out that such dependencies between listeners (where listener A removes B, or adds C or whatever) can only happen in code that is aware of these other listeners. There is no way to obtain a reference to a listener from the system, and so all of these scenario's have perfect knowledge of what each listener does and their life cycles. There can be no surprises here, listeners can't be added or removed by some other class or 3rd party dependency without a reference to them. Yes, this is just another case where I'm not sure we're doing the right thing, not that I'm sure we're not. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2667310653 From jhendrikx at openjdk.org Wed Feb 19 01:58:16 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 19 Feb 2025 01:58:16 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 18 Feb 2025 18:14:55 GMT, Michael Strau? wrote: > Should we document somewhere that safe vetoing is only possible with the first `InvalidationListener`, and not with a `ChangeListener`? This would also require us to specify that invalidation listeners are always invoked before change listeners. Specifying that invalidation happens before change callbacks is something we probably should do no matter what; in my earlier experiments I found that messing with this order breaks a lot of code in FX itself (couldn't get it to build), let alone in code that uses FX. The term "vetoing" is something I probably should not have used. I just used it to indicate a value was changed within a notification callback for the same property; its not an actual veto system (if listeners are unaware of each other, a veto system can easily get deadlocked with conflicting requirements). So yes, a listener that is not the first listener can't truly enforce that a property value meets some restrictions. The correct way to do vetoing is to override `set` on the property (although if you created the property and registered its first invalidation listener, you can get away with it); both this implementation and `ExpressionHelper` will do a final `equals` before notifying change listeners, and if `set` simply refuses to modify the value due to restrictions, no change notification will go out (you may see invalidations though). The fact that a change of value within a callback can result in later listeners to not be called ("vetoing") is just something that arises from providing correct old values. The rules I've been using for old and new values are: Rule 1: Old value received in callback X must match new value received in callback X-1 Rule 2: Old value should never `Object::equals` new value (collection properties break this rule) Rule 3: The received new value is the same as `property::get` If you agree with these rules, then we can see what this means for the implementation. >From these rules it arises that a later listener may not need to be informed if an earlier listener changed a value. Given two listeners A and B, if the last call to B was "5 -> 6", then if another value change occurs (to 7) and A changes the value back to 6, then we have a few options: 1. Call B with `6 -> 6` 2. Call B with `7 -> 6` 3. Call B with `6 -> 7` followed by `7 -> 6` 4. Don't call B When looking at the above options, remember that `B` was last called with a new value of `6`. Option 1 is avoided by `ExpressionHelper`, it will never do this (but in order to do so will provide bad old values). I think it makes sense for the new implementation to also avoid this as there is little use for telling a listener "Hey, nothing changed" Option 2 is basically what `ExpressionHelper` does, and breaks Rule 1 -- B never saw a value of `7`, it comes out of nowhere, and it may take actions based on it that would be wrong (trying to remove a listener from property 7, then adding (another) listener on property 6 .. now there are two listeners on 6) Option 3 could be a sensible option, but does violate Rule 3; the received new value is not the same as the value obtained from reading the property. This may be very surprising (it looks like a concurrent change, while FX is single threaded). If we choose this path, it may break code that uses change listeners just for the callback, and uses `property::get` to read the value (perhaps in something the listener calls, without passing the actual new value, or even some mix of both) Option 4 is what this PR implements, and does not break any of the rules that I think make sense for a good change listener callback. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2667322381 From jhendrikx at openjdk.org Wed Feb 19 03:51:03 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 19 Feb 2025 03:51:03 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) > > I'm going to assume that A and B are aware of each other, and are somehow working together, as this scenario makes little sense otherwise. The code that is using these two listeners is then likely coming from the same implementation (how else would A have a reference to B). > > Yes, here is an example: > > ```java > var property = new SimpleIntegerProperty(0); > > ChangeListener listenerB = (obs, ov, nv) -> { > }; > > ChangeListener listenerA = (obs, ov, nv) -> { > property.set(5); > property.removeListener(listenerB); > }; > > property.addListener(listenerA); > property.addListener(listenerB); > > property.set(1); > ``` > > > So, given that, if an implementation decides to remove B, no matter when that happens exactly (outside a notification call, or within one), would it be reasonable to expect a callback still? > > Here is how I walked through this in my head: > > ``` > A gets 0->1; sets 5 > A gets 1->5; setting 5 does nothing > B gets 0->5 > A removes B (in the 1->5 event) > A removes B (in the 0->1 event) > ``` I see, so from reading the code, you see `property.set(5)` and then assume (not unjustified) that everyone will first see the value change to `5`. Then the removal of B happens. I can see how that is a logical thought process. What exactly happens however is more complicated, and I guess that's why a warning to not modify the same property within a callback is still justified even with this new implementation. There may be a way to make this a bit more logical, I think I could offer an alternative solution. I've added a passive listener C after B and a passive listener Z before A to ensure they don't receive bad values: - (`progress` is set to 0 and we call Z) - Z gets 0 -> 1 - (`progress` is set to 1 and we call A) - A gets 0 -> 1; sets 5 triggering a new notification - (nested level starts, but continues with next listener instead of from start, communicated down with the `progress` field) - (`progress` is set to 2 and we call B) - B gets 0 -> 5 - (`progress` is set to 3 and we call C) - C gets 0 -> 5 - (no more listeners, set progress to `-1` to indicate a nested notification occurred and exit) - (we now arrive back in the listener A code) - A removes B - (listener callback A has now completed and returned control back to the top-level notification loop; this loop notices there was a nested notification as `progress` variable now contains `-1` instead of the index; it is going to assume that every subsequent listener was notified already by the nested level, and so breaks off its loop not continuing with B or C) - (an explicit check is done if the last called listener from its perspective (A) resulted in the value changing; normally yes, otherwise there was no nested call, but in the nested call it could have been modified again back to the value A last received) - (if the current value (5 in this case) is not the same as what A received (1) then start a partial loop containing only the listeners notified so far in this loop) - (`progress` is set to 0 and we call Z) - Z gets 1 -> 5 - (`progress` is set to 1 and we call A) - A gets 1 -> 5 I've looked at this for a few hours now, but can't say yet for sure if this is a better alternative or if it would work correctly if more listeners make changes; I think it may work. It's sort of the opposite of what the PR implementation is doing now. The PR basically will restart from the first listener in a nested level and stop when reaching the last listener notified in the parent level. The parent level then continues where it left off. Assuming we have listeners Z, A, B, C, D, and that listeners A and C make a change once it would look like: Z (0 -> 1) A (0 -> 1) wants >1 so sets 2 Z (1 -> 2) A (1 -> 2) B (0 -> 2) C (0 -> 2) wants >2 so sets 3 Z (2 -> 3) A (2 -> 3) B (2 -> 3) C (2 -> 3) D (0 -> 3) The alternative idea above sort of inverts this; a nested level continues where the parent level left off and the parent will renotify all listeners it notified at its level if the current value isn't what it thinks it should be: Z (0 -> 1) A (0 -> 1) wants >1 so sets 2 B (0 -> 2) C (0 -> 2) wants >2 so sets 3 D (0 -> 3) (check if value changed, renotify anyone notified in this level, in this case B and C) B (2 -> 3) C (2 -> 3) (check if value changed, renotify anyone notified in this level, in this case Z and A) Z (1 -> 3) A (1 -> 3) Now, whether this will be more logical from a user perspective remains to be seen. It calls listeners in a different order, and doesn't always end with the "last" listener (this could have consequences for added listeners, but its a niche case as said before). One thing that jumps out is that it needs even less calls to achieve the same goal. It's really late here, and I've been thinking about this for a few hours now; I see some potential for this alternative, it may indeed be more logical, and I think it wouldn't require more information to be passed between nested levels than I do currently (currently that's the `progress` field only). I will have to get back to you on this. > That is, after A reacts to the new value 5, it's B's turn to react _before_ it's removed. It could be just me though. As you can see from the above, I think you may have a valid point here. > > Here is a comparison table: > > It looks good, but it doesn't strictly contradict the example. A listener should stop receiving notifications immediately when it's removed, but here it's not removed yet and still doesn't receive notifications. It's the nature of the PR implementation, but may be odd from a user perspective. > > I feel I also should point out that such dependencies between listeners (where listener A removes B, or adds C or whatever) can only happen in code that is aware of these other listeners. There is no way to obtain a reference to a listener from the system, and so all of these scenario's have perfect knowledge of what each listener does and their life cycles. There can be no surprises here, listeners can't be added or removed by some other class or 3rd party dependency without a reference to them. > > Yes, this is just another case where I'm not sure we're doing the right thing, not that I'm sure we're not. It would still be nice if the system makes sense for implementations that manage multiple listeners in this way, however, we're basically discussing scenario's where 1 implementation for some inexplicable reason has multiple listeners on the **same** property, and is actively adding/removing them at random times, and then hopes it all still makes some sense (for varying definitions of sense... :)) Perhaps the proposed alternative would improve these extremely exotic scenario's, but we should really only consider such an alternative if it doesn't make the far more common cases harder to grasp for users... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2667438500 From arapte at openjdk.org Wed Feb 19 12:48:06 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 19 Feb 2025 12:48:06 GMT Subject: RFR: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 03:51:28 GMT, Alexander Matveev wrote: >> - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. >> - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. >> - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. >> - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video [v2] LGTM... ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1695#pullrequestreview-2626683864 From kcr at openjdk.org Wed Feb 19 13:31:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Feb 2025 13:31:15 GMT Subject: [jfx24u] RFR: Merge jfx:jfx24 Message-ID: Clean merge from `jfx:jfx24` into `jfx24u:master`. ------------- Commit messages: - Merge remote-tracking branch 'jfx/jfx24' into merge-jfx-jfx24-to-master-2025-02-19 - 8344367: Fix mistakes in FX API docs The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx24u/pull/7/files Stats: 78 lines in 40 files changed: 1 ins; 0 del; 77 mod Patch: https://git.openjdk.org/jfx24u/pull/7.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/7/head:pull/7 PR: https://git.openjdk.org/jfx24u/pull/7 From kcr at openjdk.org Wed Feb 19 13:49:01 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 19 Feb 2025 13:49:01 GMT Subject: [jfx24u] Integrated: Merge jfx:jfx24 In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 13:25:55 GMT, Kevin Rushforth wrote: > Clean merge from `jfx:jfx24` into `jfx24u:master`. This pull request has now been integrated. Changeset: 3f6fa19b Author: Kevin Rushforth URL: https://git.openjdk.org/jfx24u/commit/3f6fa19bf55bf8012cbf7290f22fd1898d837367 Stats: 78 lines in 40 files changed: 1 ins; 0 del; 77 mod Merge ------------- PR: https://git.openjdk.org/jfx24u/pull/7 From jbhaskar at openjdk.org Wed Feb 19 16:24:10 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 19 Feb 2025 16:24:10 GMT Subject: [jfx24u] Integrated: 8349891: Not implemented function should have printf In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 01:20:10 GMT, Jay Bhaskar wrote: > A clean backport to jfx24u. The change is a follow-up fix for newly implemented functions, ensuring that print statements are included where necessary. This pull request has now been integrated. Changeset: c29f0b62 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx24u/commit/c29f0b62daaa03ac776e3a8f3208b9c3b5dd7c35 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8349891: Not implemented function should have printf Backport-of: 065548d09dd4909137343e7e9eb2d25a336a34dd ------------- PR: https://git.openjdk.org/jfx24u/pull/6 From almatvee at openjdk.org Wed Feb 19 16:41:05 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 19 Feb 2025 16:41:05 GMT Subject: Integrated: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video In-Reply-To: References: Message-ID: <7MnFjUWfVeb8_k9vgr3Rl59aCLGusnbBdUadsqTRgOQ=.a5c03849-9822-4ce8-b875-daf5ed0ef4c3@github.com> On Wed, 5 Feb 2025 03:00:17 GMT, Alexander Matveev wrote: > - Added new class `CMFGSTBuffer` which can allocate memory internally or provide GStreamer allocated memory to Media Foundation. > - Added `GstBufferPool` to limit allocation of output buffers used for rendering (memory will not be allocated for each buffer, but instead will be reused from pool). Limits are 3 min buffers and 6 max buffers. During testing 3 buffers was enough. > - Changed `CoInitializeEx` to `COINIT_MULTITHREADED` as per Media Foundation requirements. > - Added error handling for `ProcessOutput` in case of https://bugs.openjdk.org/browse/JDK-8329227. With error handling `MediaPlayer` fails nicely instead of silent hang. This pull request has now been integrated. Changeset: 307e3087 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/307e3087f350bee5f73710b00588784696e84b07 Stats: 890 lines in 8 files changed: 640 ins; 64 del; 186 mod 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video Reviewed-by: kcr, arapte, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1695 From nlisker at openjdk.org Thu Feb 20 03:11:05 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 20 Feb 2025 03:11:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) I've thought about it and I would like to hear what others think. I have a behavior in mind that I find intuitive, but it doesn't mean others will. It actually includes throwing SOEs when listeners fight to set a value, I don't think it's an incorrect behavior (user's fault). Using your Z, A to D order, where A and C change values, Z 0->1 A 0->1; set 2 Z 1->2; A 1->2; no change B 0->2 C 0->2; sets 3 Z 2->3 A 2->3; if A sets 2 we will get a SOE because of recursive changes; let's say A wants value>=2 and not ==2 B 2->3 C 2->3; no change D 0->3 D ignores set->2 event since it got a more updated value (tracked by the progress value?) B, C, D ignore set->1 event since they got a more updated value This should still preserve the 3 rules you outlined. Each listener reacts immediately (depth first) and always in order. This causes the last listener to act to be the one that determines the final value, and not the first one. The ignored values end up being the later ones. This, of course, doesn't deal with removal/addition of listeners. I think that removal should work immediately as it does now, but still allow the immediate notifications prior. About addition I'm still not sure. --- I want to take a boarder view again for a moment. I went back to https://github.com/openjdk/jfx/pull/837 to make sure I didn't drift off course. The fixes for change listeners only pertain to nested events, right? Without nested events, even the current `ExpressionListener` works correctly, yes? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2670354834 From kcr at openjdk.org Thu Feb 20 13:46:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 20 Feb 2025 13:46:31 GMT Subject: RFR: 8350437: [GHA] Update gradle wrapper-validation action to v3 Message-ID: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> Update the GitHub gradle wrapper-validation action to v3. In addition to being a good practice in general, we've had a few intermittent failures in the existing validation task, and updating to the latest might help with this. ------------- Commit messages: - [GHA] Update gradle wrapper-validation action to v3 Changes: https://git.openjdk.org/jfx/pull/1718/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1718&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350437 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1718.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1718/head:pull/1718 PR: https://git.openjdk.org/jfx/pull/1718 From jhendrikx at openjdk.org Thu Feb 20 14:11:09 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 20 Feb 2025 14:11:09 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Thu, 20 Feb 2025 03:08:33 GMT, Nir Lisker wrote: > I've thought about it and I would like to hear what others think. I have a behavior in mind that I find intuitive, but it doesn't mean others will. It actually includes throwing SOEs when listeners fight to set a value, I don't think it's an incorrect behavior (user's fault). Using your Z, A to D order, where A and C change values, > > ``` > Z 0->1 > A 0->1; set 2 > Z 1->2; > A 1->2; no change > B 0->2 > C 0->2; sets 3 > Z 2->3 > A 2->3; if A sets 2 we will get a SOE because of recursive changes; let's say A wants value>=2 and not ==2 > B 2->3 > C 2->3; no change > D 0->3 > D ignores set->2 event since it got a more updated value (tracked by the progress value?) > B, C, D ignore set->1 event since they got a more updated value > ``` Apart from the nesting you have, this is exactly what this PR currently does. The problem with the nesting you have is that we can really only track one old value per nesting. If we need to track individual old values then we need to wrap each listener and give the wrapper a field with what value was sent last to it. For reference, this is what the current PR does: Z 0->1 A 0->1; set 2 Z 1->2; A 1->2; no change (exits nesting, original loop has correct old value to send) B 0->2 C 0->2; sets 3 Z 2->3 A 2->3; if A sets 2 we will get a SOE because of recursive changes; let's say A wants value>=2 and not ==2 B 2->3 C 2->3; no change (exits nesting, original loop has correct old value to send) D 0->3 (removed the "ignore lines", they're not needed) > This should still preserve the 3 rules you outlined. Each listener reacts immediately (depth first) and always in order. This causes the last listener to act to be the one that determines the final value, and not the first one. The amount of nesting really doesn't change much in when a listener acts (aside from niche edge cases with listener addition/removal on the **same** property, which I'm now of the opinion that we should not be looking at too closely). Also I'm not sure what you mean with your last sentence. If `D` were to change something, every listener would get called again, and again have the option to change things. Also note, this kind of value changes with listeners is never going to work with arbitrary listeners from different sources, unless they have non-conflicting rules that only move "forward" (ie. if listener A receives X, and changes it to Y, then receives Z, but also changes that to Y, then we're moving backwards and we'll not be able to resolve this kind of conflict without a more elaborate rule system -- in this system it won't result in a SOE (but maybe it should), but in `ExpressionHelper` it would). The only real way to enforce a rule on a property is to override `set` (and if you want rules from multiple sources, construct a different mechanism for it, `RuleBasedProperty` or something). Currently you can also enforce a rule by ensuring you install the first invalidation listener (but that's already "hoping" that the notification system is implemented in a certain way). We may however want to keep that intact as FX has Controls relying on this (but updating the controls is an option). When it comes to value changes, you can only have it one way; either last wins and earlier listeners may be unaware of a value being reset, or first wins and later listeners may be unaware of a value being reset. Neither will be intuitive; given the way listeners are currently already used for "veto" style behavior, I think it would be far better to go for the "first wins" option, as anyone can always install a later listener breaking whatever you intended in the last-wins case. So I think the questions we need to answer are:

    Are we going to specify the "vetoing" behavior in such detail that users may rely on this?

    Should conflicting modifications in listeners lead to an exception or warning log instead of silent failure?

    To clarify that last question; if an earlier listener persistently changes a value to 3, and a later listener persistently changes it to 4, then the earlier listener currently wins, and when notifying the later listener, we notice that the old value is the same as the new value so its 2nd notification is elided (ie, it received `0 -> 3` but changes it to `4`; the first listener sets it back to `3` again; now we need to notify the later listener with `3 -> 3` which we don't do) -- this leads to this listener being under the impression the value is 4 (the value that it set), while it has changed back to 3. Note: all cases where two listeners are in conflict, and are kept informed of ALL changes (breaking Rule 3 for example) will lead to SOE. I think our main problem is that this doesn't happen in the current implementation, but instead the conflict is "resolved" silently, with later listeners having the wrong impression. They can check this though if they really want, but doing this: laterListener = (obs, ov, nv)-> { property.set(4); // triggers nested notification if(property.get() != 4) { // oops, someone changed it back or changed it again... // it may be possible to resolve that here, but NOT by changing it to 4 again... } } I think a good rule is that only one listener should be changing values, if any at all; anything more, and you're going to need a system that is not as simplistic as a notification system. > The ignored values end up being the later ones. This, of course, doesn't deal with removal/addition of listeners. I think that removal should work immediately as it does now, but still allow the immediate notifications prior. About addition I'm still not sure. Remember, this is adding/removing of listeners on the same property by a listener on that property. It probably never happens in current code as it does not make a lot of sense; `ExpressionHelper` does not handle this gracefully either, just differently. Adding/removing listeners on other properties will work as expected. > I want to take a boarder view again for a moment. I went back to #837 to make sure I didn't drift off course. The fixes for change listeners only pertain to nested events, right? Without nested events, even the current `ExpressionListener` works correctly, yes? That's correct. This PR fixes old values for nested cases, as bad old values (or duplicated new values) can be very harmful for the common case of managing a chain of property listeners (ie. node -> scene -> window). If there were even a single nested change there by some user listener, the chain will end up broken with too few or too many listeners as one of the three rules I outlined would be broken and code isn't expecting this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2671611805 From jhendrikx at openjdk.org Thu Feb 20 14:40:03 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 20 Feb 2025 14:40:03 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <6vh2T5GaL9HpIr2eY5DUfO6qaq4gotR-FXVUj7u4eX0=.8cbd7001-8c52-43b4-bfbe-c664f8bf15cc@github.com> On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :)

    Rules

    This PR was created because there is an unwritten contract for `ChangeListener`s that people expect, but that we are currently not guaranteeing. I've written these down as three rules: Rule 1: Old value received in callback X must match new value received in callback X-1 Rule 2: Old value should never Object::equals new value (collection properties break this rule) Rule 3: The received new value is the same as property::get I think these rules need to become part of the specification of `ChangeListener`. A possible further rule that I think we may want to explicitly specify somewhere is: Rule 4: A listener is never notified after removal

    Edge Case: Two listeners upon notification change the value, and cannot reach agreement

    |ExpressionHelper|This PR|Specification| |---|---|---| |This leads to a `StackOverflowError` as new nested levels of notifications keep being added until the stack is exhausted. During this process the listeners receive old values they may never have seen before violating Rule 1|The later listener will stop being called as its last received value equals the notification value if it was changed back; the listener will not be called (to preserve Rule 2) and so is unaware that the value has changed to something it didn't set|Specify that conflicting changes lead to an exception| Opinion: this PR should probably not silently allow this but instead throw an exception ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2671686463 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2671687002 From jhendrikx at openjdk.org Thu Feb 20 14:50:05 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 20 Feb 2025 14:50:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :)

    Edge Case: A listener upon notification removes an earlier listener, then makes a nested change

    |ExpressionHelper|This PR|Specification| |---|---|---| |The removed listener is not notified of the initial or nested change|The removed listener is not notified of the initial or nested change|Leave unspecified| Opinion: as this operates on the same property on which you already have a listener, and the listener you removed must be something you have a reference to (and so probably created yourself), this case makes little sense in real world applications. We should leave it unspecified.

    Edge Case: A listener upon notification removes a later listener, then makes a nested change

    |ExpressionHelper|This PR|Specification| |---|---|---| |The removed listener is still notified of the initial change that triggered the initial notification as lists are copied|A removed listener is under no circumstances notified after removal|Leave unspecified| Opinion: as this operates on the same property on which you already have a listener, and the listener you removed must be something you have a reference to (and so probably created yourself), this case makes little sense in real world applications. We should leave it unspecified.

    Edge Case: A listener upon notification adds a listener, then makes a nested change

    |ExpressionHelper|This PR|Specification| |---|---|---| |The added listener is notified of the nested change, but not of the initial change|The added listener is not notified of the initial change, nor of the nested change|Leave unspecified| Opinion: as this operates on the same property on which you already have a listener, the added listener is superfluous; this case also makes little sense in real world applications. We should leave it unspecified. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2671717626 From angorya at openjdk.org Thu Feb 20 16:05:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 16:05:58 GMT Subject: RFR: 8350437: [GHA] Update gradle wrapper-validation action to v3 In-Reply-To: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> References: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> Message-ID: On Thu, 20 Feb 2025 13:42:01 GMT, Kevin Rushforth wrote: > Update the GitHub gradle wrapper-validation action to v3. In addition to being a good practice in general, we've had a few intermittent failures in the existing validation task, and updating to the latest might help with this. The GHA actions in this PR runs just fine which should be sufficient to validate the fix. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1718#pullrequestreview-2630385747 From angorya at openjdk.org Thu Feb 20 16:13:04 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 16:13:04 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Thu, 6 Feb 2025 20:14:43 GMT, Kevin Rushforth wrote: >> Root Cause: >> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. >> >> I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. >> >> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. >> >> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. >> >> With this change, it is safe to create and populate charts with data in a background thread. >> >> --- >> >> ## NOTES >> >> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. >> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > Reviewers: @kevinrushforth @azuev-java Hi @kevinrushforth and @azuev-java , could you please re-approve this PR to unblock two more? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2671963887 From angorya at openjdk.org Thu Feb 20 19:11:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 19:11:58 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v5] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 22:56:56 GMT, Marius Hanl wrote: >> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. >> >> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. >> >> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). >> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Add as javadoc A good improvement! The testing on macOS 15.3.1 M1 looks good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1645#pullrequestreview-2630899253 From angorya at openjdk.org Thu Feb 20 19:30:29 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 19:30:29 GMT Subject: RFR: 8342565: [TestBug] StubTextLayout [v4] 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 22 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout - review comments - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout - atomic boolean - Merge branch 'master' into 8342565.stub.text.layout - cleanup - better test - cleanup - more magic - magic numbers - ... and 12 more: https://git.openjdk.org/jfx/compare/cc65512e...d2128477 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1667/files - new: https://git.openjdk.org/jfx/pull/1667/files/b1042820..d2128477 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=02-03 Stats: 779077 lines in 8294 files changed: 648376 ins; 72616 del; 58085 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 Thu Feb 20 19:40:42 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 19:40:42 GMT Subject: RFR: 8347359: RichTextArea API Tests [v2] In-Reply-To: References: Message-ID: > Additional RichTextArea API tests. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests - 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 8347359.rta.api.tests - newlines - check - cleanup - clamp - get text - ... and 10 more: https://git.openjdk.org/jfx/compare/307e3087...d6e9ba3f ------------- Changes: https://git.openjdk.org/jfx/pull/1677/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=01 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 kcr at openjdk.org Thu Feb 20 21:58:11 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 20 Feb 2025 21:58:11 GMT Subject: RFR: 8350437: [GHA] Update gradle wrapper-validation action to v3 In-Reply-To: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> References: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> Message-ID: On Thu, 20 Feb 2025 13:42:01 GMT, Kevin Rushforth wrote: > Update the GitHub gradle wrapper-validation action to v3. In addition to being a good practice in general, we've had a few intermittent failures in the existing validation task, and updating to the latest might help with this. I'll integrate this tomorrow. Btw, I pushed this fix to a [bad-gradle-wrapper-validation-v3](https://github.com/kevinrushforth/jfx/tree/refs/heads/bad-gradle-wrapper-validation-v3) test branch, along with a commit that injects a failure by updating `gradle-wrapper.jar` such that the checksum doesn't match (I unzipped and rezipped it). The updated v3 version of the gradle wrapper-validation action still catches the problem: https://github.com/kevinrushforth/jfx/actions/runs/13442644497 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1718#issuecomment-2672776163 From angorya at openjdk.org Thu Feb 20 22:46:08 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 22:46:08 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes Message-ID: ## Added Missing Controls ButtonBar ProgressIndicator Separator Slider, ## Added Node Classes AnchorPane AmbientLight Arc BorderPane Box Circle CubicCurve Cylinder DialogPane DirectionalLight Ellipse FlowPane GridPane Group HBox ImageView Line MediaView MeshView Pane ParallelCamera Path PerspectiveCamera PointLight Polygon Polyline QuadCurve Rectangle Region Sphere StackPane SVGPath TilePane VBox ## Miscellaneous - minor improvements - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) ## Not Included Due to Threading Limitations HTMLEditor MenuBar SwingNode WebView ------------- Commit messages: - cleanup - images - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 - media - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 - 3d - shapes - show() - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 - panes - ... and 2 more: https://git.openjdk.org/jfx/compare/065548d0...6d4e99f7 Changes: https://git.openjdk.org/jfx/pull/1713/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1713&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349750 Stats: 868 lines in 2 files changed: 829 ins; 13 del; 26 mod Patch: https://git.openjdk.org/jfx/pull/1713.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1713/head:pull/1713 PR: https://git.openjdk.org/jfx/pull/1713 From angorya at openjdk.org Thu Feb 20 22:51:12 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 22:51:12 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin Message-ID: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> - enforced fx application thread - added a headful test `TestThreadingRestrictions` ## Note to the Reviewers To avoid merge conflicts, the preferred order of integrations: #1697 #1713 #1717 ------------- Commit messages: - fixed node init test - all tests - initial test Changes: https://git.openjdk.org/jfx/pull/1717/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350048 Stats: 472 lines in 11 files changed: 429 ins; 14 del; 29 mod Patch: https://git.openjdk.org/jfx/pull/1717.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717 PR: https://git.openjdk.org/jfx/pull/1717 From angorya at openjdk.org Thu Feb 20 23:04:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Feb 2025 23:04:15 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v4] In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: > Root Cause: > (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. > > I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. > > Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. > > The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. > > With this change, it is safe to create and populate charts with data in a background thread. > > --- > > ## NOTES > > 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. > 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - enabled pie chart test - Merge branch 'master' into 8349091.charts.thread.safety - Merge branch 'master' into 8349091.charts.thread.safety - whitespace - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - cleanup - tests pass - chart tests only - more jitter - ... and 12 more: https://git.openjdk.org/jfx/compare/307e3087...e60c027b ------------- Changes: https://git.openjdk.org/jfx/pull/1697/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=03 Stats: 305 lines in 11 files changed: 165 ins; 101 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1697.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697 PR: https://git.openjdk.org/jfx/pull/1697 From mstrauss at openjdk.org Fri Feb 21 02:00:07 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Feb 2025 02:00:07 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: <0eUs6fno5ob_x1JGgJpeRTkkCj9NsH7EO9wqgV4wE3M=.290c2080-aa7e-442d-9384-bc39012ebd4c@github.com> References: <0eUs6fno5ob_x1JGgJpeRTkkCj9NsH7EO9wqgV4wE3M=.290c2080-aa7e-442d-9384-bc39012ebd4c@github.com> Message-ID: On Tue, 18 Feb 2025 19:52:44 GMT, Andy Goryachev wrote: >> Ease of use for JavaFX developers. Easily maintainable code is one of the most important aspects, miles ahead of chasing bytes and chasing nanoseconds. There's no tangible value in spending any considerable amount of time on thinking how to shave 150 bytes off of a window. > > a) we are _constantly_ adding runtime bytes, we have to be aware of the cost > b) I think we should rather focus on the application developers, and they do not see the complexity behind the API. And moving a rarely used stuff into a rarely initialized object should not be a problem for any JavaFX developer, or am I mistaken? Here's the problem: we're also constantly adding code that needs to be written, reviewed, tested, and maintained. We're talking about a small amount of code here in this particular example, but then again, what particular straw broke the camel's back? I think we have to be aware of runtime overhead where it matters most: in hot loops, or where something is instantiated tens of thousands of times. In all other cases, focusing on bytes and nanoseconds can actually be detrimental in the long run. It makes code inherently harder to reason about, and when many such "optimizations" are taken together, we can end up with code that you can't change any more for fear of breaking the myriads of code paths. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1964634245 From mstrauss at openjdk.org Fri Feb 21 02:44:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Feb 2025 02:44:47 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v51] In-Reply-To: References: Message-ID: <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@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: remove HeaderButtonOverlay.allowRtl ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/cd9c2a94..394c95f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=50 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=49-50 Stats: 68 lines in 5 files changed: 0 ins; 66 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 Fri Feb 21 02:44:48 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Feb 2025 02:44:48 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v49] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 18:19:33 GMT, Andy Goryachev wrote: >> `HeaderButtonOverlay` inherits its node orientation from the scene, which is under the control of the application developer. On the other hand, `allowRtl` is under the control of JavaFX developers (that's us), specifying whether the selected header button implementation supports RTL layouts at all. Currently, all header button implementations do. >> >> The property is there to make all aspects of `HeaderButtonOverlay` styleable, so that future JavaFX developers can add other header button styles that may have fixed locations (i.e. don't move from one side to the other in RTL mode). > > should it have a different name then? `fixedPosition` or something like that? I've removed `allowRtl` completely. Let's entertain this problem when (and if) we decide to have system-provided header buttons that don't adjust for RTL mode. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1964663979 From mstrauss at openjdk.org Fri Feb 21 02:58:08 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Feb 2025 02:58:08 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: <6vh2T5GaL9HpIr2eY5DUfO6qaq4gotR-FXVUj7u4eX0=.8cbd7001-8c52-43b4-bfbe-c664f8bf15cc@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <6vh2T5GaL9HpIr2eY5DUfO6qaq4gotR-FXVUj7u4eX0=.8cbd7001-8c52-43b4-bfbe-c664f8bf15cc@github.com> Message-ID: On Thu, 20 Feb 2025 14:36:11 GMT, John Hendrikx wrote: > I think these rules need to become part of the specification of `ChangeListener`. If we do that, then we 1. break many implementations that don't use the property base classes ("break" as in: render them non-compliant) 2. force compliant implementations to basically re-implement this PR, which is unreasonable We should think about providing a listener management API that third parties can use to easily create compliant implementations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2673238902 From jhendrikx at openjdk.org Fri Feb 21 06:17:10 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 21 Feb 2025 06:17:10 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <6vh2T5GaL9HpIr2eY5DUfO6qaq4gotR-FXVUj7u4eX0=.8cbd7001-8c52-43b4-bfbe-c664f8bf15cc@github.com> Message-ID: On Fri, 21 Feb 2025 02:55:22 GMT, Michael Strau? wrote: > > I think these rules need to become part of the specification of `ChangeListener`. > > If we do that, then we > > 1. break many implementations that don't use the property base classes ("break" as in: render them non-compliant) > 2. force compliant implementations to basically re-implement this PR, which is unreasonable > > We should think about providing a listener management API that third parties can use to easily create compliant implementations. The code in this PR could partially become public API. I'd then probably also provide a simpler option that doesn't rely on an `Object` field for optimization, so users can choose to go fully optimized or (more likely) use a simpler option as it probably only matters for core FX properties. Interfaces however can't enforce anything. Its easy to create a non-compliant `Set` implementation (See JavaFX `BitSet`). Such non-compliant implementations have wide ranging consequences however, as they may accidentally get exposed in public API as plain `Set`s (see Node#getPseudoClassStates -- now fixed). That doesn't mean that interfaces shouldn't specify what a compliant implementation is. There is already an implicit expectation as to how change listeners operate, derived from their name ("change") and their parameters ("old value", "new value"). It is reasonable to expect to be only called on a change ("old value" != "new value"); it is also reasonable to expect that the old value is what was received in the previous's call new value (this saves caching the value when you really need it). If such values are unreliable, then there is just no point to the entire interface; you might as well use `InvalidationListener`, store your own "old value" and get the current value directly from the property. The point of encoding these expectations in the interface is that when bugs occur, it is clear who is at fault; the user who is unable to deal with bad values, or the implementation that provides them. So, yes, 3rd parties may become non-compliant (but only in edge cases where they were probably already broken) so nothing changes there. With the implicit rules now spelled out it is however now easier for users to file bug reports against non-compliant implementations, not to mention, much easier for users to see that Change Listeners indeed provide what they likely already **assumed** to be true... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2673567634 From dani-kurmann at protonmail.com Fri Feb 21 14:02:08 2025 From: dani-kurmann at protonmail.com (dani-kurmann) Date: Fri, 21 Feb 2025 14:02:08 +0000 Subject: bugfix JDK-8229902, 2025 edition Message-ID: Hi everyone, I registered autumn of last year for a bugfix(Bug JDK-8229902). I have a working bugfix, but was asked to investigate the issue a bit deeper in order to find an appropriate course of action. I wasnt able to put in enough time before the end-of-year and beginning-of-year madness at my dayjobs, so sorry for the slow pace. Now, I was able to put in some more time and I feel like I am a step further. So here's my two cents: Like already explained, the bug is caused by the conditional flush()-call in the freespace-function (this is called to make sure that there is enough space in the buffer, before something is put into it). The unconditional flushBuffer()-call works fine, however. You can fix the bug by setting m_autoflush to false or commenting out the flush()-call in freespace. (file: /modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/RenderingQueue.cpp) Since both functions contain the word "flush", I feel the urge to explain: The RenderingQueue is basically a LinkedList of Bytearrays. the freespace-function checks if there is enough space in the current bytearray for whatever you want to put in it. If there is not enough space, a new Bytearray is declared and set as current, so that what you put into the buffer gets put into the new bytearray. However, this new bytearray is NOT part of the LinkedList on the java side of things, but exists only in c++. So here is what the two functions are doing: - flushBuffer "flushes" the current c++ bytearray into the java LinkedList and declares a new current c++-Bytearray. After this, you have a new, empty c++ Bytearray, and the LinkedList on the java side contains one more Bytearray (the old current c++ array) - flush() "flushes" the whole LinkedList of bytearrays. It decodes all its Bytearrays. After this, you have a new, empty java LinkedList. (in file: modules/javafx.web/src/main/java/com/sun/webkit/graphics /WCRenderQueue.java, BufferData is a helper class around a ByteArray, its a bit confusing, flushBuffer adds a new BufferData to the list, but only on the next flushBuffer-call, the bytebuffer of the bufferdata gets set to the bytearray, and can therefore be decoded by flush()) Now there is still some mess here, (does it work to put in Glyphs? to me it looks like they never make it into the bytearray) there are flushbuffer calls directly before freespace-calls, so clearly space and time is wasted. (~30% time on my setup, still havent checked how much memory can be saved) I see two ways of tackling this beast: 1. clearly the naming is confusing and has lead to mistakes in using the RenderingQueue from the outside. I could maybe make the naming a bit better and explain the two functions better in the comments. Then fix or take out the unnecessary/inefficient flush/flushBuffer-calls, just from a time and (memory)space point of view, the bug AND related inefficencies are perfectly solvable this way. 2. solve the problem "once and for all": The way I see it, todays buffer-solution is unnecessary complicated. Wouldnt it be nicer, if you could just put things into the buffer and let the RenderingQueue worry about the details(is there enough space etc.)? Same thing when you want the Queue to decode. The fact that the current bytebuffer has to be "flushed" into the LinkedList before decoding is a special technique of the RenderingQueue. Of course, you should know about it, if you are messing around inside RenderingQueue. But when you are just using a RenderingQueue, I think you should be freed from the resposibility of micromanaging RenderingQueue. I will need to put in some more time for either solution. This is not just a bugfix for the specific bug. My first approach was to fix the bug with minimal changes (just "flipping" one bit from true to false), now I would prefer to fix the underlying problem in a more substantial way. And if I'm doing that, I would prefer strategy (2.), rather than (1.) Even tough (2.) will not cause alot of code change, it will significantly change RenderingQueues behavior as seen from the outside, rather than just fix its wrong or inefficient behavior. Of course I will still need to present the solution in a git commit in order for you people to decide if thats a good idea/strategy. What do you guys (or just Kevin ?) think? You want me to put my time into a more comprehensive strategy or is my time better spent fixing specific problems and leave the bigger changes to people with more experience and knowledge? kind regards Dani Kurmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Feb 21 16:38:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Feb 2025 16:38:59 GMT Subject: Integrated: 8350437: [GHA] Update gradle wrapper-validation action to v3 In-Reply-To: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> References: <26w37zu-xT-8YN4B7-YfFUhIXzquGPCnEnmr9QbF80s=.36a0a2e8-b7b6-429e-887c-e8840b1dca5a@github.com> Message-ID: On Thu, 20 Feb 2025 13:42:01 GMT, Kevin Rushforth wrote: > Update the GitHub gradle wrapper-validation action to v3. In addition to being a good practice in general, we've had a few intermittent failures in the existing validation task, and updating to the latest might help with this. This pull request has now been integrated. Changeset: 163bf6d4 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/163bf6d42fde7de0454695311746964ff6bc1f49 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8350437: [GHA] Update gradle wrapper-validation action to v3 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1718 From kcr at openjdk.org Fri Feb 21 16:43:38 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Feb 2025 16:43:38 GMT Subject: [jfx24u] RFR: 8350437: [GHA] Update gradle wrapper-validation action to v3 Message-ID: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> Clean backport of GHA-only fix to jfx24u. ------------- Commit messages: - Backport 163bf6d42fde7de0454695311746964ff6bc1f49 Changes: https://git.openjdk.org/jfx24u/pull/8/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=8&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350437 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx24u/pull/8.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/8/head:pull/8 PR: https://git.openjdk.org/jfx24u/pull/8 From arapte at openjdk.org Fri Feb 21 17:43:14 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 21 Feb 2025 17:43:14 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 Message-ID: Update copyright year in files updated in the year 2025. ------------- Commit messages: - 8349472: Update copyright header for files modified in 2025 Changes: https://git.openjdk.org/jfx/pull/1721/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1721&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349472 Stats: 172 lines in 172 files changed: 0 ins; 0 del; 172 mod Patch: https://git.openjdk.org/jfx/pull/1721.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1721/head:pull/1721 PR: https://git.openjdk.org/jfx/pull/1721 From angorya at openjdk.org Fri Feb 21 17:50:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Feb 2025 17:50:58 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 17:39:03 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2025. I am one of the culprits! For my education, how is this list generated? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1721#pullrequestreview-2633822340 PR Comment: https://git.openjdk.org/jfx/pull/1721#issuecomment-2675186774 From angorya at openjdk.org Fri Feb 21 18:07:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Feb 2025 18:07:59 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 17:39:03 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2025. Are incubator modules included in the list? `incubator.richteext/src/main/java/module-info.java` seems to be missing ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1721#pullrequestreview-2633859784 From kcr at openjdk.org Fri Feb 21 18:27:00 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Feb 2025 18:27:00 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 17:39:03 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2025. We have an internal tool that generates this. We exclude certain commits that should not "count" for some reason. Usually, they are related to updating copyright year's themselves, but in some cases they are excluded because the git commit date in the repo doesn't tell the whole story. Specifically, the following fix was integrated in 2025, but the contents of that PR were last touched in 2024 (no commit in the source branch was done in 2025). [JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121): RichTextArea Control (Incubator) So we exclude that from the list. While looking at this, I noticed that there are 4 additional commits that we should exclude when running the copyright tool script (for the same reason). All of these commits were from PRs last modified in 2024, but just waiting for the CSR to be approved or a second reviewer before integrating early in 2025. [JDK-8343398](https://bugs.openjdk.org/browse/JDK-8343398): Add reducedData preference [JDK-8346227](https://bugs.openjdk.org/browse/JDK-8346227): Seal Paint and Material [JDK-8342703](https://bugs.openjdk.org/browse/JDK-8342703): CSS transition is not started when initial value was not specified [JDK-8342233](https://bugs.openjdk.org/browse/JDK-8342233): Regression: TextInputControl selection is backwards in RTL mode And we need to make sure that for those 5 commits, all of the files touched have (at least) a 2024 date as the last modified year. @arapte will update. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1721#issuecomment-2675256324 PR Comment: https://git.openjdk.org/jfx/pull/1721#issuecomment-2675257811 From angorya at openjdk.org Fri Feb 21 18:32:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Feb 2025 18:32:57 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 17:39:03 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2025. could this tool be run in a git hook on each integration or something like that? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1721#issuecomment-2675267963 From kcr at openjdk.org Fri Feb 21 18:41:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Feb 2025 18:41:56 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 17:39:03 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2025. If by "git hook" you mean "something the Skara bots could do" (we do not and cannot use raw git hooks), it's been suggested. That's a much longer discussion, but the short answer is "no" (or at least "not at this time"). I'm not in favor of it anyway. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1721#issuecomment-2675283767 From nlisker at openjdk.org Fri Feb 21 19:04:04 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 21 Feb 2025 19:04:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 17 Feb 2025 15:37:56 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... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix fix for regression :) modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManagerBase.java line 41: > 39: * @param the type of the instance providing listener data > 40: */ > 41: public abstract class ListenerManagerBase> { Is this a class and not an interface because of the need for `protected` methods? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1966029617 From jhendrikx at openjdk.org Fri Feb 21 21:45:04 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 21 Feb 2025 21:45:04 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Fri, 21 Feb 2025 19:01:03 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix fix for regression :) > > modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManagerBase.java line 41: > >> 39: * @param the type of the instance providing listener data >> 40: */ >> 41: public abstract class ListenerManagerBase> { > > Is this a class and not an interface because of the need for `protected` methods? I think I extracted this when I discovered that I needed two implementations (caching one and one that doesn't need caching, to save more memory). Looking at it now (over a year later) I suppose it could also be an interface. There is no risk that any of this gets exposed as the property classes will all create a private class to implement the abstract methods. It can be changed at any time as it is internal. If we want to make it an interface, I'm going to need to think of a good name for it (`ListenerDataProvider`, `ListenerDataStore`, ... ) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1966230774 From jbhaskar at openjdk.org Sat Feb 22 02:51:26 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 22 Feb 2025 02:51:26 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 Message-ID: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. This patch has been tested on Jenkins and there is no side effects introduced. ------------- Commit messages: - Fix trailing white space and tab - webkit gtk cherrypick 2.46.6 Changes: https://git.openjdk.org/jfx/pull/1722/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1722&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349924 Stats: 3487 lines in 116 files changed: 1823 ins; 1316 del; 348 mod Patch: https://git.openjdk.org/jfx/pull/1722.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1722/head:pull/1722 PR: https://git.openjdk.org/jfx/pull/1722 From kcr at openjdk.org Sat Feb 22 13:47:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 22 Feb 2025 13:47:58 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 In-Reply-To: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: <107SaBYET7oz77yJlIdcUr-i8sIQUsp7VKky-4_4k5E=.fcf763d6-b0c7-44b7-84cb-743ad498c168@github.com> On Sat, 22 Feb 2025 02:31:58 GMT, Jay Bhaskar wrote: > WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. > This patch has been tested on Jenkins and there is no side effects introduced. Reviewers: @kevinrushforth @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1722#issuecomment-2676218183 From kcr at openjdk.org Sat Feb 22 14:17:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 22 Feb 2025 14:17:59 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 In-Reply-To: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: On Sat, 22 Feb 2025 02:31:58 GMT, Jay Bhaskar wrote: > WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. > This patch has been tested on Jenkins and there is no side effects introduced. I left a couple (minor) questions, but the changes look good to me. I'll test it early next week. modules/javafx.web/src/main/native/Source/JavaScriptCore/Configurations/Base.xcconfig line 1: > 1: // Copyright (C) 2009-2023 Apple Inc. All rights reserved. We don't currently have the `Source/JavaScriptCore/Configurations` directory or any of the `.xcconfig` files in our repo. I think you can revert these file additions. modules/javafx.web/src/main/native/Source/WTF/wtf/FileSystem.cpp line 534: > 532: } > 533: > 534: #if !PLATFORM(JAVA) Can you explain this change? The only way I can see that it would make sense is if all of the following are true: 1. In WebKit620.1 _prior to_ the 2.46.6 changes, neither `HAVE(STD_FILESYSTEM)` nor `HAVE(STD_EXPERIMENTAL_FILESYSTEM)` were defined in the CMake files. 2. The upstream code removed the conditional checks 3. We still need to exclude it from our port Are all three of the above statements true? ------------- PR Review: https://git.openjdk.org/jfx/pull/1722#pullrequestreview-2634808113 PR Review Comment: https://git.openjdk.org/jfx/pull/1722#discussion_r1966518897 PR Review Comment: https://git.openjdk.org/jfx/pull/1722#discussion_r1966520982 From john.hendrikx at gmail.com Sun Feb 23 15:07:54 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 23 Feb 2025 16:07:54 +0100 Subject: Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc) In-Reply-To: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> References: <7a13841d-af52-4ebb-a30f-8d3866f82285@gmail.com> Message-ID: <418bf882-443d-4f9e-a714-bd90d096bffd@gmail.com> I have a draft PR for this now. I'd appreciate some feedback, before I flesh this out completely (I'd need to add CSS documentation for example). https://github.com/openjdk/jfx/pull/1714 --John On 11/02/2025 23:47, John Hendrikx wrote: > > Hi list, > > I've done a little proof of concept where I've made some minor > modifications to CssStyleHelper to allow the CSS engine to offer > styleable properties on children, but defined by the container class. > > What this means is that we can make it appear that direct children of > a container like GridPane, HBox and VBox have properties like: > `vgrow`, `hgrow`, `column-index`, `margin`, `halignment`, `fill-width` > etc.? The exact names can be chosen by the container in question.? For > example, I could style a child of an HBox like this: > > .text-field { > > ??? -fx-background-color: yellow; > > ??? -fx-hbox-hgrow: ALWAYS; > > ??? -fx-hbox-margin: 5px; > > } > > This will make it possible to do far more visual styling directly in > CSS.? As usual, unrecognized properties are ignored, so if you put > this text field in a VBox, nothing will happen. > > How does it work? > > - Containers that wish to add additional styleable properties to their > direct descendants implement this interface: > > publicinterfaceChildStyleProvider { > > List> getChildCssMetaData(Node child); > > } > > - The CssMetaData they provide for these properties looks like this > for example: > > newCssMetaData<>("-fx-hbox-hgrow", > StyleConverter.getEnumConverter(Priority.class)) { > > @Override > > publicbooleanisSettable(Styleable styleable) { > > returntrue; > > } > > @Override > > publicStyleableProperty getStyleableProperty(Styleable > styleable) { > > returnChildStyleProvider.createProp(this, "hbox-hgrow", child); > > } > > } > > - A special StyleableProperty is created as the "receiver" of CSS > styling that will store the value in the Node#getProperties map (where > normally these values are already stored when using the static methods > like HBox.setHGrow(Node, Priority) type methods).? This property is > cached as part of the same getProperties map, so it is only created once. > > - The CssStyleHelper will see if the parent of the Node being styled > implements?ChildStyleProvider, and if so will also?process these > additional CssMetaData properties when any are present; this seems to > be fairly safe to do, as changing a Node's parent will reset all its > styling already. Some more tests are needed here, if moving this forward. > > That is basically the change in a nutshell.? Not only does setting a > property like `-fx-hbox-hgrow` on a child now act as if you called > `HBox.setHGrow`, changing the style of the child can also change these > settings and HBox will instantly respond to the change.? When the > style is completely removed, it will also?null the hgrow value which > is translated as removing that key from the Node#getProperties map. > > If people think this proposal has some merit, I can flesh it out > further and make it into a PR. > > --John > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Sun Feb 23 22:10:34 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 23 Feb 2025 22:10:34 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false Message-ID: Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. **Note**: some tests have had their values adjusted. This is because the asymmetries between the compute width/height functions have been removed. Most of these tests use the `MockBiased` test control that simulates an area of pixels that always covers the same size (ie. it is 10x1000 or 100x100 or 1000x10 = 10000). One should be aware though that when correctly querying its minimum size, it will say something like 100x100 -- and that's correct, as that's what `MockBiased` will tell the layout system, even though in a single dimension it can return a minimum size of 1 when the other dimension provided is set to say 10000. Due to a bug in how content bias was handled before in the height functions (content bias was taken into account when `-1` was passed which is incorrect) some tests saw much smaller minimum sizes. `HBoxTest` is an example of this, but if you compare it to the equivalent code in `VBoxTest`, you can see that something is clearly off, as the tests don't agree even though they mirror each other. The original developer tried to rationalize these differences, instead of investigating where they came from. It may be worth to add tests for a different type of biased control. `MockBiased` is an example of a control that requires roughly the same area when resized (like a reflowing Label, or a FlowPane). Another example is a control that tries to maintain a fixed aspect ratio, like a scaling Image. The latter type is not interested in maintaining an area of roughly the same size, but instead it is interested in maintaining a fixed factor between its width and height. **Note 2**: Many layout containers will call min/pref/max width/height methods with a dependent size provided (instead of -1) even when the control has no content bias. Control implementations therefore need to be careful not to use this value when they have no bias or have the opposite bias. `MockBiased` handles this correctly. **BorderPaneTest** BorderPaneTest has had some tests adjusted as its height computations were affected by the bug in the compute height functions where a biased calculation was partially executed when it shouldn't have. The height values make much more sense now instead of being some weird fractional number when a biased control is involved. I've adjusted the tests accordingly, and tried adding some rationalization of how the values are reached. Note that `BorderPane` (apparently) always adjusts whatever size it is given during layout to be greater than its minimum size; this is the first time I've seen containers do that, instead of going with whatever they've been given... ------------- Commit messages: - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter Changes: https://git.openjdk.org/jfx/pull/1723/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350149 Stats: 989 lines in 12 files changed: 815 ins; 49 del; 125 mod Patch: https://git.openjdk.org/jfx/pull/1723.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1723/head:pull/1723 PR: https://git.openjdk.org/jfx/pull/1723 From jbhaskar at openjdk.org Mon Feb 24 06:16:00 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 24 Feb 2025 06:16:00 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 In-Reply-To: References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: On Sat, 22 Feb 2025 13:48:06 GMT, Kevin Rushforth wrote: >> WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. >> This patch has been tested on Jenkins and there is no side effects introduced. > > modules/javafx.web/src/main/native/Source/JavaScriptCore/Configurations/Base.xcconfig line 1: > >> 1: // Copyright (C) 2009-2023 Apple Inc. All rights reserved. > > We don't currently have the `Source/JavaScriptCore/Configurations` directory or any of the `.xcconfig` files in our repo. I think you can revert these file additions. Yes , agree ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1722#discussion_r1967081075 From jbhaskar at openjdk.org Mon Feb 24 06:49:13 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 24 Feb 2025 06:49:13 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 [v2] In-Reply-To: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: > WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. > This patch has been tested on Jenkins and there is no side effects introduced. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove Configurations folder becuase it is not required ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1722/files - new: https://git.openjdk.org/jfx/pull/1722/files/c14365f1..3b4a5f86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1722&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1722&range=00-01 Stats: 554 lines in 8 files changed: 0 ins; 554 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1722.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1722/head:pull/1722 PR: https://git.openjdk.org/jfx/pull/1722 From sykora at openjdk.org Mon Feb 24 13:24:59 2025 From: sykora at openjdk.org (Joeri Sykora) Date: Mon, 24 Feb 2025 13:24:59 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 [v2] In-Reply-To: References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: On Mon, 24 Feb 2025 06:49:13 GMT, Jay Bhaskar wrote: >> WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. >> This patch has been tested on Jenkins and there is no side effects introduced. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove Configurations folder becuase it is not required All builds went fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1722#pullrequestreview-2637074746 From arapte at openjdk.org Mon Feb 24 13:51:59 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 24 Feb 2025 13:51:59 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 [v2] In-Reply-To: References: Message-ID: > Update copyright year in files updated in the year 2025. Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: - cp year 2025/2024 - Revert "8349472: Update copyright header for files modified in 2025" This reverts commit b3e0486cc8ad514933804673edf66aacd66fd166. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1721/files - new: https://git.openjdk.org/jfx/pull/1721/files/b3e0486c..90644350 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1721&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1721&range=00-01 Stats: 40 lines in 40 files changed: 0 ins; 0 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1721.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1721/head:pull/1721 PR: https://git.openjdk.org/jfx/pull/1721 From arapte at openjdk.org Mon Feb 24 13:57:03 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 24 Feb 2025 13:57:03 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: <_XiwtX2VzacUIFKv2kOXwYHlh82PYYgaXo5kkK4fDtw=.f6d79358-b8e6-4528-a77a-b40c806fa16c@github.com> On Fri, 21 Feb 2025 18:24:49 GMT, Kevin Rushforth wrote: > And we need to make sure that for those 5 commits, all of the files touched have (at least) a 2024 date as the last modified year. > > @arapte will update. Thank you Kevin, Please review the updated files. As you guided, the files modified in those 5 commits should have 2024 as modified year. Only 2 files needed to be updated for that, rest were correctly updated to 2024 in the original PR itself. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/shape/TextHelper.java modules/javafx.graphics/src/main/native-glass/win/GlassApplication.h Created a new issue for above record : [JDK-8350561](https://bugs.openjdk.org/browse/JDK-8350561) All other files have 2025 as modified year. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1721#issuecomment-2678484404 From kcr at openjdk.org Mon Feb 24 15:09:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Feb 2025 15:09:59 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: <43Y8aUYbYJDkZqJzxHVoH_-bsi3vIdQtEizVBtoM08g=.7f9ccf1c-abe2-4f6c-8942-3d4ec98aba35@github.com> On Wed, 19 Feb 2025 20:39:19 GMT, Andy Goryachev wrote: > - enforced fx application thread > - added a headful test `TestThreadingRestrictions` > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 Reviewers: @kevinrushforth @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2678740549 From snazarki at openjdk.org Mon Feb 24 16:57:38 2025 From: snazarki at openjdk.org (Sergey Nazarkin) Date: Mon, 24 Feb 2025 16:57:38 GMT Subject: [jfx21u] RFR: 8346228: Update GStreamer to 1.24.10 Message-ID: 8346228: Update GStreamer to 1.24.10 ------------- Commit messages: - Backport 22035dec470756e03d254aa12c088876ae20497d Changes: https://git.openjdk.org/jfx21u/pull/89/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=89&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/jfx21u/pull/89.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/89/head:pull/89 PR: https://git.openjdk.org/jfx21u/pull/89 From angorya at openjdk.org Mon Feb 24 17:14:03 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Feb 2025 17:14:03 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 15:57:28 GMT, John Hendrikx wrote: > Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. > > The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). > > With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: > > Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: > > 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). > 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. > 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. > > All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. > > **Note**: some tests have had their values adjusted. This is becaus... you probably want to start off a new PR from the latest master... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2679132073 From angorya at openjdk.org Mon Feb 24 17:59:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Feb 2025 17:59:06 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 15:57:28 GMT, John Hendrikx wrote: > Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. > > The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). > > With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: > > Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: > > 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). > 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. > 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. > > All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. > > **Note**: some tests have had their values adjusted. This is becaus... Not a finished review, only a few initial comments - I need to do a bit more testing. This change however looks exceptionally good. modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 1450: > 1448: int start = getNodeRowIndex(child); > 1449: int end = getNodeRowEndConvertRemaining(child); > 1450: double childPrefAreaHeight = computeChildPrefAreaHeight( thank you for fixing the indentation! much more readable now. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2020: > 2018: double baseline = child.getBaselineOffset(); > 2019: if (child.isResizable() && baseline == BASELINE_OFFSET_SAME_AS_HEIGHT) { > 2020: return top + snapSizeY(boundedSize(child.minHeight(alt), max, Double.MAX_VALUE)) + bottom here and elsewhere: a wise man once said that the sum of snapped values may not come out snapped. Should we start snapping the result of any algebraic operation that involves snapped values? modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2044: > 2042: * # content width/heights: > 2043: * > 2044: * The space allocated to a child, minus its margins. These are never -1. or always `> 0.0` ? modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2049: > 2047: * > 2048: * The space allocated to a child, minus its margins, adjusted according to > 2049: * its constraints (min <= X <= max). These are never -1. always `> 0.0` here? modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2093: > 2091: double right = margin != null ? snapSpaceX(margin.getRight(), snap) : 0; > 2092: > 2093: return width - left - right; snap? modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1025: > 1023: */ > 1024: > 1025: assertEquals(12, RegionShim.computeChildMinAreaWidth(pane, c2, -1, new Insets(1), -1, false), 1e-100); might as well declare a static `computeChildMinAreaWidth()` which delegates to `RegionShim.computeChildMinAreaWidth`... ------------- PR Review: https://git.openjdk.org/jfx/pull/1723#pullrequestreview-2637850093 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968064369 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968088719 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968091482 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968104020 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968090525 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968114907 From jhendrikx at openjdk.org Mon Feb 24 20:30:17 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Feb 2025 20:30:17 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: > Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. > > The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). > > With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: > > Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: > > 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). > 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. > 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. > > All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. > > **Note**: some tests have had their values adjusted. This is becaus... John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1723/files - new: https://git.openjdk.org/jfx/pull/1723/files/33500bab..b55c20e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=00-01 Stats: 779078 lines in 8295 files changed: 648376 ins; 72616 del; 58086 mod Patch: https://git.openjdk.org/jfx/pull/1723.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1723/head:pull/1723 PR: https://git.openjdk.org/jfx/pull/1723 From jhendrikx at openjdk.org Mon Feb 24 20:45:15 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 24 Feb 2025 20:45:15 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 17:19:58 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix >> - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2020: > >> 2018: double baseline = child.getBaselineOffset(); >> 2019: if (child.isResizable() && baseline == BASELINE_OFFSET_SAME_AS_HEIGHT) { >> 2020: return top + snapSizeY(boundedSize(child.minHeight(alt), max, Double.MAX_VALUE)) + bottom > > here and elsewhere: a wise man once said that the sum of snapped values may not come out snapped. Should we start snapping the result of any algebraic operation that involves snapped values? LOL, I think I may have said that :) However, perhaps the problem is not as bad as I made it out to be. It's definitely true that any operation on a floating point value may slightly nudge it away from a true snapped value (somewhere in the 10th decimal place) and that this problem gets worse the more operations you perform (ie. a HBox with 10.000 children will have a worse error than one with only a few children). But there may be some middle ground possible here. As long as our layout containers are aware that values returned from `computeMinWidth` etc are only "near" snapped (meaning that if you round them to the nearest pixel, you'll always get the right result), it should be fine -- one must take care not to immediately call `ceil` or `floor` on these values. A thing we may want to look into is how this is rendered on screen by the rendering layer; does the rendering do additional work when values are near snapped, or do they perform some rounding already anyway. I certainly never noticed these small errors resulting in display artifacts. In any case, this is probably better addressed in a separate effort, and we should probably write some guidelines first. I'm hoping to do some of this with the space distributor PR. > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2044: > >> 2042: * # content width/heights: >> 2043: * >> 2044: * The space allocated to a child, minus its margins. These are never -1. > > or always `> 0.0` ? Yeah, or possibly zero included. What I meant here is that these are **real** values, and don't have a "special" value `-1` meaning absent/unavailable. > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1025: > >> 1023: */ >> 1024: >> 1025: assertEquals(12, RegionShim.computeChildMinAreaWidth(pane, c2, -1, new Insets(1), -1, false), 1e-100); > > might as well declare a static `computeChildMinAreaWidth()` which delegates to `RegionShim.computeChildMinAreaWidth`... Yeah, I can streamline this a bit more. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968386958 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968389924 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968390974 From angorya at openjdk.org Mon Feb 24 20:50:55 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Feb 2025 20:50:55 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:39:01 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2020: >> >>> 2018: double baseline = child.getBaselineOffset(); >>> 2019: if (child.isResizable() && baseline == BASELINE_OFFSET_SAME_AS_HEIGHT) { >>> 2020: return top + snapSizeY(boundedSize(child.minHeight(alt), max, Double.MAX_VALUE)) + bottom >> >> here and elsewhere: a wise man once said that the sum of snapped values may not come out snapped. Should we start snapping the result of any algebraic operation that involves snapped values? > > LOL, I think I may have said that :) However, perhaps the problem is not as bad as I made it out to be. It's definitely true that any operation on a floating point value may slightly nudge it away from a true snapped value (somewhere in the 10th decimal place) and that this problem gets worse the more operations you perform (ie. a HBox with 10.000 children will have a worse error than one with only a few children). > > But there may be some middle ground possible here. As long as our layout containers are aware that values returned from `computeMinWidth` etc are only "near" snapped (meaning that if you round them to the nearest pixel, you'll always get the right result), it should be fine -- one must take care not to immediately call `ceil` or `floor` on these values. A thing we may want to look into is how this is rendered on screen by the rendering layer; does the rendering do additional work when values are near snapped, or do they perform some rounding already anyway. I certainly never noticed these small errors resulting in display artifacts. > > In any case, this is probably better addressed in a separate effort, and we should probably write some guidelines first. I'm hoping to do some of this with the space distributor PR. In theory, all these calculations end up being used by the layoutChildren() which always (?) snap the values. So the question is whether this small error gets accumulated enough to shift the result to a wrong value. Given a typical number of children (<1000) and screen sizes (<10000), we might conclude that it's unlikely, since `Math.ulp(1000 * 10_000.0) = 1.862645149230957E-9` which is much smaller than the distance between pixels even at 1000% scale. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968398142 From kcr at openjdk.org Mon Feb 24 20:53:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Feb 2025 20:53:59 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 13:51:59 GMT, Ambarish Rapte wrote: >> Update copyright year in files updated in the year 2025. > > Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: > > - cp year 2025/2024 > - Revert "8349472: Update copyright header for files modified in 2025" > > This reverts commit b3e0486cc8ad514933804673edf66aacd66fd166. Looks good. I verified that the files _only_ modified by the four commits listed are correctly reverted, and that of those, the two files that did not already have a 2024 copyright year now do. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1721#pullrequestreview-2638412894 From angorya at openjdk.org Mon Feb 24 20:57:02 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Feb 2025 20:57:02 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: <0eIPzURMVNBvbyv7cQ_Ag6n9GNWhTbBGaCtoaMrBfs8=.f3ab2a5a-089c-4f36-8fb7-599506c28dd0@github.com> On Mon, 24 Feb 2025 20:41:29 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2044: >> >>> 2042: * # content width/heights: >>> 2043: * >>> 2044: * The space allocated to a child, minus its margins. These are never -1. >> >> or always `> 0.0` ? > > Yeah, or possibly zero included. What I meant here is that these are **real** values, and don't have a "special" value `-1` meaning absent/unavailable. A _very quick_ test with the monkey tester showed it never entered `boundedSize()` with zero values, but I can't be sure (I've seen 0's in `layoutChildren()`). The statement about "never -1" is even more suspect below when margins are subtracted... I just wanted to point this out because I am not entirely sure that we'll never receive 0 width/height. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968404397 From angorya at openjdk.org Mon Feb 24 20:58:12 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Feb 2025 20:58:12 GMT Subject: RFR: 8349472: Update copyright header for files modified in 2025 [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 13:51:59 GMT, Ambarish Rapte wrote: >> Update copyright year in files updated in the year 2025. > > Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: > > - cp year 2025/2024 > - Revert "8349472: Update copyright header for files modified in 2025" > > This reverts commit b3e0486cc8ad514933804673edf66aacd66fd166. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1721#pullrequestreview-2638418583 From angorya at openjdk.org Mon Feb 24 23:08:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Feb 2025 23:08:00 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:30:17 GMT, John Hendrikx wrote: >> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. >> >> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). >> >> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: >> >> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: >> >> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). >> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. >> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. >> >> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. >> >> **Note**: some tests have had their va... > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix > - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter FYI: To help with testing, I've added some containers to the monkey tester: https://github.com/andy-goryachev-oracle/MonkeyTest (AnchorPane, BorderPane, FlowPane) and added more options to the HBox/VBox page and add child function and the childrens' context menus. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2679883002 From arapte at openjdk.org Tue Feb 25 00:29:07 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 25 Feb 2025 00:29:07 GMT Subject: Integrated: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: <5K3qjAqZoiBADzbBT2aQhiOP6Cm5YZK6JQzFmVEmR48=.edd5e2f1-2428-442d-9c07-ce1814609ba7@github.com> On Fri, 21 Feb 2025 17:39:03 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2025. This pull request has now been integrated. Changeset: 0555fb25 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67 Stats: 134 lines in 134 files changed: 0 ins; 0 del; 134 mod 8349472: Update copyright header for files modified in 2025 8350561: Update copyright header for files modified in 2024 Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1721 From kcr at openjdk.org Tue Feb 25 00:41:05 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 00:41:05 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v4] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Thu, 20 Feb 2025 23:04:15 GMT, Andy Goryachev wrote: >> Root Cause: >> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. >> >> I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. >> >> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. >> >> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. >> >> With this change, it is safe to create and populate charts with data in a background thread. >> >> --- >> >> ## NOTES >> >> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. >> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - enabled pie chart test > - Merge branch 'master' into 8349091.charts.thread.safety > - Merge branch 'master' into 8349091.charts.thread.safety > - whitespace > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - cleanup > - tests pass > - chart tests only > - more jitter > - ... and 12 more: https://git.openjdk.org/jfx/compare/307e3087...e60c027b This is heading in the right direction, but has some bugs that will need to be fixed. modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 546: > 544: symbol.setAccessibleRole(AccessibleRole.TEXT); > 545: symbol.setAccessibleRoleDescription("Point"); > 546: symbol.setFocusTraversable(isAccessibilityActive()); It looks like you are mixing the setting up of the listeners with setting the focus traversable of this symbol to the current state of accessibilityActive, which will be `Platform.accessibilityActiveProperty` for the FX app thread) and "false" (for background thread. As a result, this method, which is called once per symbol, will set up a new listener each time it is called. You might consider refactoring this a bit to only ever set up the listeners when the object is constructed. Either that or ensure that you guard against repeatedly recreating the listener. modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 536: > 534: */ > 535: // package protected: custom charts must handle accessbility on their own > 536: boolean isAccessibilityActive() { This can be final, although as I mentioned in an earlier comment, it could probably use to be refactored. modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 551: > 549: ChangeListener li = new ChangeListener<>() { > 550: @Override > 551: public void changed(ObservableValue src, Scene prev, Scene scene) { This is insufficient. It will miss the case where both the node and the scene are created in the background thread, and the scene is later added to a window on the FX app thread. I tested this case and verified my assertion. This also means that in some cases, if this listener is called from a background thread, you will create a new scene listener from the current scene listener. Consider instead using `TreeShowingProperty`, which is used by `ProgressIndicatorSkin` to set up its animation.`TreeShowingProperty` sets up a listener chain that fires when the the "tree showing" status of a node changed (tree showing means the node and all ancestors are visible and is attached to a scene that is attached to a window that is showing. Alternatively, since you might not care whether the node is visible, you can just set up a binding using `ObservableValue::flatMap`. The code snippet of the docs: ObservableValue isShowing = sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false); And then you can then add a listener (or a value subscription might be better) on `isShowing` -- when it becomes true, you can setup the binding or listener to `Platform.accessibilityActiveProperty`. With either of the above two solutions, the showing state will only become true on the FX app thread. ------------- PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2634906931 PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1968581638 PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1968583768 PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1968591700 From kcr at openjdk.org Tue Feb 25 00:41:05 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 00:41:05 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: <47o-NdybeK2ARCfUvT5mjQQFWlI_RocBRXRRbR6Tyq0=.ecabaf73-beb6-4519-93b9-1a45a00ef217@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> <47o-NdybeK2ARCfUvT5mjQQFWlI_RocBRXRRbR6Tyq0=.ecabaf73-beb6-4519-93b9-1a45a00ef217@github.com> Message-ID: On Mon, 10 Feb 2025 18:41:07 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 186: >> >>> 184: accessChart(c); >>> 185: c.getData().setAll(createNumberSeries()); >>> 186: c.getData().setAll(createNumberSeries()); >> >> Just curious - why do we do setAll twice in all the tests? > > good question! this code exercises both remove and add code paths. Maybe add a comment then? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1966536274 From kcr at openjdk.org Tue Feb 25 00:45:01 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 00:45:01 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:30:17 GMT, John Hendrikx wrote: >> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. >> >> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). >> >> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: >> >> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: >> >> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). >> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. >> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. >> >> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. >> >> **Note**: some tests have had their va... > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix > - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter I'll review this too. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2680046722 From kcr at openjdk.org Tue Feb 25 01:07:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 01:07:56 GMT Subject: RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 [v2] In-Reply-To: References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: On Mon, 24 Feb 2025 06:49:13 GMT, Jay Bhaskar wrote: >> WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. >> This patch has been tested on Jenkins and there is no side effects introduced. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove Configurations folder becuase it is not required All good from my end. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1722#pullrequestreview-2638845693 From jbhaskar at openjdk.org Tue Feb 25 05:45:04 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 25 Feb 2025 05:45:04 GMT Subject: Integrated: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 In-Reply-To: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> References: <_45LUDioPYvM3Wj3X5TQGPYRH-nE-ntanVxXKPmlvXw=.50866c59-61b6-4a15-8e1a-a38fb2d62eb4@github.com> Message-ID: On Sat, 22 Feb 2025 02:31:58 GMT, Jay Bhaskar wrote: > WebkitGTK 2.46.6 has additional fixes for crash and rendering issue, the crash fix is related to Skia CPU rendering which does not apply to JavaFX Webkit. > This patch has been tested on Jenkins and there is no side effects introduced. This pull request has now been integrated. Changeset: f38ab33b Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/f38ab33b296de7b0bf5b306e4803de8c686e2a83 Stats: 2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1722 From dlemmermann at gmail.com Tue Feb 25 08:20:13 2025 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Tue, 25 Feb 2025 09:20:13 +0100 Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false In-Reply-To: References: Message-ID: <1AD62A47-0BC2-4295-89BA-9FD569EC8028@gmail.com> Thank you for detecting and fixing this issue guys. I have spent many days / weeks chasing issues related to this issue. It often came up with my custom controls and I was always assuming that it is me making a mistake. I never even considered that this might be a bug in the layout code. Dirk > Am 23.02.2025 um 23:10 schrieb John Hendrikx : > > Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. > > The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). > > With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: > > Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: > > 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). > 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. > 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. > > All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. > > **Note**: some tests have had their values adjusted. This is because the asymmetries between the compute width/height functions have been removed. Most of these tests use the `MockBiased` test control that simulates an area of pixels that always covers the same size (ie. it is 10x1000 or 100x100 or 1000x10 = 10000). One should be aware though that when correctly querying its minimum size, it will say something like 100x100 -- and that's correct, as that's what `MockBiased` will tell the layout system, even though in a single dimension it can return a minimum size of 1 when the other dimension provided is set to say 10000. > > Due to a bug in how content bias was handled before in the height functions (content bias was taken into account when `-1` was passed which is incorrect) some tests saw much smaller minimum sizes. `HBoxTest` is an example of this, but if you compare it to the equivalent code in `VBoxTest`, you can see that something is clearly off, as the tests don't agree even though they mirror each other. The original developer tried to rationalize these differences, instead of investigating where they came from. > > It may be worth to add tests for a different type of biased control. `MockBiased` is an example of a control that requires roughly the same area when resized (like a reflowing Label, or a FlowPane). Another example is a control that tries to maintain a fixed aspect ratio, like a scaling Image. The latter type is not interested in maintaining an area of roughly the same size, but instead it is interested in maintaining a fixed factor between its width and height. > > **Note 2**: Many layout containers will call min/pref/max width/height methods with a dependent size provided (instead of -1) even when the control has no content bias. Control implementations therefore need to be careful not to use this value when they have no bias or have the opposite bias. `MockBiased` handles this correctly. > > **BorderPaneTest** > > BorderPaneTest has had some tests adjusted as its height computations were affected by the bug in the compute height functions where a biased calculation was partially executed when it shouldn't have. The height values make much more sense now instead of being some weird fractional number when a biased control is involved. I've adjusted the tests accordingly, and tried adding some rationalization of how the values are reached. Note that `BorderPane` (apparently) always adjusts whatever size it is given during layout to be greater than its minimum size; this is the first time I've seen containers do that, instead of going with whatever they've been given... > > ------------- > > Commit messages: > - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter > > Changes: https://git.openjdk.org/jfx/pull/1723/files > Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8350149 > Stats: 989 lines in 12 files changed: 815 ins; 49 del; 125 mod > Patch: https://git.openjdk.org/jfx/pull/1723.diff > Fetch: git fetch https://git.openjdk.org/jfx.git pull/1723/head:pull/1723 > > PR: https://git.openjdk.org/jfx/pull/1723 From jbhaskar at openjdk.org Tue Feb 25 09:56:35 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 25 Feb 2025 09:56:35 GMT Subject: [jfx24u] RFR: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 Message-ID: clean backport to jfx24u, the update is for cherry pick Webkitgtk-2.46.6 backport from mainline. ------------- Commit messages: - Backport f38ab33b296de7b0bf5b306e4803de8c686e2a83 Changes: https://git.openjdk.org/jfx24u/pull/9/files Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=9&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349924 Stats: 2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod Patch: https://git.openjdk.org/jfx24u/pull/9.diff Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/9/head:pull/9 PR: https://git.openjdk.org/jfx24u/pull/9 From jbhaskar at openjdk.org Tue Feb 25 13:06:05 2025 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 25 Feb 2025 13:06:05 GMT Subject: [jfx24u] Integrated: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 In-Reply-To: References: Message-ID: <_EKms0j27ta40MZHhEVg-X29h3adVxImWm5dIsCczNc=.525eaac3-c955-4bbf-abfa-a5e3e57de7ce@github.com> On Tue, 25 Feb 2025 09:51:22 GMT, Jay Bhaskar wrote: > clean backport to jfx24u, the update is for cherry pick Webkitgtk-2.46.6 backport from mainline. This pull request has now been integrated. Changeset: cdd4f2fd Author: Jay Bhaskar URL: https://git.openjdk.org/jfx24u/commit/cdd4f2fdb37d5e367f9c018eca67bfef56086a85 Stats: 2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6 Backport-of: f38ab33b296de7b0bf5b306e4803de8c686e2a83 ------------- PR: https://git.openjdk.org/jfx24u/pull/9 From oschmidtmer at openjdk.org Tue Feb 25 13:29:13 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Tue, 25 Feb 2025 13:29:13 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard Message-ID: Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. If this should be added as a unit test, I'm open for advice how to do that. ------------- Commit messages: - JDK-8281384: Random chars on paste from Windows clipboard Changes: https://git.openjdk.org/jfx/pull/1724/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8281384 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1724.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724 PR: https://git.openjdk.org/jfx/pull/1724 From kcr at openjdk.org Tue Feb 25 13:50:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 13:50:08 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer wrote: > Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. > The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. > > The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. > If this should be added as a unit test, I'm open for advice how to do that. Reviewers: @kevinrushforth @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2682037632 From kcr at openjdk.org Tue Feb 25 14:47:11 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 14:47:11 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer wrote: > Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. > The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. > > The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. > If this should be added as a unit test, I'm open for advice how to do that. I left a couple comments. As for an automated test, maybe there is something we could do with FFM, but it might be a bit of a project to figure out how to incorporate it into our test framework. modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 255: > 253: try { > 254: // JDK-8118474 - internal Windows data null terminated > 255: // JDK-8281384 - buffer might be larger than data and null terminator not at the end Minor: We generally don't include the bug ID of the bug we are fixing in a comment (and I see no need here). modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 258: > 256: int nullTerm = data.length - 2; > 257: for (int i = 0; i < data.length; i += 2) { > 258: if (data[i] == 0) { Since this is UTF-16, don't you need to check that both the even and odd bytes are 0? if (data[i] == 0 && data[i+1] == 0) { If you do this, you will want to validate that the length is even (if it isn't already ensured by `popBytes`). ------------- PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2641322865 PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969912664 PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969913328 From kcr at openjdk.org Tue Feb 25 15:08:09 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 15:08:09 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 14:36:38 GMT, Kevin Rushforth wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 255: > >> 253: try { >> 254: // JDK-8118474 - internal Windows data null terminated >> 255: // JDK-8281384 - buffer might be larger than data and null terminator not at the end > > Minor: We generally don't include the bug ID of the bug we are fixing in a comment (and I see no need here). Although, since the previous line does, I don't mind if you leave it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969968941 From oschmidtmer at openjdk.org Tue Feb 25 15:24:39 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Tue, 25 Feb 2025 15:24:39 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: > Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. > The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. > > The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. > If this should be added as a unit test, I'm open for advice how to do that. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: check both UTF16 bytes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1724/files - new: https://git.openjdk.org/jfx/pull/1724/files/c686954c..e8b8dd64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1724.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724 PR: https://git.openjdk.org/jfx/pull/1724 From oschmidtmer at openjdk.org Tue Feb 25 15:24:40 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Tue, 25 Feb 2025 15:24:40 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: <1Yq5zkLI5YHTBxvANK-SqQblbKNG78QUlEdqD4Q4Kf8=.585c6085-31d8-4185-9acb-c638b4799e49@github.com> On Tue, 25 Feb 2025 14:36:59 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: >> >> check both UTF16 bytes > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 258: > >> 256: int nullTerm = data.length - 2; >> 257: for (int i = 0; i < data.length; i += 2) { >> 258: if (data[i] == 0) { > > Since this is UTF-16, don't you need to check that both the even and odd bytes are 0? > > > if (data[i] == 0 && data[i+1] == 0) { > > > If you do this, you will want to validate that the length is even (if it isn't already ensured by `popBytes`). done and aborting loop now if there's only one byte left. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1970003043 From kcr at openjdk.org Tue Feb 25 16:11:04 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 16:11:04 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 Code changes look good. I confirm that the new tests fail without the fix and pass with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1679#pullrequestreview-2641657062 From kcr at openjdk.org Tue Feb 25 16:30:05 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 16:30:05 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 00:55:36 GMT, Michael Strau? wrote: > The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. > > The solution is to implement `SortableList.doSort()` with the following protocol: > 1. Make a copy of the list and sort it. > 2. Present the sorted list with `onProposedChange` for a potential veto. > 3. If successful, use `setAll()` to swap out the current list with the sorted list. LGTM. I left one question and will re-review if you decide to change. modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 115: > 113: modCount--; > 114: throw e; > 115: } Could this be replaced by `setAll(sortedList)`? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1674#pullrequestreview-2641703891 PR Review Comment: https://git.openjdk.org/jfx/pull/1674#discussion_r1970119348 From kcr at openjdk.org Tue Feb 25 17:03:03 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 17:03:03 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 00:55:36 GMT, Michael Strau? wrote: > The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. > > The solution is to implement `SortableList.doSort()` with the following protocol: > 1. Make a copy of the list and sort it. > 2. Present the sorted list with `onProposedChange` for a potential veto. > 3. If successful, use `setAll()` to swap out the current list with the sorted list. @andy-goryachev-oracle or @arapte Could one of you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1674#issuecomment-2682669596 From angorya at openjdk.org Tue Feb 25 17:22:18 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 17:22:18 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" In-Reply-To: References: Message-ID: <6iffHWjWtaJs2DK6XAboSvX58QeuR6Dp7Vqhg1AJXwg=.d94a5e35-23f0-4448-beca-4622fe2e725f@github.com> On Tue, 14 Jan 2025 00:55:36 GMT, Michael Strau? wrote: > The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. > > The solution is to implement `SortableList.doSort()` with the following protocol: > 1. Make a copy of the list and sort it. > 2. Present the sorted list with `onProposedChange` for a potential veto. > 3. If successful, use `setAll()` to swap out the current list with the sorted list. I'll review it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1674#issuecomment-2682721273 From angorya at openjdk.org Tue Feb 25 17:37:07 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 17:37:07 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v2] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> <959D5_XjpZWypOZ1wcSWnNCidpMue6RR39gCoZopk60=.41a8898d-cf48-4d8c-b928-441189781b03@github.com> <47o-NdybeK2ARCfUvT5mjQQFWlI_RocBRXRRbR6Tyq0=.ecabaf73-beb6-4519-93b9-1a45a00ef217@github.com> Message-ID: <40OyQUJoSrb1YilxslhzjGbf2nKp5oqvfORrezCTdak=.16c68fc9-fa70-4aa4-9a5c-784d790bfa08@github.com> On Sat, 22 Feb 2025 15:30:24 GMT, Kevin Rushforth wrote: >> good question! this code exercises both remove and add code paths. > > Maybe add a comment then? added a class-level comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1970248044 From mstrauss at openjdk.org Tue Feb 25 17:58:09 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 25 Feb 2025 17:58:09 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 4f0f992a Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/4f0f992a9801e4fa20b2e6d7d693dd4bb8c34407 Stats: 147 lines in 2 files changed: 96 ins; 5 del; 46 mod 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1679 From kcr at openjdk.org Tue Feb 25 18:09:06 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 18:09:06 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 00:08:22 GMT, Andy Goryachev wrote: > ## Added Missing Controls > > ButtonBar > ProgressIndicator > Separator > Slider, > > ## Added Node Classes > > AnchorPane > AmbientLight > Arc > BorderPane > Box > Circle > CubicCurve > Cylinder > DialogPane > DirectionalLight > Ellipse > FlowPane > GridPane > Group > HBox > ImageView > Line > MediaView > MeshView > Pane > ParallelCamera > Path > PerspectiveCamera > PointLight > Polygon > Polyline > QuadCurve > Rectangle > Region > Sphere > StackPane > SVGPath > TilePane > VBox > > > ## Miscellaneous > > - minor improvements > - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) > > > > ## Not Included Due to Threading Limitations > > HTMLEditor > MenuBar > SwingNode > WebView > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 The newly added tests look good, as do the modified tests to eliminate calling show / hide from a background thread. One more test that would be useful is one that verifies that Scene can be constructed and modified (root node changed and descendants of the root node modified / added / removed) on a background thread. I left a few questions / comments inline as well. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 224: > 222: * Also, the visible node gets accessed periodically in the FX application thread just to shake things up. > 223: */ > 224: @TestMethodOrder(MethodOrderer.MethodName.class) Why is this needed? Our tests use the JUnit5 default (which is random) without a compelling reason to do otherwise. I recommend removing it. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 227: > 225: public class NodeInitializationStressTest extends RobotTestBase { > 226: /* debugging aid: set this flag to true and comment out assumeFalse(SKIP_TEST) to run specific test(s). */ > 227: private static final boolean SKIP_TEST = false; Maybe it's time to remove this flag? Does Eclipse not provide a way to run a single test? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 328: > 326: c.setCenter(n); > 327: BorderPane.setAlignment(n, nextEnum(Pos.class)); > 328: accessNode(c); Should this call `accessRegion` instead? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 656: > 654: > 655: @Test > 656: public void imageView() { You mentioned that there was a problem with modifying a writable image on a background thread. Similarly, there might be a problem loading animated GIF images on a background thread. Is there a bug filed? tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 737: > 735: c.setFitHeight(nextDouble(200)); > 736: c.setFitWidth(nextDouble(200)); > 737: //c.setMediaPlayer(new MediaPlayer(new Media("no-data-url-support"))); Would it be useful to load a media file? If so, you could use the default media file that Ensemble uses. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1124: > 1122: } > 1123: > 1124: //@Test disabled because it times out Please file a bug and add an `@Disabled` annotation using that bug ID. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1388: > 1386: > 1387: private static void accessPane(Pane p, Consumer onChild) { > 1388: ObservableList children = p.getChildren(); It might be useful for this method to call `accessRegion` (as is done from `accessControl`). tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1423: > 1421: c.setDrawMode(nextEnum(DrawMode.class)); > 1422: PhongMaterial m = new PhongMaterial(); > 1423: //m.setSelfIlluminationMap(Image); // what is expected? There is a good description of the material properties and how they work, complete with illustrations, in the `PhongMaterial` class docs. tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1426: > 1424: m.setSpecularColor(nextColor()); > 1425: //m.setSpecularMap(Image); // what is expected? > 1426: m.setSpecularPower(nextDouble(100)); // what is the acceptable range? There is technically no upper limit, but 1.0 - 200.0 is a good range (so maybe add 1.0 to the value returned by `nextDouble`). tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1671: > 1669: > 1670: private static PathElement createPathElement() { > 1671: switch (nextInt(7)) { Minor: fix Indentation tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1755: > 1753: > 1754: private static String createSvgPath() { > 1755: switch(nextInt(4)) { Minor: space after switch ------------- PR Review: https://git.openjdk.org/jfx/pull/1713#pullrequestreview-2641843482 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970196814 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970198168 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970258183 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970231968 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970236555 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970267812 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970271244 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970276883 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970277986 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970288827 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970292234 From mstrauss at openjdk.org Tue Feb 25 18:53:48 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 25 Feb 2025 18:53:48 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" [v2] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 16:21:30 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> factor out setAll implementation > > modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 115: > >> 113: modCount--; >> 114: throw e; >> 115: } > > Could this be replaced by `setAll(sortedList)`? That would incur another unnecessary copy of the list. I've factored out the common `setAllImpl` instead to prevent these copies. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1674#discussion_r1970352937 From mstrauss at openjdk.org Tue Feb 25 18:53:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 25 Feb 2025 18:53:47 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" [v2] In-Reply-To: References: Message-ID: > The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. > > The solution is to implement `SortableList.doSort()` with the following protocol: > 1. Make a copy of the list and sort it. > 2. Present the sorted list with `onProposedChange` for a potential veto. > 3. If successful, use `setAll()` to swap out the current list with the sorted list. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: factor out setAll implementation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1674/files - new: https://git.openjdk.org/jfx/pull/1674/files/978d2dd2..d4ed2092 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1674&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1674&range=00-01 Stats: 19 lines in 1 file changed: 6 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1674.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1674/head:pull/1674 PR: https://git.openjdk.org/jfx/pull/1674 From mstrauss at openjdk.org Tue Feb 25 19:05:23 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 25 Feb 2025 19:05:23 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" [v3] In-Reply-To: References: Message-ID: > The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. > > The solution is to implement `SortableList.doSort()` with the following protocol: > 1. Make a copy of the list and sort it. > 2. Present the sorted list with `onProposedChange` for a potential veto. > 3. If successful, use `setAll()` to swap out the current list with the sorted list. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - merge - Merge branch 'master' into fixes/vetoable-list-decorator-sort # Conflicts: # modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java - factor out setAll implementation - Implement sorting for VetoableListDecorator - failing tests ------------- Changes: https://git.openjdk.org/jfx/pull/1674/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1674&range=02 Stats: 49 lines in 4 files changed: 40 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1674.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1674/head:pull/1674 PR: https://git.openjdk.org/jfx/pull/1674 From angorya at openjdk.org Tue Feb 25 19:06:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 19:06:59 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v4] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Mon, 24 Feb 2025 23:56:01 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 22 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - enabled pie chart test >> - Merge branch 'master' into 8349091.charts.thread.safety >> - Merge branch 'master' into 8349091.charts.thread.safety >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - cleanup >> - tests pass >> - chart tests only >> - more jitter >> - ... and 12 more: https://git.openjdk.org/jfx/compare/307e3087...e60c027b > > modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 551: > >> 549: ChangeListener li = new ChangeListener<>() { >> 550: @Override >> 551: public void changed(ObservableValue src, Scene prev, Scene scene) { > > This is insufficient. It will miss the case where both the node and the scene are created in the background thread, and the scene is later added to a window on the FX app thread. I tested this case and verified my assertion. This also means that in some cases, if this listener is called from a background thread, you will create a new scene listener from the current scene listener. > > Consider instead using `TreeShowingProperty`, which is used by `ProgressIndicatorSkin` to set up its animation.`TreeShowingProperty` sets up a listener chain that fires when the the "tree showing" status of a node changed (tree showing means the node and all ancestors are visible and is attached to a scene that is attached to a window that is showing. > > Alternatively, since you might not care whether the node is visible, you can just set up a binding using `ObservableValue::flatMap`. The code snippet of the docs: > > > ObservableValue isShowing = sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false); > > > And then you can then add a listener (or a value subscription might be better) on `isShowing` -- when it becomes true, you can setup the binding or listener to `Platform.accessibilityActiveProperty`. > > With either of the above two solutions, the showing state will only become true on the FX app thread. thanks for noticing! the old code was indeed flawed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1970371417 From angorya at openjdk.org Tue Feb 25 19:21:21 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 19:21:21 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v5] In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: > Root Cause: > (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. > > I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. > > Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. > > The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. > > With this change, it is safe to create and populate charts with data in a background thread. > > --- > > ## NOTES > > 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. > 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - review comments - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - enabled pie chart test - Merge branch 'master' into 8349091.charts.thread.safety - Merge branch 'master' into 8349091.charts.thread.safety - whitespace - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - cleanup - tests pass - ... and 14 more: https://git.openjdk.org/jfx/compare/f38ab33b...75d4b836 ------------- Changes: https://git.openjdk.org/jfx/pull/1697/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=04 Stats: 323 lines in 11 files changed: 184 ins; 100 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1697.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697 PR: https://git.openjdk.org/jfx/pull/1697 From angorya at openjdk.org Tue Feb 25 19:31:04 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 19:31:04 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 17:03:17 GMT, Kevin Rushforth wrote: >> ## Added Missing Controls >> >> ButtonBar >> ProgressIndicator >> Separator >> Slider, >> >> ## Added Node Classes >> >> AnchorPane >> AmbientLight >> Arc >> BorderPane >> Box >> Circle >> CubicCurve >> Cylinder >> DialogPane >> DirectionalLight >> Ellipse >> FlowPane >> GridPane >> Group >> HBox >> ImageView >> Line >> MediaView >> MeshView >> Pane >> ParallelCamera >> Path >> PerspectiveCamera >> PointLight >> Polygon >> Polyline >> QuadCurve >> Rectangle >> Region >> Sphere >> StackPane >> SVGPath >> TilePane >> VBox >> >> >> ## Miscellaneous >> >> - minor improvements >> - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) >> >> >> >> ## Not Included Due to Threading Limitations >> >> HTMLEditor >> MenuBar >> SwingNode >> WebView >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 227: > >> 225: public class NodeInitializationStressTest extends RobotTestBase { >> 226: /* debugging aid: set this flag to true and comment out assumeFalse(SKIP_TEST) to run specific test(s). */ >> 227: private static final boolean SKIP_TEST = false; > > Maybe it's time to remove this flag? Does Eclipse not provide a way to run a single test? Yes, the problem in Eclipse is that it creates a launch configuration which is always incorrect (the dependencies must be modified for each new configuration). I'd like to keep it. There is very little overhead. > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 656: > >> 654: >> 655: @Test >> 656: public void imageView() { > > You mentioned that there was a problem with modifying a writable image on a background thread. Similarly, there might be a problem loading animated GIF images on a background thread. Is there a bug filed? I guess it works as designed, see ImageView:254 Toolkit.getImageAccessor().getImageProperty(_image).addListener(platformImageChangeListener.getWeakListener()); so an animated GIF would most likely be off limits from a background thread as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970399115 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970404189 From angorya at openjdk.org Tue Feb 25 19:35:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 19:35:57 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 17:26:30 GMT, Kevin Rushforth wrote: >> ## Added Missing Controls >> >> ButtonBar >> ProgressIndicator >> Separator >> Slider, >> >> ## Added Node Classes >> >> AnchorPane >> AmbientLight >> Arc >> BorderPane >> Box >> Circle >> CubicCurve >> Cylinder >> DialogPane >> DirectionalLight >> Ellipse >> FlowPane >> GridPane >> Group >> HBox >> ImageView >> Line >> MediaView >> MeshView >> Pane >> ParallelCamera >> Path >> PerspectiveCamera >> PointLight >> Polygon >> Polyline >> QuadCurve >> Rectangle >> Region >> Sphere >> StackPane >> SVGPath >> TilePane >> VBox >> >> >> ## Miscellaneous >> >> - minor improvements >> - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) >> >> >> >> ## Not Included Due to Threading Limitations >> >> HTMLEditor >> MenuBar >> SwingNode >> WebView >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 737: > >> 735: c.setFitHeight(nextDouble(200)); >> 736: c.setFitWidth(nextDouble(200)); >> 737: //c.setMediaPlayer(new MediaPlayer(new Media("no-data-url-support"))); > > Would it be useful to load a media file? If so, you could use the default media file that Ensemble uses. I don't think we want to download media from an URL as part of this test, and data URLs are not supported by Media (and it will be too long anyway). I think we can classify this under rubric "one can only create a JavaFX object in a background thread, but not utilize it". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970413210 From angorya at openjdk.org Tue Feb 25 19:39:03 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 19:39:03 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 17:47:47 GMT, Kevin Rushforth wrote: >> ## Added Missing Controls >> >> ButtonBar >> ProgressIndicator >> Separator >> Slider, >> >> ## Added Node Classes >> >> AnchorPane >> AmbientLight >> Arc >> BorderPane >> Box >> Circle >> CubicCurve >> Cylinder >> DialogPane >> DirectionalLight >> Ellipse >> FlowPane >> GridPane >> Group >> HBox >> ImageView >> Line >> MediaView >> MeshView >> Pane >> ParallelCamera >> Path >> PerspectiveCamera >> PointLight >> Polygon >> Polyline >> QuadCurve >> Rectangle >> Region >> Sphere >> StackPane >> SVGPath >> TilePane >> VBox >> >> >> ## Miscellaneous >> >> - minor improvements >> - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) >> >> >> >> ## Not Included Due to Threading Limitations >> >> HTMLEditor >> MenuBar >> SwingNode >> WebView >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 1124: > >> 1122: } >> 1123: >> 1124: //@Test disabled because it times out > > Please file a bug and add an `@Disabled` annotation using that bug ID. Hmmm, this probably needs a completely different test. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970420966 From zjx001202 at gmail.com Tue Feb 25 19:55:41 2025 From: zjx001202 at gmail.com (Glavo) Date: Wed, 26 Feb 2025 03:55:41 +0800 Subject: What is the best way to get a high frame rate in a JavaFX application? Message-ID: Hi, Recently I was investigating how to improve the user experience of our JavaFX applications. I noticed that JavaFX applications seem to be limited to 60fps by default, which makes JavaFX applications appear to animate less smoothly than many other applications when users are using high refresh rate monitors. In particular, we used a self-drawn title bar, which caused users to drag our app more slowly than dragging other applications. I learned that there is an undocumented property `javafx.animation.fullspeed` and that setting it to true would significantly improve the user experience of our application. While it works fine on my computer, it seems to have a lot of potential problems, such as conflicts with vsync, may have significantly higher CPU/GPU utilization, and has been less tested, so I dare not push it to users. There is also a property `javafx.animation.framerate` which seems to be safer, but it didn't work for me. So, what is the best way to get a high frame rate for a JavaFX application? Can we get more than 60fps in a JavaFX application with vsync enabled? Is it possible to make JavaFX applications adapt to the monitor's refresh rate without us setting it to a fixed value? Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Feb 25 20:20:27 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 20:20:27 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes [v2] In-Reply-To: References: Message-ID: > ## Added Missing Controls > > ButtonBar > ProgressIndicator > Separator > Slider, > > ## Added Node Classes > > AnchorPane > AmbientLight > Arc > BorderPane > Box > Circle > CubicCurve > Cylinder > DialogPane > DirectionalLight > Ellipse > FlowPane > GridPane > Group > HBox > ImageView > Line > MediaView > MeshView > Pane > ParallelCamera > Path > PerspectiveCamera > PointLight > Polygon > Polyline > QuadCurve > Rectangle > Region > Sphere > StackPane > SVGPath > TilePane > VBox > > > ## Miscellaneous > > - minor improvements > - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) > > > > ## Not Included Due to Threading Limitations > > HTMLEditor > MenuBar > SwingNode > WebView > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - review comments - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 - cleanup - images - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 - media - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 - 3d - shapes - show() - ... and 4 more: https://git.openjdk.org/jfx/compare/f38ab33b...a8b892ab ------------- Changes: https://git.openjdk.org/jfx/pull/1713/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1713&range=01 Stats: 867 lines in 2 files changed: 828 ins; 13 del; 26 mod Patch: https://git.openjdk.org/jfx/pull/1713.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1713/head:pull/1713 PR: https://git.openjdk.org/jfx/pull/1713 From kcr at openjdk.org Tue Feb 25 21:21:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 21:21:58 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Wed, 19 Feb 2025 20:39:19 GMT, Andy Goryachev wrote: > - enforced fx application thread > - added a headful test `TestThreadingRestrictions` > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 The API doc changes look good, although I noted a couple additional changes that are needed. The API docs for `Dialog::hide` should also be documented to throw ISE (since it calls `close()` directly the implementation is fine) The API docs for `Stage::close` should also be documented to throw ISE (since it calls `hide()` directly the implementation is fine) For `ComboBoxBase`, were you going to get rid of the word "aspect" in the opening sentence "... display the popup aspect of the user interface."? I think that's a little awkward even with that word removed. Maybe it could just be: "... display the popup associated with this control." As for the implementation, There are a few places where the skin will call hide(), and I can't tell by just looking at the code that they are all guaranteed to be on the FX app thread. For example, I recommend checking the following: * `MenuBarSkin` line 799 * `ComboBoxListViewSkin` line 199 There may be others. tests/system/src/test/java/test/robot/javafx/scene/TestThreadingRestrictions.java line 63: > 61: * This test ensures that the threading restrictions are in place where required. > 62: */ > 63: @TestMethodOrder(MethodOrderer.MethodName.class) This is unnecessary (and not a usual practice). tests/system/src/test/java/test/robot/javafx/scene/TestThreadingRestrictions.java line 239: > 237: test(TPopupWindow::new, (p) -> p.show(stage)); > 238: test(TPopupWindow::new, (p) -> p.show(stage, 0, 0)); > 239: test(TPopupWindow::new, (p) -> p.show(contentPane, 0, 0)); It's probably worth adding a test for `hide` when it isn't showing (like you've done for other objects). tests/system/src/test/java/test/robot/javafx/scene/TestThreadingRestrictions.java line 262: > 260: p.show(); > 261: }); > 262: p.hide(); // do we need to fail early here, or only when showing? We should fail early (although this comment seems misplaced, since it is the case where it _is_ showing). tests/system/src/test/java/test/robot/javafx/scene/TestThreadingRestrictions.java line 268: > 266: > 267: @Test > 268: @Timeout(value = 1, unit = TimeUnit.DAYS) Um, 1 DAY??? Seriously, though: Remove the timeout (it isn't needed or wanted). ------------- PR Review: https://git.openjdk.org/jfx/pull/1717#pullrequestreview-2642150796 PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1970380200 PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1970398687 PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1970400883 PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1970401521 From kcr at openjdk.org Tue Feb 25 21:41:57 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 21:41:57 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes [v2] In-Reply-To: References: Message-ID: <_0ndipH3WwbZJAr1BJl6XtJxi24zcvn3LGqtNf53omQ=.f4883149-a985-4a2c-89fc-0e757c1d93c5@github.com> On Tue, 25 Feb 2025 20:20:27 GMT, Andy Goryachev wrote: >> ## Added Missing Controls >> >> ButtonBar >> ProgressIndicator >> Separator >> Slider, >> >> ## Added Node Classes >> >> AnchorPane >> AmbientLight >> Arc >> BorderPane >> Box >> Circle >> CubicCurve >> Cylinder >> DialogPane >> DirectionalLight >> Ellipse >> FlowPane >> GridPane >> Group >> HBox >> ImageView >> Line >> MediaView >> MeshView >> Pane >> ParallelCamera >> Path >> PerspectiveCamera >> PointLight >> Polygon >> Polyline >> QuadCurve >> Rectangle >> Region >> Sphere >> StackPane >> SVGPath >> TilePane >> VBox >> >> >> ## Miscellaneous >> >> - minor improvements >> - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) >> >> >> >> ## Not Included Due to Threading Limitations >> >> HTMLEditor >> MenuBar >> SwingNode >> WebView >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 > - cleanup > - images > - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 > - media > - Merge remote-tracking branch 'origin/master' into 8349750.stress.2 > - 3d > - shapes > - show() > - ... and 4 more: https://git.openjdk.org/jfx/compare/f38ab33b...a8b892ab LGTM. I think a single reviewer should be sufficient for this test fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1713#pullrequestreview-2642489943 From kcr at openjdk.org Tue Feb 25 21:41:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 21:41:58 GMT Subject: RFR: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes [v2] In-Reply-To: References: Message-ID: <6WrUrxEyjhWkgtePWuAdjQOHhYGh3rEpumMYdBAuRoQ=.8008e466-ede8-4b5c-9448-1979ae29fbcb@github.com> On Tue, 25 Feb 2025 19:25:25 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 227: >> >>> 225: public class NodeInitializationStressTest extends RobotTestBase { >>> 226: /* debugging aid: set this flag to true and comment out assumeFalse(SKIP_TEST) to run specific test(s). */ >>> 227: private static final boolean SKIP_TEST = false; >> >> Maybe it's time to remove this flag? Does Eclipse not provide a way to run a single test? > > Yes, the problem in Eclipse is that it creates a launch configuration which is always incorrect (the dependencies must be modified for each new configuration). > I'd like to keep it. There is very little overhead. OK. Given how long-running this test is I can see the value when debugging or adding / modifying tests. >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 656: >> >>> 654: >>> 655: @Test >>> 656: public void imageView() { >> >> You mentioned that there was a problem with modifying a writable image on a background thread. Similarly, there might be a problem loading animated GIF images on a background thread. Is there a bug filed? > > I guess it works as designed, see ImageView:254 > > > Toolkit.getImageAccessor().getImageProperty(_image).addListener(platformImageChangeListener.getWeakListener()); > > so an animated GIF would most likely be off limits from a background thread as well. I don't think it's intentional. See [JDK-8222211](https://bugs.openjdk.org/browse/JDK-8222211) where we fixed a problem with not being able to construct an image on a background thread. It's quite possible that the fix for JDK-8222211 is insufficient. So I think a follow-up bug is in order. A possible fix would be to defer both the animation and setting up image ChangeListener until we know that it is on the FX app thread (similar to what you did for Pagination). >> tests/system/src/test/java/test/robot/javafx/scene/NodeInitializationStressTest.java line 737: >> >>> 735: c.setFitHeight(nextDouble(200)); >>> 736: c.setFitWidth(nextDouble(200)); >>> 737: //c.setMediaPlayer(new MediaPlayer(new Media("no-data-url-support"))); >> >> Would it be useful to load a media file? If so, you could use the default media file that Ensemble uses. > > I don't think we want to download media from an URL as part of this test, and data URLs are not supported by Media (and it will be too long anyway). > > I think we can classify this under rubric "one can only create a JavaFX object in a background thread, but not utilize it". That seems reasonable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970558804 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970568328 PR Review Comment: https://git.openjdk.org/jfx/pull/1713#discussion_r1970576260 From kcr at openjdk.org Tue Feb 25 21:45:59 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Feb 2025 21:45:59 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" [v3] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 19:05:23 GMT, Michael Strau? wrote: >> The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. >> >> The solution is to implement `SortableList.doSort()` with the following protocol: >> 1. Make a copy of the list and sort it. >> 2. Present the sorted list with `onProposedChange` for a potential veto. >> 3. If successful, use `setAll()` to swap out the current list with the sorted list. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - merge > - Merge branch 'master' into fixes/vetoable-list-decorator-sort > > # Conflicts: > # modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java > - factor out setAll implementation > - Implement sorting for VetoableListDecorator > - failing tests Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1674#pullrequestreview-2642537471 From angorya at openjdk.org Tue Feb 25 22:27:08 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 22:27:08 GMT Subject: Integrated: 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 00:08:22 GMT, Andy Goryachev wrote: > ## Added Missing Controls > > ButtonBar > ProgressIndicator > Separator > Slider, > > ## Added Node Classes > > AnchorPane > AmbientLight > Arc > BorderPane > Box > Circle > CubicCurve > Cylinder > DialogPane > DirectionalLight > Ellipse > FlowPane > GridPane > Group > HBox > ImageView > Line > MediaView > MeshView > Pane > ParallelCamera > Path > PerspectiveCamera > PointLight > Polygon > Polyline > QuadCurve > Rectangle > Region > Sphere > StackPane > SVGPath > TilePane > VBox > > > ## Miscellaneous > > - minor improvements > - remove tests that execute show() in non-fx threads per [JDK-8350048](https://bugs.openjdk.org/browse/JDK-8350048) > > > > ## Not Included Due to Threading Limitations > > HTMLEditor > MenuBar > SwingNode > WebView > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 This pull request has now been integrated. Changeset: 7a7854c9 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/7a7854c947728daab6a924baa0596ccfc2df1ebb Stats: 867 lines in 2 files changed: 828 ins; 13 del; 26 mod 8349750: [TestBug] NodeInitializationStressTest: remaining Nodes Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1713 From angorya at openjdk.org Tue Feb 25 22:33:40 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Feb 2025 22:33:40 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v6] In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: > Root Cause: > (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. > > I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. > > Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. > > The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. > > With this change, it is safe to create and populate charts with data in a background thread. > > --- > > ## NOTES > > 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. > 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - review comments - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - enabled pie chart test - Merge branch 'master' into 8349091.charts.thread.safety - Merge branch 'master' into 8349091.charts.thread.safety - whitespace - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety - cleanup - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0 ------------- Changes: https://git.openjdk.org/jfx/pull/1697/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=05 Stats: 324 lines in 11 files changed: 184 ins; 101 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1697.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697 PR: https://git.openjdk.org/jfx/pull/1697 From arapte at openjdk.org Wed Feb 26 00:36:23 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 26 Feb 2025 00:36:23 GMT Subject: [jfx24] RFR: 8349472: Update copyright header for files modified in 2025 Message-ID: Update copyright year for jfx24 release. ------------- Commit messages: - cp year 2024 - update cp year 2025 Changes: https://git.openjdk.org/jfx/pull/1725/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1725&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349472 Stats: 65 lines in 65 files changed: 0 ins; 0 del; 65 mod Patch: https://git.openjdk.org/jfx/pull/1725.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1725/head:pull/1725 PR: https://git.openjdk.org/jfx/pull/1725 From kizune at openjdk.org Wed Feb 26 11:30:50 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 26 Feb 2025 11:30:50 GMT Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v7] In-Reply-To: References: Message-ID: > Create implementation for Slider and Stepper accessibility protocols. > Fix mapping. > Fix performAction parameter type in declaration. Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Add accessibilityTitleUIElement function to the base class. - Merge branch 'master' into JDK-8313556 - Merge pull request #13 from openjdk/master Merge - Merge pull request #12 from openjdk/master Merge - Merge pull request #11 from openjdk/master Merge - Merge pull request #10 from openjdk/master Merge - Adding accessibilityMinValue and accessibilityMaxValue - Merge remote-tracking branch 'origin/master' into JDK-8313556 - Merge pull request #7 from openjdk/master Merge - - Added accessibilityTitle method - Removed some debug output generation - ... and 4 more: https://git.openjdk.org/jfx/compare/7a7854c9...09f68099 ------------- Changes: https://git.openjdk.org/jfx/pull/1226/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=06 Stats: 277 lines in 6 files changed: 276 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1226.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1226/head:pull/1226 PR: https://git.openjdk.org/jfx/pull/1226 From kcr at openjdk.org Wed Feb 26 12:39:11 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 12:39:11 GMT Subject: [jfx24] RFR: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 00:32:02 GMT, Ambarish Rapte wrote: > Update copyright year for jfx24 release. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1725#pullrequestreview-2644327282 From arapte at openjdk.org Wed Feb 26 12:43:04 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 26 Feb 2025 12:43:04 GMT Subject: [jfx24] Integrated: 8349472: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 00:32:02 GMT, Ambarish Rapte wrote: > Update copyright year for jfx24 release. This pull request has now been integrated. Changeset: ca0f3806 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/ca0f3806bb8ab0b210fad262fdc5d900301b88bd Stats: 65 lines in 65 files changed: 0 ins; 0 del; 65 mod 8349472: Update copyright header for files modified in 2025 8350561: Update copyright header for files modified in 2024 Reviewed-by: kcr Backport-of: 0555fb25a16b6b6705a42c6d8592cf1c6ddccc67 ------------- PR: https://git.openjdk.org/jfx/pull/1725 From kcr at openjdk.org Wed Feb 26 12:46:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 12:46:08 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: <1Yq5zkLI5YHTBxvANK-SqQblbKNG78QUlEdqD4Q4Kf8=.585c6085-31d8-4185-9acb-c638b4799e49@github.com> References: <1Yq5zkLI5YHTBxvANK-SqQblbKNG78QUlEdqD4Q4Kf8=.585c6085-31d8-4185-9acb-c638b4799e49@github.com> Message-ID: On Tue, 25 Feb 2025 15:21:22 GMT, Oliver Schmidtmer wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 258: >> >>> 256: int nullTerm = data.length - 2; >>> 257: for (int i = 0; i < data.length; i += 2) { >>> 258: if (data[i] == 0) { >> >> Since this is UTF-16, don't you need to check that both the even and odd bytes are 0? >> >> >> if (data[i] == 0 && data[i+1] == 0) { >> >> >> If you do this, you will want to validate that the length is even (if it isn't already ensured by `popBytes`). > > done and aborting loop now if there's only one byte left. Looks good now. I'll test and then finish my review. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1971521731 From kcr at openjdk.org Wed Feb 26 13:25:07 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 13:25:07 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > check both UTF16 bytes @Schmidor I can't reproduce the original bug on Windows 11. Back when I did reproduce it, I was running Windows 10, so Microsoft might have fixed something on their end. I'll try to find a Windows 10 system to verify the fix on, but it looks like a good fix nonetheless. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2684945424 From lkostyra at openjdk.org Wed Feb 26 14:40:15 2025 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 26 Feb 2025 14:40:15 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > check both UTF16 bytes So far this change looks good, I could reproduce it with attached `ClipboardTest` program and `HelloTextArea` on my Windows 11 machine. After the fix it's no longer an issue and the contents are as expected. Tests also did not show any regressions. I do, however, have one question. I kind of wish we got correct information about how big Clipboard contents are from Windows API, and I'm kind of surprised it only gives us buffer size information and not actual content information. Are you sure we shouldn't fetch this information from Windows API somewhere instead of manually searching for a null terminator? ------------- PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2644740561 From kcr at openjdk.org Wed Feb 26 15:42:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 15:42:08 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: <5TLb6lWjkkYLnfqk7S-iVHByjgn-JlAKxCVc-vnkWoM=.f5ab0c09-488e-4e49-8113-d85d03b2f037@github.com> On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > check both UTF16 bytes That's a good question. If Windows does provide the information, then it would be best to use it. If not, maybe it would be better to move this check in the native code anyway, so that the Java code could just use the returned byte array? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2685441855 From kcr at openjdk.org Wed Feb 26 15:45:12 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 15:45:12 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: <9cjWtSYi43eoOgOBKOW09w2vsx2LASJ6Lf96f-vdZFE=.61f307ea-edb4-4064-9542-5b4a86f7a79e@github.com> On Wed, 26 Feb 2025 13:22:16 GMT, Kevin Rushforth wrote: > I can't reproduce the original bug on Windows 11. Actually, I didn't run the test correctly earlier. I can reproduce it locally, so I'll be able to verify the fix (once we resolve the outstanding questions). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2685450520 From jhendrikx at openjdk.org Wed Feb 26 16:24:07 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 26 Feb 2025 16:24:07 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > check both UTF16 bytes How about fixing this in https://github.com/openjdk/jfx/blob/7a7854c947728daab6a924baa0596ccfc2df1ebb/modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp#L383 ? It already includes special handling for `CF_DROP`, and you could add special handling for text/unicode: if (CF_TEXT == cf || CF_UNICODETEXT == cf) { ... } I also checked, it seems that Windows does not provide a way to determine the content length. For (unicode) text it indeed relyings on nul terminators. Main advantage is that it allocates the Java byte array in this function, and it could allocate it of the correct size immediately. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2685552330 From kcr at openjdk.org Wed Feb 26 17:07:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 17:07:56 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v2] In-Reply-To: References: Message-ID: <4kw_f6crQRslmINU9PsSHP1WBhrhVGPQRPpC77DfEC8=.cb3530b8-6ad1-4f62-a6a6-c06783e9b44e@github.com> On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > check both UTF16 bytes That's a good idea, and is along the lines of what I was thinking when I mentioned moving this check into the native code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2685674912 From zjx001202 at gmail.com Wed Feb 26 18:00:29 2025 From: zjx001202 at gmail.com (Glavo) Date: Thu, 27 Feb 2025 02:00:29 +0800 Subject: What is the best way to get a high frame rate in a JavaFX application? In-Reply-To: References: Message-ID: I found that setting `javafx.animation.pulse` to a higher value worked for me. I considered setting `javafx.animation.pulse` to 120 for all users to get smooth animation. Is this the most recommended approach at this time? Glavo On Wed, Feb 26, 2025 at 3:55?AM Glavo wrote: > Hi, > > Recently I was investigating how to improve the user experience of our > JavaFX applications. > I noticed that JavaFX applications seem to be limited to 60fps by default, > which makes JavaFX applications appear to animate less smoothly than many > other applications > when users are using high refresh rate monitors. > In particular, we used a self-drawn title bar, which caused users to drag > our app more slowly than dragging other applications. > > I learned that there is an undocumented property > `javafx.animation.fullspeed` > and that setting it to true would significantly improve the user > experience of our application. > While it works fine on my computer, it seems to have a lot of potential > problems, > such as conflicts with vsync, may have significantly higher CPU/GPU > utilization, and has been less tested, > so I dare not push it to users. > There is also a property `javafx.animation.framerate` which seems to be > safer, but it didn't work for me. > > So, what is the best way to get a high frame rate for a JavaFX application? > Can we get more than 60fps in a JavaFX application with vsync enabled? > Is it possible to make JavaFX applications adapt to the monitor's refresh > rate without us setting it to a fixed value? > > Glavo > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oschmidtmer at openjdk.org Wed Feb 26 18:14:53 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Wed, 26 Feb 2025 18:14:53 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v3] In-Reply-To: References: Message-ID: > Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. > The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. > > The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. > If this should be added as a unit test, I'm open for advice how to do that. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: search NUL terminator in native code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1724/files - new: https://git.openjdk.org/jfx/pull/1724/files/e8b8dd64..57dcbedc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=01-02 Stats: 18 lines in 2 files changed: 8 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1724.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724 PR: https://git.openjdk.org/jfx/pull/1724 From johan.vos at gluonhq.com Wed Feb 26 18:17:31 2025 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 26 Feb 2025 19:17:31 +0100 Subject: What is the best way to get a high frame rate in a JavaFX application? In-Reply-To: References: Message-ID: Hi Glavo, I believe setting the javafx.animation.pulse is indeed the best way to increase the render frequency (or to minimize the time between 2 pulses). It is independent of the hardware/pipeline being used. Of course, you may see a higher load in the JavaFX Application Thread and in the Quantum Renderer, but I guess you're aware of that -- but even at 10 fps those threads can be under pressure (same for the GPU cache). - Johan On Wed, Feb 26, 2025 at 7:01?PM Glavo wrote: > I found that setting `javafx.animation.pulse` to a higher value worked for > me. > I considered setting `javafx.animation.pulse` to 120 for all users to get > smooth animation. > Is this the most recommended approach at this time? > > Glavo > > On Wed, Feb 26, 2025 at 3:55?AM Glavo wrote: > >> Hi, >> >> Recently I was investigating how to improve the user experience of our >> JavaFX applications. >> I noticed that JavaFX applications seem to be limited to 60fps by >> default, >> which makes JavaFX applications appear to animate less smoothly than many >> other applications >> when users are using high refresh rate monitors. >> In particular, we used a self-drawn title bar, which caused users to drag >> our app more slowly than dragging other applications. >> >> I learned that there is an undocumented property >> `javafx.animation.fullspeed` >> and that setting it to true would significantly improve the user >> experience of our application. >> While it works fine on my computer, it seems to have a lot of potential >> problems, >> such as conflicts with vsync, may have significantly higher CPU/GPU >> utilization, and has been less tested, >> so I dare not push it to users. >> There is also a property `javafx.animation.framerate` which seems to be >> safer, but it didn't work for me. >> >> So, what is the best way to get a high frame rate for a JavaFX >> application? >> Can we get more than 60fps in a JavaFX application with vsync enabled? >> Is it possible to make JavaFX applications adapt to the monitor's refresh >> rate without us setting it to a fixed value? >> >> Glavo >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From oschmidtmer at openjdk.org Wed Feb 26 18:28:28 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Wed, 26 Feb 2025 18:28:28 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4] In-Reply-To: References: Message-ID: > Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. > The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. > > The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. > If this should be added as a unit test, I'm open for advice how to do that. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1724/files - new: https://git.openjdk.org/jfx/pull/1724/files/57dcbedc..56e75dd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1724.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724 PR: https://git.openjdk.org/jfx/pull/1724 From kevin.rushforth at oracle.com Wed Feb 26 20:33:46 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Feb 2025 12:33:46 -0800 Subject: What is the best way to get a high frame rate in a JavaFX application? In-Reply-To: References: Message-ID: <989dae1a-856f-40a9-be41-6b4190dc608e@oracle.com> Yes, I think that's the best advice for now. Really, though, a good RFE would be to provide a way to adapt to the refresh rate of the monitor when vsync is being used. That's really the point of doing vsync in the first place. -- Kevin On 2/26/2025 10:17 AM, Johan Vos wrote: > Hi Glavo, > > I believe setting the javafx.animation.pulse is indeed the best way to > increase the render frequency (or to minimize the time between 2 > pulses). It is independent?of the hardware/pipeline being used. > Of course, you may see a higher load in the JavaFX Application Thread > and in the Quantum Renderer, but I guess you're aware of that -- but > even at 10 fps those threads can be under pressure (same for the GPU > cache). > > - Johan > > > On Wed, Feb 26, 2025 at 7:01?PM Glavo wrote: > > I found that setting `javafx.animation.pulse` to a higher value > worked for me. > I considered setting `javafx.animation.pulse` to 120 for all users > to get smooth animation. > Is this the most recommended approach at this time? > > Glavo > > On Wed, Feb 26, 2025 at 3:55?AM Glavo wrote: > > Hi, > > Recently I was investigating how to improve the user > experience of our JavaFX applications. > I noticed that JavaFX applications seem to be limited to 60fps > by default, > which makes JavaFX applications appear to animate less > smoothly than many other applications > when users are using high refresh rate monitors. > In particular, we used a self-drawn title bar, which caused > users to drag our app more slowly than dragging other > applications. > > I learned that there is an undocumented property > `javafx.animation.fullspeed` > and that setting it to true would significantly improve the > user experience of our application. > While it works fine on my computer, it seems to have a lot of > potential problems, > such as conflicts with vsync, may have significantly higher > CPU/GPU utilization, and has been less tested, > so I dare not push it to users. > There is also a property?`javafx.animation.framerate` which > seems to be safer, but it didn't work for me. > > So, what is the best way to get a high frame rate for a JavaFX > application? > Can we get more than 60fps in a JavaFX application with vsync > enabled? > Is it possible to make JavaFX applications adapt to the > monitor's refresh rate without us setting it to a fixed value? > > Glavo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Feb 26 21:11:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Feb 2025 21:11:58 GMT Subject: [jfx24u] RFR: 8350437: [GHA] Update gradle wrapper-validation action to v3 In-Reply-To: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> References: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> Message-ID: On Fri, 21 Feb 2025 16:37:57 GMT, Kevin Rushforth wrote: > Clean backport of GHA-only fix to jfx24u. @johanvos Can you approve this (it doesn't need review, but needs maintainer approval). ------------- PR Comment: https://git.openjdk.org/jfx24u/pull/8#issuecomment-2686202650 From angorya at openjdk.org Wed Feb 26 22:00:33 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Feb 2025 22:00:33 GMT Subject: RFR: 8347359: RichTextArea API Tests [v3] In-Reply-To: References: Message-ID: > Additional RichTextArea API tests. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests - 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 8347359.rta.api.tests - newlines - check - cleanup - clamp - ... and 11 more: https://git.openjdk.org/jfx/compare/7a7854c9...b3a60874 ------------- Changes: https://git.openjdk.org/jfx/pull/1677/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=02 Stats: 1383 lines in 10 files changed: 1323 ins; 29 del; 31 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 Feb 26 22:00:34 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Feb 2025 22:00:34 GMT Subject: RFR: 8347359: RichTextArea API Tests [v2] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 19:40:42 GMT, Andy Goryachev wrote: >> Additional RichTextArea API tests. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests > - 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 > 8347359.rta.api.tests > - newlines > - check > - cleanup > - clamp > - get text > - ... and 10 more: https://git.openjdk.org/jfx/compare/307e3087...d6e9ba3f keep-alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1677#issuecomment-2686291305 From angorya at openjdk.org Wed Feb 26 23:39:27 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Feb 2025 23:39:27 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v2] In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: > - enforced fx application thread > - added a headful test `TestThreadingRestrictions` > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 Andy Goryachev 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 remote-tracking branch 'origin/master' into 8350048.enforce - fixed node init test - all tests - initial test ------------- Changes: https://git.openjdk.org/jfx/pull/1717/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=01 Stats: 465 lines in 11 files changed: 413 ins; 28 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/1717.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717 PR: https://git.openjdk.org/jfx/pull/1717 From mstrauss at openjdk.org Thu Feb 27 03:45:03 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Feb 2025 03:45:03 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:28:28 GMT, Oliver Schmidtmer wrote: >> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. >> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > cleanup modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 406: > 404: cdata = 0; > 405: } > 406: } else if(CF_TEXT == cf || CF_UNICODETEXT == cf){ Instead of doing that, consider always requesting `CF_UNICODETEXT` from the clipboard. Windows will then convert both `CF_TEXT` and `CF_OEMTEXT` to unicode (see [Synthesized Clipboard Formats](https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats)). modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 409: > 407: for(int i = 0; i < cdata - 1; i+=2){ > 408: jbyte *pos = me.getMem() + offset + i; > 409: if(*(pos) == 0 && *(pos + 1) == 0){ 1. `offset` is always 0 here. 2. Minor: add spacing around operators and after keywords (`for`, `if`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1972777624 PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1972778132 From arapte at openjdk.org Thu Feb 27 07:47:05 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 27 Feb 2025 07:47:05 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v2] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Wed, 26 Feb 2025 23:39:27 GMT, Andy Goryachev wrote: >> - enforced fx application thread >> - added a headful test `TestThreadingRestrictions` >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > Andy Goryachev 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 remote-tracking branch 'origin/master' into 8350048.enforce > - fixed node init test > - all tests > - initial test modules/javafx.controls/src/main/java/javafx/scene/control/ChoiceBox.java line 491: > 489: setShowing(true); > 490: } > 491: } Would it be a good idea to move the check `Toolkit.getToolkit().checkFxUserThread();` to a new method `show()` in Parent class `Control`? And may be similarly to Parent classes of other classes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1973034032 From john.hendrikx at gmail.com Thu Feb 27 08:20:37 2025 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 27 Feb 2025 09:20:37 +0100 Subject: What is the best way to get a high frame rate in a JavaFX application? In-Reply-To: <989dae1a-856f-40a9-be41-6b4190dc608e@oracle.com> References: <989dae1a-856f-40a9-be41-6b4190dc608e@oracle.com> Message-ID: <13ec6e4b-f271-4ed7-bb19-068fad1bbc94@gmail.com> Some more information for Windows platform: The FX thread is woken up by the pulse mechanism, and then will pin down a time using `System.nanoTime`.? However, the wake up process on Windows can take anywhere from 1-30 milliseconds as it by default uses a 64 Hz clock for scheduling purposes.? This means that the frame time you receive for animation callbacks is wildly inaccuratel.? One way to significantly improve this (on Windows) is to have your application change the timer resolution?-- it can be set as high as 2000 Hz -- allowing threads (like the FX thread) to be scheduled much more quickly in response to a pulse.? This is however a native call (timeBeginPeriod), and is a global change for the system (it can't be done per application). On a Windows system, setting pulse to 120 Hz by itself probably will not show significant improvement as the animation calculations are likely still using badly calculated frame times, resulting in the animation to look stuttery.? One way to improve this may be to also set "-D-com.sun.scenario.animation.fixed.pulse.length=true", but I'm not entirely sure it works in conjunction with setting the pulse duration. See https://bugs.openjdk.org/browse/JDK-8339606 for more detailed information. --John On 26/02/2025 21:33, Kevin Rushforth wrote: > Yes, I think that's the best advice for now. > > Really, though, a good RFE would be to provide a way to adapt to the > refresh rate of the monitor when vsync is being used. That's really > the point of doing vsync in the first place. > > -- Kevin > > On 2/26/2025 10:17 AM, Johan Vos wrote: >> Hi Glavo, >> >> I believe setting the javafx.animation.pulse is indeed the best way >> to increase the render frequency (or to minimize the time between 2 >> pulses). It is independent?of the hardware/pipeline being used.? >> Of course, you may see a higher load in the JavaFX Application Thread >> and in the Quantum Renderer, but I guess you're aware of that -- but >> even at 10 fps those threads can be under pressure (same for the GPU >> cache). >> >> - Johan >> >> >> On Wed, Feb 26, 2025 at 7:01?PM Glavo wrote: >> >> I found that setting `javafx.animation.pulse` to a higher value >> worked for me. >> I considered setting `javafx.animation.pulse` to 120 for all >> users to get smooth animation. >> Is this the most recommended approach at this time? >> >> Glavo >> >> On Wed, Feb 26, 2025 at 3:55?AM Glavo wrote: >> >> Hi, >> >> Recently I was investigating how to improve the user >> experience of our JavaFX applications. >> I noticed that JavaFX applications seem to be limited to >> 60fps by default,? >> which makes JavaFX applications appear to animate less >> smoothly than many other applications >> when users are using high refresh rate monitors. >> In particular, we used a self-drawn title bar, which caused >> users to drag our app more slowly than dragging other >> applications. >> >> I learned that there is an undocumented property >> `javafx.animation.fullspeed`? >> and that setting it to true would significantly improve the >> user experience of our application. >> While it works fine on my computer, it seems to have a lot of >> potential problems, >> such as conflicts with vsync, may have significantly higher >> CPU/GPU utilization, and has been less tested, >> so I dare not push it to users. >> There is also a property?`javafx.animation.framerate` which >> seems to be safer, but it didn't work for me. >> >> So, what is the best way to get a high frame rate for a >> JavaFX application? >> Can we get more than 60fps in a JavaFX application with vsync >> enabled? >> Is it possible to make JavaFX applications adapt to the >> monitor's refresh rate without us setting it to a fixed value? >> >> Glavo >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Thu Feb 27 09:15:10 2025 From: jvos at openjdk.org (Johan Vos) Date: Thu, 27 Feb 2025 09:15:10 GMT Subject: [jfx24u] RFR: 8350437: [GHA] Update gradle wrapper-validation action to v3 In-Reply-To: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> References: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> Message-ID: <1qtQcBdAAzuEjJsaOlpKcvVAzc9Pi_h86QaAeaKiL9s=.13e40661-bc5e-4ce4-ab56-18720a6b514f@github.com> On Fri, 21 Feb 2025 16:37:57 GMT, Kevin Rushforth wrote: > Clean backport of GHA-only fix to jfx24u. Trivial fix, it doesn't affect code or build logic. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx24u/pull/8#pullrequestreview-2647108863 From oschmidtmer at openjdk.org Thu Feb 27 09:56:58 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Thu, 27 Feb 2025 09:56:58 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v5] In-Reply-To: References: Message-ID: > Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. > The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars. > > The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue. > If this should be added as a unit test, I'm open for advice how to do that. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: format and unneeded var removed ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1724/files - new: https://git.openjdk.org/jfx/pull/1724/files/56e75dd6..6ef3353e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1724.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724 PR: https://git.openjdk.org/jfx/pull/1724 From oschmidtmer at openjdk.org Thu Feb 27 10:02:17 2025 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Thu, 27 Feb 2025 10:02:17 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4] In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 03:40:47 GMT, Michael Strau? wrote: >> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup > > modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 406: > >> 404: cdata = 0; >> 405: } >> 406: } else if(CF_TEXT == cf || CF_UNICODETEXT == cf){ > > Instead of doing that, consider always requesting `CF_UNICODETEXT` from the clipboard. Windows will then convert both `CF_TEXT` and `CF_OEMTEXT` to unicode (see [Synthesized Clipboard Formats](https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats)). As the existing code was already pretty optimistic about 2 byte chars, is it possible that is already handled somewhere else? I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT is just tried first. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1973256648 From kcr at openjdk.org Thu Feb 27 13:51:09 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 13:51:09 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v2] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: <-IK3oLJgqe0O4BFvnPKXP1CcK37Ro44ijpGHh8WUWEQ=.f09d73b6-cf97-4eae-a159-98bed107aa90@github.com> On Thu, 27 Feb 2025 07:43:59 GMT, Ambarish Rapte 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 four commits: >> >> - Merge remote-tracking branch 'origin/master' into 8350048.enforce >> - fixed node init test >> - all tests >> - initial test > > modules/javafx.controls/src/main/java/javafx/scene/control/ChoiceBox.java line 491: > >> 489: setShowing(true); >> 490: } >> 491: } > > Would it be a good idea to move the check `Toolkit.getToolkit().checkFxUserThread();` to a new method `show()` in Parent class `Control`? And may be similarly to Parent classes of other classes. No, we don't want to add a new public `show` method to `Control` since it is only a very few controls that have the concept of showing a popup. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1973616028 From johan.vos at gluonhq.com Thu Feb 27 15:15:09 2025 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 27 Feb 2025 16:15:09 +0100 Subject: Building OpenJFX with the JDK build system Message-ID: Hi, I introduced this topic during the OpenJDK Committers' workshop in Brussels, on Feb 3, 2025. For a long time, I was thinking about building OpenJFX using the JDK buildsystem, and I just blogged about a very basic and limited POC for doing so on Linux: https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/ . The POC I have for this (linux-only at the moment) is at https://github.com/johanvos/jdk/tree/jfxpoc-blog This is just a personal idea and effort, but I would be more than happy to discuss how we as the OpenJFX developers might benefit from this. One of the main reasons for doing this (I list a number of reasons in my blog post), is the cross-compilation capability. It is also very convenient that the result of the build is now a full JDK image, including the JavaFX modules. I am aware that some companies distribute JavaFX modules with their JDK distribution, and this might help a better alignment. Since I am also the OpenJDK/Mobile project lead, I have to work with the JDK build system anyhow. To me personally, it saves a major amount of time if I only have to use 1 build system (configure/make) instead of 2 build systems. This is no criticism at all to Gradle, but I lack the expertise (and time to learn) needed to work efficiently with it. With all the projects I do, I try to be as efficient as possible with my time, and streamlining build systems helps. The JDK build system is really excellent, and since it is used by so many OpenJDK developers, it feels very familiar. The delta that is needed to have it working and support for JavaFX is very small. The POC I did is far from complete. There are a number of issues that need to be tackled, e.g.: * what about webkit? * we have a code-generator for shaders, that is using a very old external dependency. While the JDK build system has great support to generate code, I'm not sure this is the ideal approach * warnings, warnings and warnings. The last item is something that I believe should be tacklked in any case. I had to disable the warnings-as-errors, and I had to add a fair amount of exceptions to javac warnings. This might be a good time to look into this as well. Again, I want to stress that this is just an experiment I did because it would save me lots of time, and make it much easier for me to understand what is going on in builds. I absolutely do not want to imply that this is much better than what we currently have. But maybe others are interested as well, and in that case we can discuss this. - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Feb 27 15:36:10 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 15:36:10 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v2] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Tue, 25 Feb 2025 19:26:58 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 four commits: >> >> - Merge remote-tracking branch 'origin/master' into 8350048.enforce >> - fixed node init test >> - all tests >> - initial test > > tests/system/src/test/java/test/robot/javafx/scene/TestThreadingRestrictions.java line 268: > >> 266: >> 267: @Test >> 268: @Timeout(value = 1, unit = TimeUnit.DAYS) > > Um, 1 DAY??? > > Seriously, though: Remove the timeout (it isn't needed or wanted). checked in by mistake ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1973836513 From angorya at openjdk.org Thu Feb 27 15:57:07 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 15:57:07 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v3] In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: <4klz-DJIBJFB07-ub0fiM2_0t6qTJxx8fwYSP9qEqwg=.6a98877f-40e3-4c02-b1df-bad8ce808d09@github.com> > - enforced fx application thread > - added a headful test `TestThreadingRestrictions` > > ## Note to the Reviewers > > To avoid merge conflicts, the preferred order of integrations: > > #1697 > #1713 > #1717 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/1717/files - new: https://git.openjdk.org/jfx/pull/1717/files/db921097..7d8ef4e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=01-02 Stats: 13 lines in 4 files changed: 5 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1717.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717 PR: https://git.openjdk.org/jfx/pull/1717 From angorya at openjdk.org Thu Feb 27 15:57:07 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 15:57:07 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v3] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Tue, 25 Feb 2025 21:19:16 GMT, Kevin Rushforth wrote: > For example, I recommend checking the following: > MenuBarSkin line 799 > ComboBoxListViewSkin line 199 I think it should be sufficient to mention the exception in the actual methods where the check is done, such as `hide()` and `show()`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2688379991 From kcr at openjdk.org Thu Feb 27 17:43:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 17:43:40 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 Message-ID: This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). The following filter was used to produce the list of issues fixed in JavaFX 24: https://bugs.openjdk.org/issues/?filter=46704 Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). ------------- Commit messages: - Add release note for JDK-8340852 - Add JDK-8309381 to list of Enhancements - Merge branch 'master' into 8350136-release-notes-24 - Remove additional noreg-cleanup issues - Merge remote-tracking branch 'upstream/master' into 8350136-release-notes-24 - Add JDK-8340003 - 8350136: Create release notes for JavaFX 24 Changes: https://git.openjdk.org/jfx/pull/1712/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350136 Stats: 272 lines in 1 file changed: 272 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1712.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1712/head:pull/1712 PR: https://git.openjdk.org/jfx/pull/1712 From kcr at openjdk.org Thu Feb 27 17:43:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 17:43:40 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 23:15:46 GMT, Kevin Rushforth wrote: > This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). > > The following filter was used to produce the list of issues fixed in JavaFX 24: > > https://bugs.openjdk.org/issues/?filter=46704 > > Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). Reviewers: Some combination of @abhinayagarwal @johanvos @nlisker @andy-goryachev-oracle @hjohn @mstr2 Now that we are in the RC phase of the release, no further content is expected. I plan to integrate this closer to the GA date of JavaFX 24 and will then backport it to the jfx24 branch (although it will not be part of any build) so that it will live in that branch and be propagated to the jfx24u update repo. I left one inline comment about the release note for [JDK-8340852](https://bugs.openjdk.org/browse/JDK-8340852), which as noted, seems a bit long for an inline release note. I'm leaning towards moving it to a JBS comment (probably in the main bug) and providing a link to that from the release note, but I'd be interested in other opinions on this. doc-files/release-notes-24.md line 78: > 76: `ScrollPane` now only responds to key events when it is the active focus owner. This ensures that custom controls and other UI elements work correctly inside a `ScrollPane`, providing a more consistent and intuitive navigation experience. > 77: > 78: Reverting to Previous `ScrollPane` Behavior: This section describing the workaround makes this release note relatively long. As noted in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8343066?focusedId=14756771&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14756771), we might consider putting somewhere else and have the release note link to it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1712#issuecomment-2688659779 PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974047129 From angorya at openjdk.org Thu Feb 27 18:09:05 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 18:09:05 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 23:15:46 GMT, Kevin Rushforth wrote: > This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). > > The following filter was used to produce the list of issues fixed in JavaFX 24: > > https://bugs.openjdk.org/issues/?filter=46704 > > Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). doc-files/release-notes-24.md line 51: > 49: > 50: NOTE: The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the `--module-path` option instead. > 51: do you think we could also show an example here? doc-files/release-notes-24.md line 54: > 52: #### Applications using `jlink` to create a custom Java runtime image: > 53: > 54: When creating your custom Java runtime image, put the JavaFX jmods on the module path ahead of the JDK jmoods. For example: jmoods ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974080262 PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974083181 From angorya at openjdk.org Thu Feb 27 18:09:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 18:09:06 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 17:29:02 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 24: >> >> https://bugs.openjdk.org/issues/?filter=46704 >> >> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). > > doc-files/release-notes-24.md line 78: > >> 76: `ScrollPane` now only responds to key events when it is the active focus owner. This ensures that custom controls and other UI elements work correctly inside a `ScrollPane`, providing a more consistent and intuitive navigation experience. >> 77: >> 78: Reverting to Previous `ScrollPane` Behavior: > > This section describing the workaround makes this release note relatively long. As noted in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8343066?focusedId=14756771&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14756771), we might consider putting somewhere else and have the release note link to it. Though it's probably too late for jfx24, I would like to see jfx JEPs and notes like this to be a part of the jfx repo. Github rendering of .md files is pretty good and the target audience is jfx developers and users. Maybe something along the lines of `/doc-files/notes/2024/0227/JDK-8340852-ScrollPane-Consumes-Navigation-Keys` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974093888 From crschnick at xpipe.io Thu Feb 27 18:25:17 2025 From: crschnick at xpipe.io (Christopher Schnick) Date: Thu, 27 Feb 2025 19:25:17 +0100 Subject: Platform preferences changes are not properly registered on Linux Message-ID: Hello, it seems like the Platform preferences API does not properly register theme updates anymore in the latest desktop environments. In my testing, it didn't work on Gnome 47.4 and KDE Plasma 6.3.2. The color scheme is always light and no updates are registered. The accent color is also always the default one. On Gnome 46.0, when you change the dark mode setting, the GTK.theme_name is actually updated but the bgcolor and fgcolor properties are not, leading to the color scheme not being updated. But here, the properties are definitely detected correctly on initialization, it's just the updates that are not happening at runtime when something is changed. Best Christopher Schnick From angorya at openjdk.org Thu Feb 27 18:57:11 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 18:57:11 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" [v3] In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 19:05:23 GMT, Michael Strau? wrote: >> The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. >> >> The solution is to implement `SortableList.doSort()` with the following protocol: >> 1. Make a copy of the list and sort it. >> 2. Present the sorted list with `onProposedChange` for a potential veto. >> 3. If successful, use `setAll()` to swap out the current list with the sorted list. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - merge > - Merge branch 'master' into fixes/vetoable-list-decorator-sort > > # Conflicts: > # modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java > - factor out setAll implementation > - Implement sorting for VetoableListDecorator > - failing tests Marked as reviewed by angorya (Reviewer). modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 127: > 125: > 126: private boolean setAllImpl(List unmodifiableList) { > 127: onProposedChange(unmodifiableList, 0, size()); Have you thought of moving all the checks and wrapping into `setAllImpl()`? Regardless of that, the current code is good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1674#pullrequestreview-2648772428 PR Review Comment: https://git.openjdk.org/jfx/pull/1674#discussion_r1974168926 From kcr at openjdk.org Thu Feb 27 19:10:09 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 19:10:09 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 18:01:55 GMT, Andy Goryachev wrote: >> doc-files/release-notes-24.md line 78: >> >>> 76: `ScrollPane` now only responds to key events when it is the active focus owner. This ensures that custom controls and other UI elements work correctly inside a `ScrollPane`, providing a more consistent and intuitive navigation experience. >>> 77: >>> 78: Reverting to Previous `ScrollPane` Behavior: >> >> This section describing the workaround makes this release note relatively long. As noted in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8343066?focusedId=14756771&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14756771), we might consider putting somewhere else and have the release note link to it. > > Though it's probably too late for jfx24, I would like to see jfx JEPs and notes like this to be a part of the jfx repo. Github rendering of .md files is pretty good and the target audience is jfx developers and users. > > Maybe something along the lines of > > `/doc-files/notes/2024/0227/JDK-8340852-ScrollPane-Consumes-Navigation-Keys` Yes, likely too late for JavaFX 24 (at least for JEPs, which will need discussion on the mailing list). Going forward we should consider something along these lines I think. Whatever we end up doing for JEPs or notes should be organized by JavaFX release not calendar date. So maybe something like: doc-files/notes/24/JDK-8340852-info.md If we think we need a hint in the name of the file as to what the note is about (I don't think it's needed for additional release note information), then maybe: doc-files/notes/24/JDK-8340852-ScrollPane-restore-previous-behavior.md ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974186557 From kcr at openjdk.org Thu Feb 27 19:16:08 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 19:16:08 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 17:52:25 GMT, Andy Goryachev wrote: >> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 24: >> >> https://bugs.openjdk.org/issues/?filter=46704 >> >> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). > > doc-files/release-notes-24.md line 51: > >> 49: >> 50: NOTE: The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the `--module-path` option instead. >> 51: > > do you think we could also show an example here? No, I think there is enough information already for someone who chooses to run JavaFX on an older JDK. I don't want to distract with too much information that is irrelevant in the typical case. > doc-files/release-notes-24.md line 54: > >> 52: #### Applications using `jlink` to create a custom Java runtime image: >> 53: >> 54: When creating your custom Java runtime image, put the JavaFX jmods on the module path ahead of the JDK jmoods. For example: > > jmoods Ooooops. :) I'll fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974194985 PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974195666 From angorya at openjdk.org Thu Feb 27 19:25:06 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Feb 2025 19:25:06 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: Message-ID: <54jvCUubyygJYt0J1_8HtJwKRliBgnnBjOeUdYCjI8c=.388d1dd2-2599-4cd1-928a-d15184bb7f11@github.com> On Thu, 27 Feb 2025 19:07:34 GMT, Kevin Rushforth wrote: >> Though it's probably too late for jfx24, I would like to see jfx JEPs and notes like this to be a part of the jfx repo. Github rendering of .md files is pretty good and the target audience is jfx developers and users. >> >> Maybe something along the lines of >> >> `/doc-files/notes/2024/0227/JDK-8340852-ScrollPane-Consumes-Navigation-Keys` > > Yes, likely too late for JavaFX 24 (at least for JEPs, which will need discussion on the mailing list). Going forward we should consider something along these lines I think. > > Whatever we end up doing for JEPs or notes should be organized by JavaFX release not calendar date. So maybe something like: > > > doc-files/notes/24/JDK-8340852-info.md > > > If we think we need a hint in the name of the file as to what the note is about (I don't think it's needed for additional release note information), then maybe: > > > doc-files/notes/24/JDK-8340852-ScrollPane-restore-previous-behavior.md `doc-files/notes/24/JDK-8340852.md` the only problem with this is that the feature may not make it into specific release so the docs need to be moved, which will break the reviews and the mailing list. May be we can organize drafts using dates `/doc-files/drafts/2025/0227/JDK-8340852` and organize the final versions by release `/doc-files/notes/24/JDK-8340852`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974206523 From kcr at openjdk.org Thu Feb 27 19:43:07 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 19:43:07 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: <54jvCUubyygJYt0J1_8HtJwKRliBgnnBjOeUdYCjI8c=.388d1dd2-2599-4cd1-928a-d15184bb7f11@github.com> References: <54jvCUubyygJYt0J1_8HtJwKRliBgnnBjOeUdYCjI8c=.388d1dd2-2599-4cd1-928a-d15184bb7f11@github.com> Message-ID: On Thu, 27 Feb 2025 19:22:23 GMT, Andy Goryachev wrote: > `doc-files/notes/24/JDK-8340852.md` > > the only problem with this is that the feature may not make it into specific release so the docs need to be moved, which will break the reviews and the mailing list. By the time something gets into the mainline jfx repo, we know which release it is targeted to. We already have to update the `@since` tags for any in-progress reviews when the targeted release changes, and this is no different. > May be we can organize drafts using dates `/doc-files/drafts/2025/0227/JDK-8340852` and organize the final versions by release `/doc-files/notes/24/JDK-8340852`? This will never happen for additional release notes. By definition we don't even write them until they are integrated. For JEPs, maybe... _if_ we ever put Draft DEPs in our repo (I don't think we should, but let's cross that bridge when we have the JEP discussion). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974234450 From kcr at openjdk.org Thu Feb 27 19:48:03 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Feb 2025 19:48:03 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: <54jvCUubyygJYt0J1_8HtJwKRliBgnnBjOeUdYCjI8c=.388d1dd2-2599-4cd1-928a-d15184bb7f11@github.com> Message-ID: On Thu, 27 Feb 2025 19:40:18 GMT, Kevin Rushforth wrote: >> `doc-files/notes/24/JDK-8340852.md` >> >> the only problem with this is that the feature may not make it into specific release so the docs need to be moved, which will break the reviews and the mailing list. >> >> May be we can organize drafts using dates `/doc-files/drafts/2025/0227/JDK-8340852` and organize the final versions by release `/doc-files/notes/24/JDK-8340852`? > >> `doc-files/notes/24/JDK-8340852.md` >> >> the only problem with this is that the feature may not make it into specific release so the docs need to be moved, which will break the reviews and the mailing list. > > By the time something gets into the mainline jfx repo, we know which release it is targeted to. We already have to update the `@since` tags for any in-progress reviews when the targeted release changes, and this is no different. > >> May be we can organize drafts using dates `/doc-files/drafts/2025/0227/JDK-8340852` and organize the final versions by release `/doc-files/notes/24/JDK-8340852`? > > This will never happen for additional release notes. By definition we don't even write them until they are integrated. > > For JEPs, maybe... _if_ we ever put Draft DEPs in our repo (I don't think we should, but let's cross that bridge when we have the JEP discussion). Getting back to this release note question, I did the split in a separate [8350136-release-notes-24.dev](https://github.com/kevinrushforth/jfx/tree/8350136-release-notes-24.dev) branch. Here is the [updated release note for the ScrollPane behavior change](https://github.com/kevinrushforth/jfx/blob/8350136-release-notes-24.dev/doc-files/release-notes-24.md#scrollpane-consumes-navigation-keys-only-when-it-has-direct-focus). @hjohn @andy-goryachev-oracle please take a look. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974241857 From mstrauss at openjdk.org Thu Feb 27 23:36:04 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Feb 2025 23:36:04 GMT Subject: RFR: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" [v3] In-Reply-To: References: Message-ID: On Thu, 27 Feb 2025 18:54:45 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - merge >> - Merge branch 'master' into fixes/vetoable-list-decorator-sort >> >> # Conflicts: >> # modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java >> - factor out setAll implementation >> - Implement sorting for VetoableListDecorator >> - failing tests > > modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 127: > >> 125: >> 126: private boolean setAllImpl(List unmodifiableList) { >> 127: onProposedChange(unmodifiableList, 0, size()); > > Have you thought of moving all the checks and wrapping into `setAllImpl()`? > > Regardless of that, the current code is good. The wrappers are slightly different (`UnmodifiableArrayList` vs `Collections.unmodifiableList`), so doing that would be a little less efficient. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1674#discussion_r1974492296 From mstrauss at openjdk.org Thu Feb 27 23:36:05 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Feb 2025 23:36:05 GMT Subject: Integrated: 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 00:55:36 GMT, Michael Strau? wrote: > The `VetoableListDecorator` class does not override the default implementation of `List.sort()`. The default implementation copies the elements into an array, sorts the array, and then calls `List.set()` in a loop to sort the List **without removing the old elements first**. This leads to the `VetoableListDecorator` intercepting the call to `set()` and seeing a "duplicate child" being added. > > The solution is to implement `SortableList.doSort()` with the following protocol: > 1. Make a copy of the list and sort it. > 2. Present the sorted list with `onProposedChange` for a potential veto. > 3. If successful, use `setAll()` to swap out the current list with the sorted list. This pull request has now been integrated. Changeset: f3ba4485 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/f3ba44858efe16a4a82cdcd37c998023b3603eea Stats: 49 lines in 4 files changed: 40 ins; 4 del; 5 mod 8233179: VetoableListDecorator#sort throws IllegalArgumentException "duplicate children" Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1674 From jhendrikx at openjdk.org Fri Feb 28 02:04:19 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 02:04:19 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 In-Reply-To: References: <54jvCUubyygJYt0J1_8HtJwKRliBgnnBjOeUdYCjI8c=.388d1dd2-2599-4cd1-928a-d15184bb7f11@github.com> Message-ID: On Thu, 27 Feb 2025 19:44:53 GMT, Kevin Rushforth wrote: >>> `doc-files/notes/24/JDK-8340852.md` >>> >>> the only problem with this is that the feature may not make it into specific release so the docs need to be moved, which will break the reviews and the mailing list. >> >> By the time something gets into the mainline jfx repo, we know which release it is targeted to. We already have to update the `@since` tags for any in-progress reviews when the targeted release changes, and this is no different. >> >>> May be we can organize drafts using dates `/doc-files/drafts/2025/0227/JDK-8340852` and organize the final versions by release `/doc-files/notes/24/JDK-8340852`? >> >> This will never happen for additional release notes. By definition we don't even write them until they are integrated. >> >> For JEPs, maybe... _if_ we ever put Draft DEPs in our repo (I don't think we should, but let's cross that bridge when we have the JEP discussion). > > Getting back to this release note question, I did the split in a separate [8350136-release-notes-24.dev](https://github.com/kevinrushforth/jfx/tree/8350136-release-notes-24.dev) branch. Here is the [updated release note for the ScrollPane behavior change](https://github.com/kevinrushforth/jfx/blob/8350136-release-notes-24.dev/doc-files/release-notes-24.md#scrollpane-consumes-navigation-keys-only-when-it-has-direct-focus). > > @hjohn @andy-goryachev-oracle please take a look. @kevinrushforth Yeah, that was what I had intended, just the first few lines, and a link to the code sample. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1974623329 From arapte at openjdk.org Fri Feb 28 11:47:10 2025 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 28 Feb 2025 11:47:10 GMT Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v7] In-Reply-To: References: Message-ID: <65HCZyfzuXcId6WPcOPeewV0i_t1mF5GYbWOCqyE3Tw=.f1d028ce-6766-48e8-a6e0-b0aa63050250@github.com> On Wed, 26 Feb 2025 11:30:50 GMT, Alexander Zuev wrote: >> Create implementation for Slider and Stepper accessibility protocols. >> Fix mapping. >> Fix performAction parameter type in declaration. > > Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Add accessibilityTitleUIElement function to the base class. > - Merge branch 'master' into JDK-8313556 > - Merge pull request #13 from openjdk/master > > Merge > - Merge pull request #12 from openjdk/master > > Merge > - Merge pull request #11 from openjdk/master > > Merge > - Merge pull request #10 from openjdk/master > > Merge > - Adding accessibilityMinValue and accessibilityMaxValue > - Merge remote-tracking branch 'origin/master' into JDK-8313556 > - Merge pull request #7 from openjdk/master > > Merge > - - Added accessibilityTitle method > - Removed some debug output generation > - ... and 4 more: https://git.openjdk.org/jfx/compare/7a7854c9...09f68099 LGTM... Tested the behavior of both controls, observed no problem. Providing a minor query, If you choose to make the change I shall re-approve. modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 165: > 163: GLASS_CHECK_EXCEPTION(env); > 164: return variantToID(env, jresult); > 165: } This method is same as `accessibilityLabel`. Should we change implementation to call one method from the other ? ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1226#pullrequestreview-2650514116 PR Review Comment: https://git.openjdk.org/jfx/pull/1226#discussion_r1975274350 From michaelstrau2 at gmail.com Fri Feb 28 13:06:45 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 28 Feb 2025 14:06:45 +0100 Subject: Platform preferences changes are not properly registered on Linux In-Reply-To: References: Message-ID: I've installed Ubuntu 24.10 (clean install), which comes with Gnome 47.0. Running tests/manual/events/PlatformPreferencesChangedTest, I can observe that backgroundColor (GTK.theme_bg_color), foregroundColor (GTK.theme_fg_color), and colorScheme correctly reflect the system settings. When I toggle "Dark Style" from the Ubuntu system menu, the values update as expected. It seems strange that the problem would appear for you with Gnome 46.0 as well as 47.4, but it doesn't appear for me with 47.0. Maybe something else is going on with your configuration. On Thu, Feb 27, 2025 at 7:25?PM Christopher Schnick wrote: > > Hello, > > it seems like the Platform preferences API does not properly register > theme updates anymore in the latest desktop environments. > > In my testing, it didn't work on Gnome 47.4 and KDE Plasma 6.3.2. The > color scheme is always light and no updates are registered. The accent > color is also always the default one. > > On Gnome 46.0, when you change the dark mode setting, the GTK.theme_name > is actually updated but the bgcolor and fgcolor properties are not, > leading to the color scheme not being updated. But here, the properties > are definitely detected correctly on initialization, it's just the > updates that are not happening at runtime when something is changed. > > Best > Christopher Schnick From kcr at openjdk.org Fri Feb 28 13:09:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 13:09:31 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: Message-ID: > This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). > > The following filter was used to produce the list of issues fixed in JavaFX 24: > > https://bugs.openjdk.org/issues/?filter=46704 > > Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision: - jmoods --> jmods - Update JDK-8340852-info.md - Move example of restoring ScrollPane behavior to separate note ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1712/files - new: https://git.openjdk.org/jfx/pull/1712/files/c3344d86..743e9ef6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=00-01 Stats: 107 lines in 2 files changed: 54 ins; 51 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1712.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1712/head:pull/1712 PR: https://git.openjdk.org/jfx/pull/1712 From kcr at openjdk.org Fri Feb 28 13:09:31 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 13:09:31 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: <54jvCUubyygJYt0J1_8HtJwKRliBgnnBjOeUdYCjI8c=.388d1dd2-2599-4cd1-928a-d15184bb7f11@github.com> Message-ID: On Fri, 28 Feb 2025 02:01:35 GMT, John Hendrikx wrote: >> Getting back to this release note question, I did the split in a separate [8350136-release-notes-24.dev](https://github.com/kevinrushforth/jfx/tree/8350136-release-notes-24.dev) branch. Here is the [updated release note for the ScrollPane behavior change](https://github.com/kevinrushforth/jfx/blob/8350136-release-notes-24.dev/doc-files/release-notes-24.md#scrollpane-consumes-navigation-keys-only-when-it-has-direct-focus). >> >> @hjohn @andy-goryachev-oracle please take a look. > > @kevinrushforth Yeah, that was what I had intended, just the first few lines, and a link to the code sample. Thanks. I'll update the PR with that change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975384767 From kcr at openjdk.org Fri Feb 28 13:16:16 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 13:16:16 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 13:09:31 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 24: >> >> https://bugs.openjdk.org/issues/?filter=46704 >> >> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). > > Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision: > > - jmoods --> jmods > - Update JDK-8340852-info.md > - Move example of restoring ScrollPane behavior to separate note doc-files/release-notes-24.md line 78: > 76: `ScrollPane` now only responds to key events when it is the active focus owner. This ensures that custom controls and other UI elements work correctly inside a `ScrollPane`, providing a more consistent and intuitive navigation experience. > 77: > 78: Applications that prefer the previous behavior, where `ScrollPane` always reacts to arrow keys and other navigational inputs, can manually restore it by adding an event handler. See [this note](notes/24/JDK-8340852-info.md) for an example of how to do this. Note to reviewers: If you are viewing the rich diffs and try to click on the "this note" link, it won't work. If you "View file" then you can test the link, which works for me. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975393191 From kcr at openjdk.org Fri Feb 28 13:20:04 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 13:20:04 GMT Subject: [jfx24u] Integrated: 8350437: [GHA] Update gradle wrapper-validation action to v3 In-Reply-To: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> References: <2MpVo7SZ1RCiuYL3TsD0GNAL00igl2WdxM2ga9BZoRA=.9b52aeea-853f-49d1-8522-fb58659fc704@github.com> Message-ID: On Fri, 21 Feb 2025 16:37:57 GMT, Kevin Rushforth wrote: > Clean backport of GHA-only fix to jfx24u. This pull request has now been integrated. Changeset: 1e670267 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx24u/commit/1e67026705bd374b19d779e913afd20a11ce829e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8350437: [GHA] Update gradle wrapper-validation action to v3 Reviewed-by: jvos Backport-of: 163bf6d42fde7de0454695311746964ff6bc1f49 ------------- PR: https://git.openjdk.org/jfx24u/pull/8 From crschnick at xpipe.io Fri Feb 28 13:30:48 2025 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 28 Feb 2025 14:30:48 +0100 Subject: Platform preferences changes are not properly registered on Linux In-Reply-To: References: Message-ID: <497c9ec1-a8fc-4bf9-a3e1-c2bc5e7877e1@xpipe.io> So I looked a little bit more into it. On a fresh Ubuntu 24.04 Gnome that I run, it actually registers as expected. For testing, I then installed KDE with sudo apt install kde-standard. During the installation it asks you to switch the display manager from gdm3 to sddm, which I did. Then, the behaviour I observed happens if you launch into Gnome. I even reverted back to gdm3 again, but now it also has the same behaviour there. On 28/02/2025 14:06, Michael Strau? wrote: > I've installed Ubuntu 24.10 (clean install), which comes with Gnome 47.0. > > Running tests/manual/events/PlatformPreferencesChangedTest, I can > observe that backgroundColor (GTK.theme_bg_color), foregroundColor > (GTK.theme_fg_color), and colorScheme correctly reflect the system > settings. When I toggle "Dark Style" from the Ubuntu system menu, the > values update as expected. > > It seems strange that the problem would appear for you with Gnome 46.0 > as well as 47.4, but it doesn't appear for me with 47.0. > Maybe something else is going on with your configuration. > > On Thu, Feb 27, 2025 at 7:25?PM Christopher Schnick wrote: >> Hello, >> >> it seems like the Platform preferences API does not properly register >> theme updates anymore in the latest desktop environments. >> >> In my testing, it didn't work on Gnome 47.4 and KDE Plasma 6.3.2. The >> color scheme is always light and no updates are registered. The accent >> color is also always the default one. >> >> On Gnome 46.0, when you change the dark mode setting, the GTK.theme_name >> is actually updated but the bgcolor and fgcolor properties are not, >> leading to the color scheme not being updated. But here, the properties >> are definitely detected correctly on initialization, it's just the >> updates that are not happening at runtime when something is changed. >> >> Best >> Christopher Schnick From michaelstrau2 at gmail.com Fri Feb 28 13:49:23 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 28 Feb 2025 14:49:23 +0100 Subject: Platform preferences changes are not properly registered on Linux In-Reply-To: <497c9ec1-a8fc-4bf9-a3e1-c2bc5e7877e1@xpipe.io> References: <497c9ec1-a8fc-4bf9-a3e1-c2bc5e7877e1@xpipe.io> Message-ID: Are colors reported at all in the change notification on your system? If not, then it's probably because gtk_style_lookup_color() returns false. From crschnick at xpipe.io Fri Feb 28 14:01:35 2025 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 28 Feb 2025 15:01:35 +0100 Subject: Platform preferences changes are not properly registered on Linux In-Reply-To: References: <497c9ec1-a8fc-4bf9-a3e1-c2bc5e7877e1@xpipe.io> Message-ID: <0aeaca4a-270d-4fe7-8c6e-c2634a0c92dd@xpipe.io> The only change that is registered when I switch between dark mode settings is: replaced Yaru by Yaru-dark at key GTK.theme_name If I change the accent color, it registers the following changes: replaced 0xe95420ff by 0x03875bff at key GTK.theme_unfocused_selected_bg_color replaced 0xe95420ff by 0x03875bff at key GTK.theme_selected_bg_color replaced Yaru by Yaru-viridian at key GTK.theme_name It seems like this is very much limited to the foreground and background colors not updating. The fg and bg color is also not updating when restarting the application or even rebooting. I switched to light mode, rebooted, and it still reports dark mode. On 28/02/2025 14:49, Michael Strau? wrote: > Are colors reported at all in the change notification on your system? > If not, then it's probably because gtk_style_lookup_color() returns false. From michaelstrau2 at gmail.com Fri Feb 28 14:23:59 2025 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 28 Feb 2025 21:23:59 +0700 Subject: Platform preferences changes are not properly registered on Linux In-Reply-To: <0aeaca4a-270d-4fe7-8c6e-c2634a0c92dd@xpipe.io> References: <497c9ec1-a8fc-4bf9-a3e1-c2bc5e7877e1@xpipe.io> <0aeaca4a-270d-4fe7-8c6e-c2634a0c92dd@xpipe.io> Message-ID: The way we?ve implemented this is that we always query all named colors, regardless of what change notification we receive. So even if a color theme change wouldn?t trigger a notification, a subsequent accent color change (that you observe) should pick up the changed fg/bg colors. Sounds like an issue with GTK or the underlying shell bindings. One way to test this hypothesis could be to write a simple GTK program that exercises the gtk_style_lookup_color API after a theme change. Christopher Schnick schrieb am Fr. 28. Feb. 2025 um 21:01: > The only change that is registered when I switch between dark mode > settings is: > replaced Yaru by Yaru-dark at key GTK.theme_name > > If I change the accent color, it registers the following changes: > replaced 0xe95420ff by 0x03875bff at key > GTK.theme_unfocused_selected_bg_color > replaced 0xe95420ff by 0x03875bff at key GTK.theme_selected_bg_color > replaced Yaru by Yaru-viridian at key GTK.theme_name > > It seems like this is very much limited to the foreground and background > colors not updating. The fg and bg color is also not updating when > restarting the application or even rebooting. I switched to light mode, > rebooted, and it still reports dark mode. > > On 28/02/2025 14:49, Michael Strau? wrote: > > Are colors reported at all in the change notification on your system? > > If not, then it's probably because gtk_style_lookup_color() returns > false. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Feb 28 15:29:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 15:29:59 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 13:09:31 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 24: >> >> https://bugs.openjdk.org/issues/?filter=46704 >> >> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). > > Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision: > > - jmoods --> jmods > - Update JDK-8340852-info.md > - Move example of restoring ScrollPane behavior to separate note doc-files/notes/24/JDK-8340852-info.md line 1: > 1: # Additional Information for JDK-8340852 minor suggestion: Rename the note to something like `JDK-8340852-ScrollPane.md` Imagine a release with 10-20 such notes/directories, it might be helpful to add a bit of context to the name, don't you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975596162 From angorya at openjdk.org Fri Feb 28 15:30:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 15:30:00 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 13:13:40 GMT, Kevin Rushforth wrote: > [this note](notes/24/JDK-8340852-info.md) very very minor: do you think it should spell the name of the file instead of "this note"? i.e. `[JDK-8340852-ScrollPane.md](notes/24/JDK-8340852-ScrollPane.md)` [JDK-8340852-ScrollPane.md](notes/24/JDK-8340852-ScrollPane.md) ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975599517 From kcr at openjdk.org Fri Feb 28 15:37:06 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 15:37:06 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v3] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Thu, 27 Feb 2025 15:53:34 GMT, Andy Goryachev wrote: > > For example, I recommend checking the following: > > MenuBarSkin line 799 > > ComboBoxListViewSkin line 199 > > I think it should be sufficient to mention the exception in the actual methods where the check is done, such as `hide()` and `show()`. I'm not talking about docs here. What I meant that if the code in question is ever executed on a background thread such that hide is called, this will now cause an exception at runtime. I don't know whether it is possible, but it isn't immediately obvious that this can't happen on a background thread -- at least not for the two cases I mentioned. In fact, I'm pretty sure that at least the second case (ComboBoxListViewSkin line 199) is possible. lh.addInvalidationListener(comboBox.sceneProperty(), (o) -> { if (((ObservableValue)o).getValue() == null) { comboBox.hide(); } }); I suspect that the following sequence of operations, all on a background thread, will trigger the exception: 1. Create a ComboBox 2. Create a Skin 3. Add the combobox to a Scene (the scene must not be showing, of course) A solution might be to check whether the combobox is showing before hiding it. lh.addInvalidationListener(comboBox.sceneProperty(), (o) -> { if (((ObservableValue)o).getValue() == null) { if (comboBox.isShowing()) { comboBox.hide(); } } }); And, if the code in MenuBarSkin is a problem, then something like this might be in order: if (menuButton.isShowing()) { menuButton.hide(); } Similarly, I think this listener in `MenuBarSkin::rebuildUI` (starting on line 913) might need a check before calling `menuButton.hide()`: menuButton.menuListener = (observable, oldValue, newValue) -> { if (menu.isShowing()) { menuButton.show(); menuModeStart(container.getChildren().indexOf(menuButton)); } else { menuButton.hide(); // <-- check if (menuButton.isShowing()) before calling } }; ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2690955428 From kcr at openjdk.org Fri Feb 28 15:37:07 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 15:37:07 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v3] In-Reply-To: <4klz-DJIBJFB07-ub0fiM2_0t6qTJxx8fwYSP9qEqwg=.6a98877f-40e3-4c02-b1df-bad8ce808d09@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> <4klz-DJIBJFB07-ub0fiM2_0t6qTJxx8fwYSP9qEqwg=.6a98877f-40e3-4c02-b1df-bad8ce808d09@github.com> Message-ID: On Thu, 27 Feb 2025 15:57:07 GMT, Andy Goryachev wrote: >> - enforced fx application thread >> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show() >> - clarified `ComboBoxBase::show` >> - added a headful test `TestThreadingRestrictions` > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments The updated docs look good. Go ahead and create the CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2690958410 From kcr at openjdk.org Fri Feb 28 15:56:19 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 15:56:19 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3] In-Reply-To: References: Message-ID: > This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). > > The following filter was used to produce the list of issues fixed in JavaFX 24: > > https://bugs.openjdk.org/issues/?filter=46704 > > Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: JDK-8340852-info.md --> JDK-8340852-ScrollPane.md ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1712/files - new: https://git.openjdk.org/jfx/pull/1712/files/743e9ef6..6f8cb54b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=01-02 Stats: 1 line in 2 files changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1712.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1712/head:pull/1712 PR: https://git.openjdk.org/jfx/pull/1712 From kcr at openjdk.org Fri Feb 28 15:56:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 15:56:21 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 15:25:03 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision: >> >> - jmoods --> jmods >> - Update JDK-8340852-info.md >> - Move example of restoring ScrollPane behavior to separate note > > doc-files/notes/24/JDK-8340852-info.md line 1: > >> 1: # Additional Information for JDK-8340852 > > minor suggestion: > Rename the note to something like `JDK-8340852-ScrollPane.md` > > Imagine a release with 10-20 such notes/directories, it might be helpful to add a bit of context to the name, don't you think? Renamed as suggested. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975639437 From kcr at openjdk.org Fri Feb 28 15:56:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 15:56:21 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v2] In-Reply-To: References: Message-ID: <4FLnJ68J9yqdq6tEnK-bXXWLcAfjDvmYP0EksMX2l4o=.b4954d07-ddac-4f9c-be90-5e4ec6206ebe@github.com> On Fri, 28 Feb 2025 15:26:33 GMT, Andy Goryachev wrote: >> doc-files/release-notes-24.md line 78: >> >>> 76: `ScrollPane` now only responds to key events when it is the active focus owner. This ensures that custom controls and other UI elements work correctly inside a `ScrollPane`, providing a more consistent and intuitive navigation experience. >>> 77: >>> 78: Applications that prefer the previous behavior, where `ScrollPane` always reacts to arrow keys and other navigational inputs, can manually restore it by adding an event handler. See [this note](notes/24/JDK-8340852-info.md) for an example of how to do this. >> >> Note to reviewers: If you are viewing the rich diffs and try to click on the "this note" link, it won't work. If you "View file" then you can test the link, which works for me. > >> [this note](notes/24/JDK-8340852-info.md) > > very very minor: > do you think it should spell the name of the file instead of "this note"? > i.e. `[JDK-8340852-ScrollPane.md](notes/24/JDK-8340852-ScrollPane.md)` > [JDK-8340852-ScrollPane.md](notes/24/JDK-8340852-ScrollPane.md) ? In this case, the name of the file is irrelevant to readers of the doc, so I prefer not to. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975640926 From angorya at openjdk.org Fri Feb 28 16:13:59 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 16:13:59 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 15:56:19 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 24: >> >> https://bugs.openjdk.org/issues/?filter=46704 >> >> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note). > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8340852-info.md --> JDK-8340852-ScrollPane.md Marked as reviewed by angorya (Reviewer). doc-files/release-notes-24.md line 214: > 212: [JDK-8340982](https://bugs.openjdk.org/browse/JDK-8340982) | [win] Dead key followed by Space generates two characters instead of one | window-toolkit > 213: [JDK-8344372](https://bugs.openjdk.org/browse/JDK-8344372) | Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' | window-toolkit > 214: [JDK-8348744](https://bugs.openjdk.org/browse/JDK-8348744) | Application window not always activated on macOS 15 | window-toolkit double checked all the links. BTW, are these links (`[JDK-8348744](https://bugs.openjdk.org/browse/JDK-8348744)`) formatted manually or is there some kind of script? ------------- PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2651191808 PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975666674 From angorya at openjdk.org Fri Feb 28 16:16:04 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 16:16:04 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v3] In-Reply-To: <4klz-DJIBJFB07-ub0fiM2_0t6qTJxx8fwYSP9qEqwg=.6a98877f-40e3-4c02-b1df-bad8ce808d09@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> <4klz-DJIBJFB07-ub0fiM2_0t6qTJxx8fwYSP9qEqwg=.6a98877f-40e3-4c02-b1df-bad8ce808d09@github.com> Message-ID: On Thu, 27 Feb 2025 15:57:07 GMT, Andy Goryachev wrote: >> - enforced fx application thread >> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show() >> - clarified `ComboBoxBase::show` >> - added a headful test `TestThreadingRestrictions` > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments created CSR https://bugs.openjdk.org/browse/JDK-8350962 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2691039623 From kcr at openjdk.org Fri Feb 28 16:22:58 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 16:22:58 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v6] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Tue, 25 Feb 2025 22:33:40 GMT, Andy Goryachev wrote: >> Root Cause: >> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe. >> >> I also changed the design a bit. Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points. This is rather inefficient, as the property has to manage (thousands?) of listeners. >> >> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly. >> >> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread. >> >> With this change, it is safe to create and populate charts with data in a background thread. >> >> --- >> >> ## NOTES >> >> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false after it transitioned to true. Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true. >> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe. >> >> ## Note to the Reviewers >> >> To avoid merge conflicts, the preferred order of integrations: >> >> #1697 >> #1713 >> #1717 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - review comments > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - enabled pie chart test > - Merge branch 'master' into 8349091.charts.thread.safety > - Merge branch 'master' into 8349091.charts.thread.safety > - whitespace > - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety > - cleanup > - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0 What you have now works in all cases I've tried. I left a couple suggestions and will reapprove if you decide to make changes. modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 106: > 104: > 105: // SimpleBooleanProperty or ObjectBinding > 106: private volatile Object accessibilityActive; You can use `ObservableValue` instead of `Object` as the type. Alternatively, use two fields, a `SimpleBooleanProperty` for use by the FX app thread and an ObjectBinding for use by a background thread. They wouldn't need to be volatile in that case. What you have is OK, but using two properties might simplify the logic a bit. modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 561: > 559: accessibilityActive = winProp; // keep the reference so it won't get gc > 560: > 561: // lambda cannot be used in place of a ChangeListener in removeListener() Why not use a Subscription then? It seems tailor-made for what you are trying to do. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2644733749 PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1971704069 PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1971713667 From kcr at openjdk.org Fri Feb 28 16:28:15 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 16:28:15 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 16:10:48 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8340852-info.md --> JDK-8340852-ScrollPane.md > > doc-files/release-notes-24.md line 214: > >> 212: [JDK-8340982](https://bugs.openjdk.org/browse/JDK-8340982) | [win] Dead key followed by Space generates two characters instead of one | window-toolkit >> 213: [JDK-8344372](https://bugs.openjdk.org/browse/JDK-8344372) | Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' | window-toolkit >> 214: [JDK-8348744](https://bugs.openjdk.org/browse/JDK-8348744) | Application window not always activated on macOS 15 | window-toolkit > > double checked all the links. > > BTW, are these links (`[JDK-8348744](https://bugs.openjdk.org/browse/JDK-8348744)`) formatted manually or is there some kind of script? I use an emacs macro to do it, so semi-automated (I don't hand edit 83 separate entries). It could save a little time to write a shell script (and wouldn't be hard), so I'll look into that for next time. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975687167 From angorya at openjdk.org Fri Feb 28 16:34:04 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 16:34:04 GMT Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 16:24:58 GMT, Kevin Rushforth wrote: >> doc-files/release-notes-24.md line 214: >> >>> 212: [JDK-8340982](https://bugs.openjdk.org/browse/JDK-8340982) | [win] Dead key followed by Space generates two characters instead of one | window-toolkit >>> 213: [JDK-8344372](https://bugs.openjdk.org/browse/JDK-8344372) | Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' | window-toolkit >>> 214: [JDK-8348744](https://bugs.openjdk.org/browse/JDK-8348744) | Application window not always activated on macOS 15 | window-toolkit >> >> double checked all the links. >> >> BTW, are these links (`[JDK-8348744](https://bugs.openjdk.org/browse/JDK-8348744)`) formatted manually or is there some kind of script? > > I use an emacs macro to do it, so semi-automated (I don't hand edit 83 separate entries). It could save a little time to write a shell script (and wouldn't be hard), so I'll look into that for next time. as long as it's not a totally manual process, we should be fine. otherwise we'd need to check the links every time. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1975695755 From mstrauss at openjdk.org Fri Feb 28 16:51:15 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 28 Feb 2025 16:51:15 GMT Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4] In-Reply-To: References: Message-ID: <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com> On Thu, 27 Feb 2025 09:59:04 GMT, Oliver Schmidtmer wrote: >> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 406: >> >>> 404: cdata = 0; >>> 405: } >>> 406: } else if(CF_TEXT == cf || CF_UNICODETEXT == cf){ >> >> Instead of doing that, consider always requesting `CF_UNICODETEXT` from the clipboard. Windows will then convert both `CF_TEXT` and `CF_OEMTEXT` to unicode (see [Synthesized Clipboard Formats](https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats)). > > As the existing code was already pretty optimistic about 2 byte chars, is it possible that is already handled somewhere else? > I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT is just tried first. Could be, but in any case, the way it's impemented right now doesn't seem to be right. We should only assume 2-byte characters if what's being pulled from the clipboard is actually `CF_UNICODETEXT`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1975720976 From zjx001202 at gmail.com Fri Feb 28 17:33:37 2025 From: zjx001202 at gmail.com (Glavo) Date: Sat, 1 Mar 2025 01:33:37 +0800 Subject: What is the best way to get a high frame rate in a JavaFX application? In-Reply-To: References: Message-ID: I noticed that when `javafx.animation.pulse` is set, `AbstractPrimaryTimer` always prints a message to `System.err`: Setting PULSE_DURATION to xxx hz This debug message looked annoying, and I thought it should only be printed when javafx.verbose is true, so I created a PR: https://github.com/openjdk/jfx/pull/1726 Can anyone take a look at it? Glavo On Thu, Feb 27, 2025 at 2:17?AM Johan Vos wrote: > Hi Glavo, > > I believe setting the javafx.animation.pulse is indeed the best way to > increase the render frequency (or to minimize the time between 2 pulses). > It is independent of the hardware/pipeline being used. > Of course, you may see a higher load in the JavaFX Application Thread and > in the Quantum Renderer, but I guess you're aware of that -- but even at 10 > fps those threads can be under pressure (same for the GPU cache). > > - Johan > > > On Wed, Feb 26, 2025 at 7:01?PM Glavo wrote: > >> I found that setting `javafx.animation.pulse` to a higher value worked >> for me. >> I considered setting `javafx.animation.pulse` to 120 for all users to get >> smooth animation. >> Is this the most recommended approach at this time? >> >> Glavo >> >> On Wed, Feb 26, 2025 at 3:55?AM Glavo wrote: >> >>> Hi, >>> >>> Recently I was investigating how to improve the user experience of our >>> JavaFX applications. >>> I noticed that JavaFX applications seem to be limited to 60fps by >>> default, >>> which makes JavaFX applications appear to animate less smoothly than >>> many other applications >>> when users are using high refresh rate monitors. >>> In particular, we used a self-drawn title bar, which caused users to >>> drag our app more slowly than dragging other applications. >>> >>> I learned that there is an undocumented property >>> `javafx.animation.fullspeed` >>> and that setting it to true would significantly improve the user >>> experience of our application. >>> While it works fine on my computer, it seems to have a lot of potential >>> problems, >>> such as conflicts with vsync, may have significantly higher CPU/GPU >>> utilization, and has been less tested, >>> so I dare not push it to users. >>> There is also a property `javafx.animation.framerate` which seems to be >>> safer, but it didn't work for me. >>> >>> So, what is the best way to get a high frame rate for a JavaFX >>> application? >>> Can we get more than 60fps in a JavaFX application with vsync enabled? >>> Is it possible to make JavaFX applications adapt to the monitor's >>> refresh rate without us setting it to a fixed value? >>> >>> Glavo >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Feb 28 18:27:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 18:27:00 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v6] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Wed, 26 Feb 2025 14:34:50 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 25 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - enabled pie chart test >> - Merge branch 'master' into 8349091.charts.thread.safety >> - Merge branch 'master' into 8349091.charts.thread.safety >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - cleanup >> - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0 > > modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 106: > >> 104: >> 105: // SimpleBooleanProperty or ObjectBinding >> 106: private volatile Object accessibilityActive; > > You can use `ObservableValue` instead of `Object` as the type. Alternatively, use two fields, a `SimpleBooleanProperty` for use by the FX app thread and an ObjectBinding for use by a background thread. They wouldn't need to be volatile in that case. What you have is OK, but using two properties might simplify the logic a bit. It's a design decision - I won't want to waste an extra pointer. The cpu cycles are much cheaper nowadays than bytes. Extra bytes cost much more in cpu cycles (gc) and electricity. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1975850728 From angorya at openjdk.org Fri Feb 28 18:37:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 18:37:01 GMT Subject: RFR: 8349091: Charts: exception initializing in a background thread [v6] In-Reply-To: References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com> Message-ID: On Wed, 26 Feb 2025 14:40:16 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 25 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - enabled pie chart test >> - Merge branch 'master' into 8349091.charts.thread.safety >> - Merge branch 'master' into 8349091.charts.thread.safety >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety >> - cleanup >> - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0 > > modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 561: > >> 559: accessibilityActive = winProp; // keep the reference so it won't get gc >> 560: >> 561: // lambda cannot be used in place of a ChangeListener in removeListener() > > Why not use a Subscription then? It seems tailor-made for what you are trying to do. I don't know how to use Subscription in this case. This does not work: ObservableValue winProp = sceneProperty().flatMap(Scene::windowProperty); accessibilityActive = winProp; // keep the reference so it won't get gc Subscription sub = winProp.subscribe((win) -> { if (win != null) { if (accessibilityActive == winProp) { accessibilityActive = null; } if (isAccessibilityActive()) { handleAccessibilityActive(true); } //winProp.removeListener(this); sub.unsubscribe(); <-- COMPILE ERROR } }); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1975861040 From angorya at openjdk.org Fri Feb 28 19:28:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 19:28:58 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v3] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Fri, 28 Feb 2025 15:33:13 GMT, Kevin Rushforth wrote: > MenuBarSkin line 799 > ComboBoxListViewSkin line 199 ComboBoxListViewSkin - thanks for the suggestion! MenuBarSkin - is a bit more complex case because of the interaction with the system menu `Toolkit.getToolkit().getSystemMenu().isSupported()` which needs to be called from the FX application thread. We probably should disallow creating MenuBars in background thread (similar to Window, WebView, and HtmlEditor) in the constructor. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2691393337 From angorya at openjdk.org Fri Feb 28 20:09:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 20:09:00 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:30:17 GMT, John Hendrikx wrote: >> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. >> >> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). >> >> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: >> >> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: >> >> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). >> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. >> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. >> >> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. >> >> **Note**: some tests have had their va... > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix > - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1953: > 1951: > 1952: double alt = -1; > 1953: if (availableWidth != -1 & child.isResizable() && child.getContentBias() == Orientation.HORIZONTAL) { // height depends on width & or && ? modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2140: > 2138: > 2139: double computeMaxPrefAreaWidth(List children, Callback childMargins, > 2140: double[] childHeights, boolean fillHeight) { +1 modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 477: > 475: double[] usedHeights = areaHeights[0]; > 476: double[] temp = areaHeights[1]; > 477: final boolean isFillWidth = isFillWidth(); isn't it effectively final here? modules/javafx.graphics/src/shims/java/javafx/scene/layout/RegionShim.java line 59: > 57: Node child, Insets margin) { > 58: return r.computeChildMinAreaHeight(child, margin); > 59: } there is something wrong with indentation here. and ... in this class since it's a shim, I would rather auto-format the whole thing... modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java line 349: > 347: assertEquals(240 /* l + r + c*/, borderpane.prefHeight(-1), 1e-10); > 348: assertEquals(110, borderpane.minWidth(-1), 1e-100); /* min center + 2x pref width (l, r) */ > 349: assertEquals(20 /*t*/ + 200 /*c*/ + 20 /*b*/, borderpane.minHeight(-1), 1e-10); minor: Do you think it'll be easier to define the constants explicitly, line double L = 40; double C = 200; and use those? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1975942819 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1975944566 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1975947322 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1975949775 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1975951774 From crschnick at xpipe.io Fri Feb 28 20:10:59 2025 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 28 Feb 2025 21:10:59 +0100 Subject: Platform preferences changes are not properly registered on Linux In-Reply-To: References: <497c9ec1-a8fc-4bf9-a3e1-c2bc5e7877e1@xpipe.io> <0aeaca4a-270d-4fe7-8c6e-c2634a0c92dd@xpipe.io> Message-ID: Alright, so that seems to be more of a niche issue then. Especially with the display manager change to sddm. GTK is weird sometimes. On these systems, I will just implement a workaround to also listen to the GTK.theme_name and detect if it contains -dark. Not perfect, but works for some cases. To test this further, I also set up a VM with Fedora Workstation 41, brand-new with no other DE other than Gnome 47.4 installed. The only thing I did on that system was upgrade all packages after install. And on that system, the platform preferences don't work at all. All values are the default values and no updates are registered for any changes. Perhaps that can be reproduced more easily. If that is also not reproducible, we can look if there is any way I can provide some information / test some things to troubleshoot this on that system. On 28/02/2025 15:23, Michael Strau? wrote: > The way we?ve implemented this is that we always query all named > colors, regardless of what change notification we receive. So even if > a color theme change wouldn?t trigger a notification, a subsequent > accent color change (that you observe) should pick up the changed > fg/bg colors. > > Sounds like an issue with GTK or the underlying shell bindings. One > way to test this hypothesis could be to write a simple GTK program > that exercises the gtk_style_lookup_color API after a theme change. > > > Christopher Schnick schrieb am Fr. 28. Feb. 2025 > um 21:01: > > The only change that is registered when I switch between dark mode > settings is: > replaced Yaru by Yaru-dark at key GTK.theme_name > > If I change the accent color, it registers the following changes: > replaced 0xe95420ff by 0x03875bff at key > GTK.theme_unfocused_selected_bg_color > replaced 0xe95420ff by 0x03875bff at key GTK.theme_selected_bg_color > replaced Yaru by Yaru-viridian at key GTK.theme_name > > It seems like this is very much limited to the foreground and > background > colors not updating. The fg and bg color is also not updating when > restarting the application or even rebooting. I switched to light > mode, > rebooted, and it still reports dark mode. > > On 28/02/2025 14:49, Michael Strau? wrote: > > Are colors reported at all in the change notification on your > system? > > If not, then it's probably because gtk_style_lookup_color() > returns false. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Feb 28 21:07:36 2025 From: duke at openjdk.org (Gopal Pattnaik) Date: Fri, 28 Feb 2025 21:07:36 GMT Subject: RFR: 8327478: Add System test to verify TextSelection issue for webkit-617.1 Message-ID: There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989), Hence we are adding a system test now. Test is written as 1. Load html content in web view. 2. pick the color of mouse pointer. 3. Perform double click. 4. pick the color again. > expected bahaviour: colour picked in step 2 and 4 should not match. Verification: The test passes with latest webkit source Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted. ------------- Commit messages: - Addressed Review comments - Empty Commit to test actions. - Addressed Review comments - Add System Test TextSelectionTest Changes: https://git.openjdk.org/jfx/pull/1719/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327478 Stats: 126 lines in 2 files changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1719.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1719/head:pull/1719 PR: https://git.openjdk.org/jfx/pull/1719 From kcr at openjdk.org Fri Feb 28 21:07:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Feb 2025 21:07:37 GMT Subject: RFR: 8327478: Add System test to verify TextSelection issue for webkit-617.1 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 06:59:52 GMT, Gopal Pattnaik wrote: > There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989), > > Hence we are adding a system test now. > > Test is written as > 1. Load html content in web view. > 2. pick the color of mouse pointer. > 3. Perform double click. > 4. pick the color again. >> expected bahaviour: colour picked in step 2 and 4 should not match. > > Verification: > The test passes with latest webkit source > Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted. @Gopalora Please enable GHA tests on your repo. I'll provide a few comments now, and formally review it once your OCA status is verified. The latest changes look good. I'll formally review it once your OCA status is verified. tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 101: > 99: > 100: Util.runAndWait(() -> { > 101: robot.mouseMove(1, 1); Minor: use the utility method `Util.parkCursor(robot);` instead tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 110: > 108: Util.sleep(50); > 109: robot.mousePress(MouseButton.PRIMARY); > 110: robot.mouseRelease(MouseButton.PRIMARY); Minor: You can call `robot.mouseClick(MouseButton)` instead of separate calls to press/release. Not so minor: You shouldn't' sleep in the FX app thread. Instead, break this block into two separate lambdas passed into to separate calls to `runAndWait` with the sleep in between them running in the test thread. Like this: Util.runAndWait(() -> { ... robot.mouseClick(MouseButton.PRIMARY); }); Util.sleep(50); Util.runAndWait(() -> { robot.mouseClick(MouseButton.PRIMARY); }); Suggestion: consider creating a `doubleClick` utility method in the test `Util` class. tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 116: > 114: > 115: Util.runAndWait(() -> { > 116: robot.mouseMove(1, 1); Minor: use the utility method `Util.parkCursor(robot);` instead tests/system/src/test/java/test/util/Util.java line 340: > 338: * Makes double click of the mouse left button. > 339: */ > 340: public static void doubleClick(Robot robot, int x, int y) { Since this is now a general-purpose utility, I'd prefer to separate out the mouse move from the double-click (with the mouse move being done in the test itself) and just have this be `void doubleClick(Robot robot)`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1719#issuecomment-2682052978 PR Comment: https://git.openjdk.org/jfx/pull/1719#issuecomment-2690829082 PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1965697976 PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1965712264 PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1965699563 PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1971745158 From duke at openjdk.org Fri Feb 28 21:07:37 2025 From: duke at openjdk.org (Gopal Pattnaik) Date: Fri, 28 Feb 2025 21:07:37 GMT Subject: RFR: 8327478: Add System test to verify TextSelection issue for webkit-617.1 In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 06:59:52 GMT, Gopal Pattnaik wrote: > There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989), > > Hence we are adding a system test now. > > Test is written as > 1. Load html content in web view. > 2. pick the color of mouse pointer. > 3. Perform double click. > 4. pick the color again. >> expected bahaviour: colour picked in step 2 and 4 should not match. > > Verification: > The test passes with latest webkit source > Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted. Thanks for the review. I have done the code change as per the suggestions in the code file. Please have a relook of the changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1719#issuecomment-2684380284 From duke at openjdk.org Fri Feb 28 21:07:37 2025 From: duke at openjdk.org (Gopal Pattnaik) Date: Fri, 28 Feb 2025 21:07:37 GMT Subject: RFR: 8327478: Add System test to verify TextSelection issue for webkit-617.1 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 14:54:06 GMT, Kevin Rushforth wrote: >> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989), >> >> Hence we are adding a system test now. >> >> Test is written as >> 1. Load html content in web view. >> 2. pick the color of mouse pointer. >> 3. Perform double click. >> 4. pick the color again. >>> expected bahaviour: colour picked in step 2 and 4 should not match. >> >> Verification: >> The test passes with latest webkit source >> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted. > > tests/system/src/test/java/test/util/Util.java line 340: > >> 338: * Makes double click of the mouse left button. >> 339: */ >> 340: public static void doubleClick(Robot robot, int x, int y) { > > Since this is now a general-purpose utility, I'd prefer to separate out the mouse move from the double-click (with the mouse move being done in the test itself) and just have this be `void doubleClick(Robot robot)`. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1972974893 From angorya at openjdk.org Fri Feb 28 21:09:37 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 21:09:37 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v4] In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: > - enforced fx application thread > - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show() > - clarified `ComboBoxBase::show` > - added a headful test `TestThreadingRestrictions` 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/1717/files - new: https://git.openjdk.org/jfx/pull/1717/files/7d8ef4e2..b6afe882 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=02-03 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1717.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717 PR: https://git.openjdk.org/jfx/pull/1717 From jhendrikx at openjdk.org Fri Feb 28 21:12:01 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:12:01 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 19:54:22 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix >> - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1953: > >> 1951: >> 1952: double alt = -1; >> 1953: if (availableWidth != -1 & child.isResizable() && child.getContentBias() == Orientation.HORIZONTAL) { // height depends on width > > & or && ? Oops, definitely `&&` :) > modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 477: > >> 475: double[] usedHeights = areaHeights[0]; >> 476: double[] temp = areaHeights[1]; >> 477: final boolean isFillWidth = isFillWidth(); > > isn't it effectively final here? Yeah, I think I "copied" the code style surrounding it... you normally wouldn't catch me writing `final` on locals > modules/javafx.graphics/src/shims/java/javafx/scene/layout/RegionShim.java line 59: > >> 57: Node child, Insets margin) { >> 58: return r.computeChildMinAreaHeight(child, margin); >> 59: } > > there is something wrong with indentation here. > and ... in this class > > since it's a shim, I would rather auto-format the whole thing... I'll see what I can do > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java line 349: > >> 347: assertEquals(240 /* l + r + c*/, borderpane.prefHeight(-1), 1e-10); >> 348: assertEquals(110, borderpane.minWidth(-1), 1e-100); /* min center + 2x pref width (l, r) */ >> 349: assertEquals(20 /*t*/ + 200 /*c*/ + 20 /*b*/, borderpane.minHeight(-1), 1e-10); > > minor: Do you think it'll be easier to define the constants explicitly, line > > double L = 40; > double C = 200; > > and use those? I just copied the style that was being used, but can make any changes desired of course (at the expense of increasing the diff and amount of code to review). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976010610 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976011044 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976011363 PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976012048 From jhendrikx at openjdk.org Fri Feb 28 21:18:12 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:18:12 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v3] In-Reply-To: References: Message-ID: > Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. > > The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). > > With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: > > Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: > > 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). > 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. > 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. > > All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. > > **Note**: some tests have had their values adjusted. This is becaus... John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Use logical AND instead of binary one - Fix indents in ReginonShim ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1723/files - new: https://git.openjdk.org/jfx/pull/1723/files/b55c20e9..bbafc21f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=01-02 Stats: 11 lines in 2 files changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1723.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1723/head:pull/1723 PR: https://git.openjdk.org/jfx/pull/1723 From angorya at openjdk.org Fri Feb 28 21:18:12 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 21:18:12 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 21:09:30 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java line 349: >> >>> 347: assertEquals(240 /* l + r + c*/, borderpane.prefHeight(-1), 1e-10); >>> 348: assertEquals(110, borderpane.minWidth(-1), 1e-100); /* min center + 2x pref width (l, r) */ >>> 349: assertEquals(20 /*t*/ + 200 /*c*/ + 20 /*b*/, borderpane.minHeight(-1), 1e-10); >> >> minor: Do you think it'll be easier to define the constants explicitly, line >> >> double L = 40; >> double C = 200; >> >> and use those? > > I just copied the style that was being used, but can make any changes desired of course (at the expense of increasing the diff and amount of code to review). I know it's a general policy not to do unrelated changes or reformatting, but I think in this case a) it's a test and b) you already touched it so might as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976016376 From jhendrikx at openjdk.org Fri Feb 28 21:26:58 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:26:58 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v3] In-Reply-To: <0eIPzURMVNBvbyv7cQ_Ag6n9GNWhTbBGaCtoaMrBfs8=.f3ab2a5a-089c-4f36-8fb7-599506c28dd0@github.com> References: <0eIPzURMVNBvbyv7cQ_Ag6n9GNWhTbBGaCtoaMrBfs8=.f3ab2a5a-089c-4f36-8fb7-599506c28dd0@github.com> Message-ID: <6hE57F8OA9zkWS3gnMLzCIZBrUZQYY2gPwITjna5--A=.cad04b0b-1c48-4045-815f-7f7d558dd847@github.com> On Mon, 24 Feb 2025 20:54:05 GMT, Andy Goryachev wrote: >> Yeah, or possibly zero included. What I meant here is that these are **real** values, and don't have a "special" value `-1` meaning absent/unavailable. > > A _very quick_ test with the monkey tester showed it never entered `boundedSize()` with zero values, but I can't be sure (I've seen 0's in `layoutChildren()`). > > The statement about "never -1" is even more suspect below when margins are subtracted... > > I just wanted to point this out because I am not entirely sure that we'll never receive 0 width/height. There are a few guards in the code that prevent these values from becoming negative (as some negative values have special meanings). See for example this code: @Override public final double minWidth(double height) { final double override = getMinWidth(); if (override == USE_COMPUTED_SIZE) { return super.minWidth(height); } else if (override == USE_PREF_SIZE) { return prefWidth(height); } return Double.isNaN(override) || override < 0 ? 0 : override; } This method is `final`, to prevent anyone from messing with this logic. And as you can see, the `override` value (which comes from calling `computeMinWidth` for example) is checked against special values, and other values are returned instead. If it is not any special value, it is guarded against negative (it becomes 0) and against `NaN`. Whether that truly guarantees we'll never see negative values, I'm not 100% sure off, but I think that's definitely the intent as specific negative values have special meanings. So I think I'll document these as `cannot be negative`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976024980 From jhendrikx at openjdk.org Fri Feb 28 21:30:31 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:30:31 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4] In-Reply-To: References: Message-ID: > Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`. This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect). No reflow would occur before this fix. > > The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise). > > With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container. In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used. However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that: > > Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**: > > 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls). > 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used. The final width calculated is then used to determine the height. > 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used). The final width calculated is then used to determine the height. > > All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other. > > **Note**: some tests have had their values adjusted. This is becaus... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Clarify terms ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1723/files - new: https://git.openjdk.org/jfx/pull/1723/files/bbafc21f..87509310 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1723.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1723/head:pull/1723 PR: https://git.openjdk.org/jfx/pull/1723 From jhendrikx at openjdk.org Fri Feb 28 21:37:57 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:37:57 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:48:38 GMT, Andy Goryachev wrote: >> LOL, I think I may have said that :) However, perhaps the problem is not as bad as I made it out to be. It's definitely true that any operation on a floating point value may slightly nudge it away from a true snapped value (somewhere in the 10th decimal place) and that this problem gets worse the more operations you perform (ie. a HBox with 10.000 children will have a worse error than one with only a few children). >> >> But there may be some middle ground possible here. As long as our layout containers are aware that values returned from `computeMinWidth` etc are only "near" snapped (meaning that if you round them to the nearest pixel, you'll always get the right result), it should be fine -- one must take care not to immediately call `ceil` or `floor` on these values. A thing we may want to look into is how this is rendered on screen by the rendering layer; does the rendering do additional work when values are near snapped, or do they perform some rounding already anyway. I certainly never noticed these small errors resulting in display artifacts. >> >> In any case, this is probably better addressed in a separate effort, and we should probably write some guidelines first. I'm hoping to do some of this with the space distributor PR. > > In theory, all these calculations end up being used by the layoutChildren() which always (?) snap the values. > > So the question is whether this small error gets accumulated enough to shift the result to a wrong value. Given a typical number of children (<1000) and screen sizes (<10000), we might conclude that it's unlikely, since > > `Math.ulp(1000 * 10_000.0) = 1.862645149230957E-9` > > which is much smaller than the distance between pixels even at 1000% scale. That's absolutely true, however this can change quickly when large values are added or subtracted to/from small values, or when division or multiplication gets involved. So I'd say its relatively safe to do simple calculations with near snapped values, but one must be careful with functions like `ceil` and `floor` as they can amplify tiny floating-point errors due to their discontinuous nature. For example, if take a snapped `spacing` and add a snapped `left` and `right` margin, then call ceil on the result, it could go like this: 1.99999999999999 + 4.00000000000001 + 4.00000000000001 = 10.00000000000001 -> ceil -> 11 (instead of the expected 10) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976034201 From angorya at openjdk.org Fri Feb 28 21:43:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 21:43:58 GMT Subject: RFR: 8327478: Add System test to verify TextSelection issue for webkit-617.1 In-Reply-To: References: Message-ID: <8PtPXD8hTVpzl0XixxqhNiN1rDeyWp9hBvbcikFd2bI=.ec693954-976e-47dd-8256-37c2bafa6886@github.com> On Fri, 21 Feb 2025 06:59:52 GMT, Gopal Pattnaik wrote: > There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989), > > Hence we are adding a system test now. > > Test is written as > 1. Load html content in web view. > 2. pick the color of mouse pointer. > 3. Perform double click. > 4. pick the color again. >> expected bahaviour: colour picked in step 2 and 4 should not match. > > Verification: > The test passes with latest webkit source > Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted. tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 45: > 43: import test.util.Util; > 44: > 45: public class TextSelectionTest { I wonder if we could extend RobotTestBase base class to simplify the code? tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 47: > 45: public class TextSelectionTest { > 46: > 47: private static final String html = "" + we could use new java text block here private static final String html = """      some text """; tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 97: > 95: > 96: int x = (int)(scene.getWindow().getX() + scene.getX() + 22); > 97: int y = (int)(scene.getWindow().getY() + scene.getY() + 15); can these offsets (22, 15) be measured instead of hard-coded? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1976035941 PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1976034756 PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1976037222 From angorya at openjdk.org Fri Feb 28 21:52:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 21:52:01 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4] In-Reply-To: References: Message-ID: <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com> On Fri, 28 Feb 2025 21:35:30 GMT, John Hendrikx wrote: >> In theory, all these calculations end up being used by the layoutChildren() which always (?) snap the values. >> >> So the question is whether this small error gets accumulated enough to shift the result to a wrong value. Given a typical number of children (<1000) and screen sizes (<10000), we might conclude that it's unlikely, since >> >> `Math.ulp(1000 * 10_000.0) = 1.862645149230957E-9` >> >> which is much smaller than the distance between pixels even at 1000% scale. > > That's absolutely true, however this can change quickly when large values are added or subtracted to/from small values, or when division or multiplication gets involved. So I'd say its relatively safe to do simple calculations with near snapped values, but one must be careful with functions like `ceil` and `floor` as they can amplify tiny floating-point errors due to their discontinuous nature. For example, if take a snapped `spacing` and add a snapped `left` and `right` margin, then call ceil on the result, it could go like this: > > 1.99999999999999 + > 4.00000000000001 + > 4.00000000000001 = > 10.00000000000001 -> ceil -> 11 (instead of the expected 10) good point! This is exactly the reason for the code in ScaledMath:71 return Math.ceil(d - Math.ulp(d)) / scale; ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976043283 From jhendrikx at openjdk.org Fri Feb 28 21:52:01 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:52:01 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4] In-Reply-To: <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com> References: <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com> Message-ID: On Fri, 28 Feb 2025 21:46:13 GMT, Andy Goryachev wrote: >> That's absolutely true, however this can change quickly when large values are added or subtracted to/from small values, or when division or multiplication gets involved. So I'd say its relatively safe to do simple calculations with near snapped values, but one must be careful with functions like `ceil` and `floor` as they can amplify tiny floating-point errors due to their discontinuous nature. For example, if take a snapped `spacing` and add a snapped `left` and `right` margin, then call ceil on the result, it could go like this: >> >> 1.99999999999999 + >> 4.00000000000001 + >> 4.00000000000001 = >> 10.00000000000001 -> ceil -> 11 (instead of the expected 10) > > good point! > > This is exactly the reason for the code in ScaledMath:71 > > return Math.ceil(d - Math.ulp(d)) / scale; Come to think of it, most the issues here are caused by using functions like `floor` and `ceil`. It might be an idea to change these functions to bias them slightly towards rounding to the closest value, instead of always doing a straight up `floor` or `ceil`. For example, let's say I calculate a size as `3.0000001`; ceiling this (with snapSize) to `4` is quite ridiculous; obviously `3` was intended, but the ceiling function won't care. But what if we subtracted a value (assuming we're dealing with pixels of course, which the `snap` functions are)? We could bias it slightly towards the correct value by using something ridiculously small like 1/10000th of a pixel. For example: `3.0000001` - 1/10000th of a pixel = `2.9999`. Ceiling this value yields the intended `3`. We could work much safer with near snapped values, as there is much less risk of a one ulp difference being dramatically amplified by floor/ceil functions. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976045508 From jhendrikx at openjdk.org Fri Feb 28 21:54:57 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 21:54:57 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4] In-Reply-To: References: <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com> Message-ID: On Fri, 28 Feb 2025 21:48:54 GMT, John Hendrikx wrote: >> good point! >> >> This is exactly the reason for the code in ScaledMath:71 >> >> return Math.ceil(d - Math.ulp(d)) / scale; > > Come to think of it, most the issues here are caused by using functions like `floor` and `ceil`. It might be an idea to change these functions to bias them slightly towards rounding to the closest value, instead of always doing a straight up `floor` or `ceil`. > > For example, let's say I calculate a size as `3.0000001`; ceiling this (with snapSize) to `4` is quite ridiculous; obviously `3` was intended, but the ceiling function won't care. But what if we subtracted a value (assuming we're dealing with pixels of course, which the `snap` functions are)? We could bias it slightly towards the correct value by using something ridiculously small like 1/10000th of a pixel. For example: > > `3.0000001` - 1/10000th of a pixel = `2.9999`. Ceiling this value yields the intended `3`. We could work much safer with near snapped values, as there is much less risk of a one ulp difference being dramatically amplified by floor/ceil functions. > good point! > > This is exactly the reason for the code in ScaledMath:71 > > ``` > return Math.ceil(d - Math.ulp(d)) / scale; > ``` Yeah, but I think we may want to subtract more than just 1 ulp. A one ulp difference can be created after any operation (like add/subtract). Do two of these without resnapping, and the difference will be >1 ulp) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976048373 From jhendrikx at openjdk.org Fri Feb 28 22:11:57 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 28 Feb 2025 22:11:57 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 21:14:54 GMT, Andy Goryachev wrote: >> I just copied the style that was being used, but can make any changes desired of course (at the expense of increasing the diff and amount of code to review). > > I know it's a general policy not to do unrelated changes or reformatting, but I think in this case > a) it's a test and > b) you already touched it > so might as well. I can do this, but realize that the test is large, and there's comments like this in multiple places, also places I didn't touch. So, I can fix it here locally, resulting in this method standing out from the rest, or I can do this everywhere causing this PR to have a lot of non-changes that reviewers will need to be aware of and ignore. Normally I would do this by marking a commit as a "refactor" commit, in which functionality changes are prohibited, and so reviewers only need to look for changes that jump out as not just a minor refactor / rename / move. However, in the JDK repositories this isn't so easily done, and such commits are not retained (it is squashed together with functional commits), and so to keep them separated you must make a new ticket, new PR, and get new buy-in to get it included. I'm really trying to avoid to make a commit too large to review and drown out the functional changes with cosmetic changes, even though every time I touch code like `CssStyleHelper` it itches to remove redundant checks or give fields/variables more descriptive names. Even the changes I did in Region I was already questioning if this wouldn't be too much (there is more that I would have liked to change there, but I refrained as I fear this will just make it too hard to review). I face a similar dilemma with HBox/VBox modifications... do I do the same modifications twice (for the sake of reviews) or do I introduce an `AbstractBox`, remove all duplicate code, and then apply the modifications there, ensuring that it will be almost impossible to review and seeing what I actually changed... What we really need IMHO is a way to include refactors with functional changes. In my day job, we do this by having a specific commit order; we have one or a couple of commits that do minor cleanups or refactors -- no functionality is changed in these commits, leading to quick and easy reviews of those changes. Then the final commit (we force push to keep commits clean and focused during reviews -- the review tooling we use handles this without any problem) contains **only** the functional changes which, thanks to the earlier refactors, are often tiny changes that just change some parameters or add a function or two -- no noise, and reviewers can focus purely on functionality. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976060714 From angorya at openjdk.org Fri Feb 28 22:57:56 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 22:57:56 GMT Subject: RFR: 8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin [v4] In-Reply-To: References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com> Message-ID: On Fri, 28 Feb 2025 21:09:37 GMT, Andy Goryachev wrote: >> - enforced fx application thread >> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show() >> - clarified `ComboBoxBase::show` >> - added a headful test `TestThreadingRestrictions` > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Created https://bugs.openjdk.org/browse/JDK-8350976 for the MenuBarSkin. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2691682516 From angorya at openjdk.org Fri Feb 28 23:10:57 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 23:10:57 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v2] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 22:09:19 GMT, John Hendrikx wrote: >> I know it's a general policy not to do unrelated changes or reformatting, but I think in this case >> a) it's a test and >> b) you already touched it >> so might as well. > > I can do this, but realize that the test is large, and there's comments like this in multiple places, also places I didn't touch. So, I can fix it here locally, resulting in this method standing out from the rest, or I can do this everywhere causing this PR to have a lot of non-changes that reviewers will need to be aware of and ignore. > > Normally I would do this by marking a commit as a "refactor" commit, in which functionality changes are prohibited, and so reviewers only need to look for changes that jump out as not just a minor refactor / rename / move. However, in the JDK repositories this isn't so easily done, and such commits are not retained (it is squashed together with functional commits), and so to keep them separated you must make a new ticket, new PR, and get new buy-in to get it included. > > I'm really trying to avoid to make a commit too large to review and drown out the functional changes with cosmetic changes, even though every time I touch code like `CssStyleHelper` it itches to remove redundant checks or give fields/variables more descriptive names. Even the changes I did in Region I was already questioning if this wouldn't be too much (there is more that I would have liked to change there, but I refrained as I fear this will just make it too hard to review). I face a similar dilemma with HBox/VBox modifications... do I do the same modifications twice (for the sake of reviews) or do I introduce an `AbstractBox`, remove all duplicate code, and then apply the modifications there, ensuring that it will be almost impossible to review and seeing what I actually changed... > > What we really need IMHO is a way to include refactors with functional changes. In my day job, we do this by having a specific commit order; we have one or a couple of commits that do minor cleanups or refactors -- no functionality is changed in these commits, leading to quick and easy reviews of those changes. Then the final commit (we force push to keep commits clean and focused during reviews -- the review tooling we use handles this without any problem) contains **only** the functional changes which, thanks to the earlier refactors, are often tiny changes that just change some parameters or add a function or two -- no noise, and reviewers can focus purely on functionality. I think the main concern with the reformatting/tangentially related changes coming from the maintainers is the general pain associated with conflicts created when merging and backporting. In this case, I think we might be ok, specifically in the tests. I would rather see the cleaner and more maintainable code, even at the small additional expense. Up to you. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976103486 From angorya at openjdk.org Fri Feb 28 23:13:56 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 23:13:56 GMT Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4] In-Reply-To: References: <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com> Message-ID: On Fri, 28 Feb 2025 21:52:36 GMT, John Hendrikx wrote: >> Come to think of it, most the issues here are caused by using functions like `floor` and `ceil`. It might be an idea to change these functions to bias them slightly towards rounding to the closest value, instead of always doing a straight up `floor` or `ceil`. >> >> For example, let's say I calculate a size as `3.0000001`; ceiling this (with snapSize) to `4` is quite ridiculous; obviously `3` was intended, but the ceiling function won't care. But what if we subtracted a value (assuming we're dealing with pixels of course, which the `snap` functions are)? We could bias it slightly towards the correct value by using something ridiculously small like 1/10000th of a pixel. For example: >> >> `3.0000001` - 1/10000th of a pixel = `2.9999`. Ceiling this value yields the intended `3`. We could work much safer with near snapped values, as there is much less risk of a one ulp difference being dramatically amplified by floor/ceil functions. > >> good point! >> >> This is exactly the reason for the code in ScaledMath:71 >> >> ``` >> return Math.ceil(d - Math.ulp(d)) / scale; >> ``` > > Yeah, but I think we may want to subtract more than just 1 ulp. A one ulp difference can be created after any operation (like add/subtract). Do two of these without resnapping, and the difference will be >1 ulp) I think you are onto something here. It almost feels like we shouldn't be doing ceil/floor at all, rounding to the closest pixel instead. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1976105122 From angorya at openjdk.org Fri Feb 28 23:44:08 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Feb 2025 23:44:08 GMT Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v7] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 11:30:50 GMT, Alexander Zuev wrote: >> Create implementation for Slider and Stepper accessibility protocols. >> Fix mapping. >> Fix performAction parameter type in declaration. > > Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Add accessibilityTitleUIElement function to the base class. > - Merge branch 'master' into JDK-8313556 > - Merge pull request #13 from openjdk/master > > Merge > - Merge pull request #12 from openjdk/master > > Merge > - Merge pull request #11 from openjdk/master > > Merge > - Merge pull request #10 from openjdk/master > > Merge > - Adding accessibilityMinValue and accessibilityMaxValue > - Merge remote-tracking branch 'origin/master' into JDK-8313556 > - Merge pull request #7 from openjdk/master > > Merge > - - Added accessibilityTitle method > - Removed some debug output generation > - ... and 4 more: https://git.openjdk.org/jfx/compare/7a7854c9...09f68099 With Slider, it announces the current value as "percent" (of the working envelope?), even though the min/max can be arbitrary. Is this intentional? Also, for Spinner, it says "Stepper", is this expected? macOS 15.3.1 M1 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2691724439