RFR: 8359599: Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells [v6]
Kevin Rushforth
kcr at openjdk.org
Tue Nov 4 18:37:46 UTC 2025
On Thu, 30 Oct 2025 08:11:34 GMT, Marius Hanl <mhanl at openjdk.org> 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:
>
> add copyright
Thanks for adding the perf test. I verified that without this fix (current master branch), the performance of "refresh" and "recreate" are the same (unsurprisingly). With this fix, "refresh" is measurably faster.
I did not review most of the code changes and will rely on others to do that. At least one of the other reviewers will need to re-review.
-------------
Marked as reviewed by kcr (Lead).
PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3418137577
More information about the openjfx-dev
mailing list