On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl <mh...@openjdk.org> wrote:

>> This PR fixes the horizontal virtualization performed in the 
>> `TableRowSkinBase`, which significantly improves performance with many 
>> columns (and thus many cells). Scrolling up and down as well as scrolling 
>> left and right feels much more snappy.
>> 
>> In order to do that, there are multiple things needed:
>> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the 
>> `VirtualFlow` into account, not the `TableView`. Since rows are inside the 
>> `VirtualFlow`, we need to use the width from there
>>   - The wrong implementation right now leads to 
>> [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you 
>> scroll to the right with many columns, cells on the left start to be empty 
>> (since they are removed when they should'nt be)
>>   - It also does not help performance when scrolled to the left, as the 
>> right cells are not removed (only when scrolling to the right, cells on the 
>> left are removed)
>> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored 
>> to take in everything that is needed directly, without reiterating through 
>> all columns
>> - As before, the `TableRow` adds or removes cells that are visible or not. 
>> Note that this is only done when a fixed cell size is set. 
>> The reason for that is that we always know the row height. If not set, we 
>> need all cells so we can iterate over them to get the max height. I'm not 
>> sure if this can be improved, but this is not the goal of this PR and can be 
>> checked later
>> - The other issue mentioned in 
>> [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when 
>> a fixed cell size is set (empty rows). This is related and also fixed:
>>   - Cells start to be empty when scolling around a lot. This is because 
>> cells that are in the pile (ready to be reused) will not receive any layout 
>> requests (`requestLayout`) while all cells in the viewport will receive 
>> them. As soon as they are reused, they are visually outdated and not 
>> updated, leading to empty cells
>>   Fix is to request layout to those cells as well, and as soon as they are 
>> reused, they will layout themself
>>   - This has revealed another error: Cells that are not used anymore (added 
>> to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as 
>> children). This will cause them to actually do the layout when requested, 
>> and especially when the height of the `TableView` changed drastically (e.g. 
>> from 50 visible cells to just 10), we have 40 cells laying around, receiving 
>> the layout request I added to fix [JDK-82763...
>
> Marius Hanl has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR. The pull request contains one new 
> commit since the last revision:
> 
>   8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal 
> direction

By the way, a Tree/TableView with 500 columns is barely usable - locks up the 
UI giving me a macOS spinning beach ball quite often.  Not that it's a 
reasonable use case.  200 is ok.  May be the 500 case can be used for profiling?

Speaking of the vertical scrolling - I could not use the idea implemented by 
the VirtualFlow in the RichTextArea as it won't work in the case of very large 
models.  So instead it uses approximation, see
https://github.com/openjdk/jfx/blob/7ed4e6ed1c20e9b32766c987b465a7c24dd0c8ad/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L665

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2520640684

Reply via email to