RFR: 8351368: RichTextArea: exception pasting from Word
The original code used String attribute keys. I'd like to backport this fix to jfx24u. - Commit messages: - fix Changes: https://git.openjdk.org/jfx/pull/1731/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1731&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351368 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1731.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1731/head:pull/1731 PR: https://git.openjdk.org/jfx/pull/1731
Re: RFR: 8342565: [TestBug] StubTextLayout [v9]
On Thu, 6 Mar 2025 16:21:52 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 incrementally with one additional > commit since the last revision: > > Revert "fixed bad merge" > > This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa. Nice Improvement for the tests and utilizing the existing abstraction of the layout code. - Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2665852619
Re: RFR: 8351368: RichTextArea: exception pasting from Word
On Thu, 6 Mar 2025 23:16:41 GMT, Andy Goryachev wrote:
> The original code used String attribute keys.
>
> I'd like to backport this fix to jfx24u.
This is a simple enough fix that a single reviewer should be sufficient.
modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/rtf/RTFReader.java
line 787:
> 785: Object stype = defined.getAttribute(STYLE_TYPE);
> 786: Map toMap;
> 787: if (STYLE_SECTION.equals(stype)) {
Since this is a marker object, should it be `==` rather than `.equals`? They
are equivalent, so it's up to you.
-
Marked as reviewed by kcr (Lead).
PR Review: https://git.openjdk.org/jfx/pull/1731#pullrequestreview-2665858008
PR Review Comment: https://git.openjdk.org/jfx/pull/1731#discussion_r1984190205
Re: RFR: 8342565: [TestBug] StubTextLayout [v2]
On Tue, 4 Feb 2025 08:53:31 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/6ed82938...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_`). > 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. thank you @Maran23 - PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2705176354
RFR: 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed
8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed - Commit messages: - Add test case - Prevent redundant compute value calls Changes: https://git.openjdk.org/jfx/pull/1730/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1730&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351276 Stats: 145 lines in 3 files changed: 138 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1730.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1730/head:pull/1730 PR: https://git.openjdk.org/jfx/pull/1730
Re: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v7]
On Thu, 6 Mar 2025 03:08:58 GMT, Nir Lisker wrote: > I tested the new convergence check. If listener A and listener B fight over a > value, it works, but if I add after then listener C that just prints what it > sees without changing the value, it completes without an error. > > Is it not possible to let the SOE be thrown naturally (by infinite recursion)? Not without breaking one of the rules. I can't get infinite recursion if I'm not calling the change listener that is causing it. I'd have to call it either with `oldValue == newValue` (breaks Rule 2) or `badOldValue + sameNewValue` (breaks Rule 1 which is what `ExpressionHelper` does). We can of course discuss this, but I think no `ChangeListener` is interested to be called with `oldValue == newValue` in edge cases. It probably wouldn't require special logic on their parts though, so it could be considered. The nasty case of adding/removing listeners to maintain a chain like node->scene->window would not break when both values are equal. > > Note that the non-convergence detection logic is pretty smart, as the test > > case where multiple listeners are trying to agree upon a value that is > > divisible by 3, 5, 7 and 11 still works fine > > And what about non-integer values, like custom objects or strings? I fail to see how this would make a difference. The test case demonstrates what happens if multiple listeners have non-conflicting rules defined, and it is not rejected just because multiple listeners are making changes, as long as they eventually reach an agreement. Doing this with any other values should work just as well as long as there **exists** a solution (and the listeners at least make some effort to resolving it). If there is no solution, or some listeners are just resetting values back, then there is no hope that it will ever converge. So a listener that requires even values and another that requires uneven values -> no solution. A listener that requires even values and one that requires positive values -> solution possible. - PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2703223673
Re: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v7]
On Thu, 6 Mar 2025 03:08:58 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix docs > > I tested the new convergence check. If listener A and listener B fight over a > value, it works, but if I add after then listener C that just prints what it > sees without changing the value, it completes without an error. > > Is it not possible to let the SOE be thrown naturally (by infinite recursion)? > >> Note that the non-convergence detection logic is pretty smart, as the test >> case where multiple listeners are trying to agree upon a value that is >> divisible by 3, 5, 7 and 11 still works fine > > And what about non-integer values, like custom objects or strings? @nlisker I've fixed the edge case you found -- thanks very much for finding it; the extra listener would overwrite the progress value and so the aborted nested loop would go undetected. I added an additional test case to cover this. - PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2703325887
Re: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v8]
> 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 edge case with non-convergence detection - Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/8e198cdb..dd714266 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=06-07 Stats: 112 lines in 2 files changed: 79 ins; 16 del; 17 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
Integrated: 8313556: Create implementation of NSAccessibilitySlider protocol
On Tue, 29 Aug 2023 10:10:54 GMT, Alexander Zuev wrote: > Create implementation for Slider and Stepper accessibility protocols. > Fix mapping. > Fix performAction parameter type in declaration. This pull request has now been integrated. Changeset: c7091e1f Author:Alexander Zuev Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/c7091e1f57503e68c578ec890a4945a74d2d2978 Stats: 276 lines in 6 files changed: 273 ins; 0 del; 3 mod 8313556: Create implementation of NSAccessibilitySlider protocol 8313558: Create implementation of NSAccessibilityStepper protocol Reviewed-by: arapte, angorya - PR: https://git.openjdk.org/jfx/pull/1226
Re: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v9]
> 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: Simplified overly complicated non-convergence logic - Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/dd714266..6608d3ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=07-08 Stats: 91 lines in 2 files changed: 16 ins; 62 del; 13 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
Re: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v10]
> 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 docs - Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/6608d3ba..5470edb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081
Re: RFR: 8342565: [TestBug] StubTextLayout [v6]
On Wed, 5 Mar 2025 15:54:49 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 24 additional
> commits since the last revision:
>
> - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
> - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
> - 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
> - ... and 14 more: https://git.openjdk.org/jfx/compare/302a3dce...3650989a
Code looks good to me, some minor convention related things from my side.
modules/javafx.controls/src/test/addExports line 38:
> 36: --add-exports=javafx.graphics/com.sun.javafx.menu=ALL-UNNAMED
> 37: --add-exports=javafx.graphics/com.sun.javafx.text=ALL-UNNAMED
> 38:
minor: extra added newline here
modules/javafx.graphics/src/main/java/com/sun/javafx/text/GlyphLayoutManager.java
line 43:
> 41: public class GlyphLayoutManager {
> 42: private static GlyphLayout reusableGL = newInstance();
> 43: private static final AtomicBoolean guard = new AtomicBoolean(false);
if we follow the java standard, then this should be named `GUARD`
modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayoutFactory.java
line 34:
> 32:
> 33: public class PrismTextLayoutFactory implements TextLayoutFactory {
> 34: private static final PrismTextLayoutFactory factory = new
> PrismTextLayoutFactory();
Again, if we want to follow the practise this should be uppercase
modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayoutFactory.java
line 37:
> 35: /* Same strategy as GlyphLayout */
> 36: private static final TextLayout reusableTL = factory.createLayout();
> 37: private static final AtomicBoolean guard = new AtomicBoolean(false);
same here
-
Marked as reviewed by mhanl (Committer).
PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2664025448
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983109268
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983105350
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983107627
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983107282
Re: RFR: 8345261: Refactor the Dimension2D classes
On Thu, 6 Mar 2025 02:50:33 GMT, Nir Lisker wrote: > The int-based Dimension is only used by Rectangle even if in another class I've taken another look. Rectangle is not using this class at all. I think it would be much better to give the GTK screencast logic its own little int/int record (not necessarily called anything like dimension). Just define it package private or as an inner type of `TokenItem`. This code really has no relation at all to the rest of FX (it is even GTK specific). Alternatively (which may be even better), avoid the creation of a dimension and just call `hasAllScreensOfSameSize(dimensions)` with the actual rectangles and have `TokenItem` figure it out using that information. As for the `float` version of `Dimension2D`, I think we don't need this. Just use the `double` one; everything in FX is doubles, and to be honest, the conversion we sometimes do to floats is a precision loss risk. So, if it is up to me: - Don't create any new dimension types; FX uses doubles, down casting to floats is not without risk. Int variants are not needed in core FX code. - Have TokenItem accept Rectangles in its `hasAllScreensOfSameSize` function. I think you can change the logic to avoid creating a dimension class at all, or you can make a tiny `record ScreenSize(int w, int h)` defined as an inner class or even method class to do what it is currently doing. - Delete `com.sun.javafx.geom.Dimension` completely - PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2703192504
Re: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v5]
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 @arapte Can you be the second reviewer? - PR Comment: https://git.openjdk.org/jfx/pull/1645#issuecomment-2705036479
Re: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11]
> 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 non-convergence logic one more time... - Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/5470edb3..5863932f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=09-10 Stats: 149 lines in 2 files changed: 114 ins; 23 del; 12 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
Re: RFR: 8342565: [TestBug] StubTextLayout [v9]
> 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 incrementally with one additional commit since the last revision: Revert "fixed bad merge" This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa. - Changes: - all: https://git.openjdk.org/jfx/pull/1667/files - new: https://git.openjdk.org/jfx/pull/1667/files/0e9e8ee6..e18e49a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=07-08 Stats: 41 lines in 2 files changed: 13 ins; 0 del; 28 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
Re: RFR: 8342565: [TestBug] StubTextLayout [v8]
> 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 incrementally with one additional commit since the last revision: fixed bad merge - Changes: - all: https://git.openjdk.org/jfx/pull/1667/files - new: https://git.openjdk.org/jfx/pull/1667/files/1c4e5a80..0e9e8ee6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=06-07 Stats: 41 lines in 2 files changed: 0 ins; 13 del; 28 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
