On Mon, 13 Oct 2025 12:28:42 GMT, Marius Hanl <[email protected]> wrote:
>> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`,
>> `TableView`, `TreeTableView`), all cells will be recreated completely,
>> instead of just refreshing them.
>>
>> This is because `recreateCells()` of the `VirtualFlow` is called when
>> `refresh()` was called. This is not needed, since refreshing the cells can
>> be done much cheaper with `rebuildCells()`.
>>
>> This will reset all cells (`index = -1`), add them to the pile and fill them
>> back in the viewport with an index again. This ensures `updateItem()` is
>> called.
>>
>> The contract of `refresh()` is also a big vague, stating:
>>
>> Calling {@code refresh()} forces the XXX control to recreate and repopulate
>> the cells
>> necessary to populate the visual bounds of the control.
>> In other words, this forces the XXX to update what it is showing to the
>> user.
>> This is useful in cases where the underlying data source has changed in a
>> way that is not observed by the XXX itself.
>>
>>
>> As written above, recreating is not needed in order to fulfull the contract
>> of updating what is shown to the user in case the underlying data source
>> changed without JavaFX noticing (e.g. calling a normal Setter without any
>> Property and therefore listener involved).
>>
>> ----
>>
>> Benchmarks
>> -
>>
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>>
>> Code is in `tests/performance`.
>>
>> Calling `refresh()` with a `Button` press.
>>
>> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH
>> JDK-8370498 |
>> | - | - | - | - | - |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
>> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
>> | Init | 2 ms | 6 ms | 6 ms | - |
>> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms ->
>> 0ms |
>> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms ->
>> 0ms |
>> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms ->
>> 0ms |
>> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms ->
>> 0ms |
>
> Marius Hanl has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Improve javadoc
I was confused when rerunning the benchmarks because suddenly I got 3
`layoutChildren` calls without the fix.
Turns out that this is due to the fix made in
https://github.com/openjdk/jfx/pull/1879 (JDK-8360940).
I made new benchmarks and edited the description:
Before fix & without JDK-8360940 | Before fix (master) | With fix | With fix &
with JDK-8370498 |
| - | - | - | - |
It looks like with https://github.com/openjdk/jfx/pull/1945, the startup got a
bit faster (which I think might be expected since we can save unnecessary
layouts)
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3464739632
