8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction

[Maran23]

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, 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 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, as mentioned above

  The fix is to remove those cells from the viewport when not needed anymore.
  NOTE: The VirtualFlow does a lot of 'clean up everything and decide which cells are visible', so I chose a performant fix (instead of removing all cells and readding them again)
  NOTE2: This makes the logic to make cells invisible and visible again obsolete. This was there so those unused cells laying around in the VirtualFlow does not receive any Mouse or KeyEvents. This can be cleaned up in a follow up PR

Considerations:

• I decided to not do more logic like batching all cells that should be removed (removeAll), as the scenario that mostly happens is:
  • You start scrolling to the right, we add and remove cells one by one
  • Therefore, we mostly do not remove or add multiple cells at once anyway
• Other bigger refactoring for performance can be done in a follow up (if we find things, I do not want to blow up this PR)

Testing:

• I added many tests to cover all possible scenarios, including:
  • Reordering a column
  • Decrease/Increase column width
  • Adding and removing columns
  • Scrolling around and checking, that no empty cells are around (JDK-8276326)
• I did lots of testing on my own and also on JavaFX applications. I found no regression
• Some tests need to be adjusted since the fix also improves TreeTableRow code, which before added LabeledText sometimes (from LabeledSkinBase), although it was not needed, leading to code that need to count that particular node in, in some tests
• Remove VirtualFlowTestUtils.BLOCK_STAGE_LOADER_DISPOSE which was hacky and replaced it with the normal StageLoader mechanism (as we use pretty much everywhere else)

/issue add JDK-8276326

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issues

• JDK-8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction (Bug - P3)
• JDK-8276326: Empty Cells in TableView supposedly after using setFixedCellSize() (Bug - P4)
• JDK-8252566: TreeTableView: broken row layout for fixedCellSize (Bug - P3)

Reviewers

• Andy Goryachev (@andy-goryachev-oracle - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1644/head:pull/1644
$ git checkout pull/1644

Update a local copy of the PR:
$ git checkout pull/1644
$ git pull https://git.openjdk.org/jfx.git pull/1644/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1644

View PR using the GUI difftool:
$ git pr show -t 1644

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1644.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mhanl! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@Maran23
Adding additional issue to issue list: 8276326: Empty Cells in TableView supposedly after using setFixedCellSize().

[mlbridge]

Webrevs

• 02: Full (b6b38e43)
• 01: Full - Incremental (e8115729)
• 00: Full (62f46c62)

[openjdk]

@Maran23 Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[andy-goryachev-oracle]

/reviewers 2

[openjdk]

@andy-goryachev-oracle
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[kevinrushforth]

We will need to check that this doesn't impact accessibility, since there are some "interesting" cases where cells are requested and a layout pass is done even when they aren't visible.

@arapte As I recall, you were looking into VirtualFlow in connection with an a11y at one point. Can you test this?

[kevinrushforth]

@johanvos You may want to take a look since this touches VirtualFlow.

[Maran23]

/issue add JDK-8252566

same issue as https://bugs.openjdk.org/browse/JDK-8276326, but for the TreeTableView

[openjdk]

@Maran23
Adding additional issue to issue list: 8252566: TreeTableView: broken row layout for fixedCellSize.

[Maran23]

We will need to check that this doesn't impact accessibility, since there are some "interesting" cases where cells are requested and a layout pass is done even when they aren't visible.

Good point! Checking getPrivateCell, I wonder why we do not use the accumCell here, we rather add a cell into the sheet (although it is not visible) and return it. With the changes made in this PR, this cell will be cleaned up later. So worth checking!

[arapte]

@arapte As I recall, you were looking into VirtualFlow in connection with an a11y at one point. Can you test this?

I tested the PR changes with a few a11y scenarios, and did not observe any issues.

[andy-goryachev-oracle]

there seems to be a merge conflict, please sync up with the latest master branch.

[andy-goryachev-oracle]

Testing on macOS 14.7.1 with the latest Monkey Tester (where I've added 200 columns case for Tree/TableView,
https://github.com/andy-goryachev-oracle/MonkeyTest )
looks good.

It feels like the horizontal scrolling has improved a bit, the vertical exhibits the same slight hiccups as with the master branch.

[andy-goryachev-oracle]

I've got an exception on the TreeTableView page in the monkey tester after clicking a cell and then pressing control+command+RIGHT_ARROW with the VoiceOver on:

Exception in thread "JavaFX Application Thread" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 1
	at javafx.graphics/com.sun.glass.ui.mac.MacAccessible.accessibilityArrayAttributeValues(MacAccessible.java:1135)

settings:

UPD: seems unrelated, the issue can be reproduced with the master branch.

UPD2: the problem seems to be with the MenuBar. In the monkey tester, press option key with the VoiceOver on, this triggers the MT window menu bar. The issue can also be seen by switching to the MenuBar page and simply clicking on the Menu1. This might be related to JDK-8235989 though the symptoms are different.

[kevinrushforth]

I've got an exception on the TreeTableView page in the monkey tester after clicking a cell and then pressing control+command+RIGHT_ARROW with the VoiceOver on:

Is this reproducible? Does it happen without this fix? If this is a regression then it needs to be fixed.

UPDATE: nm, I just read Andy's updated comment.

[andy-goryachev-oracle]

Created JDK-8235989 for the a11y exception issue.

[Maran23]

It feels like the horizontal scrolling has improved a bit, the vertical exhibits the same slight hiccups as with the master branch.

Yes, especially if you try with many columns (> 100), scrolling up and down is much faster (especially when scrolled completely to the left). When you scroll completely to the right, it is just a little bit faster than master.

I have also some ideas how to improve vertical scrolling with many items, but for another day. :)

[Maran23]

I tested the PR changes with a few a11y scenarios, and did not observe any issues.

Thank you for testing!
Out of interesting, is it 'enough' to test with the Narrator application on Windows 11?

[openjdk]

@Maran23 this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout 8185887-virtualization
git fetch https://git.openjdk.org/jfx.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[andy-goryachev-oracle]

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

jfx/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java

Line 665 in 7ed4e6e

public void handleVerticalScroll() {

[Maran23]

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?

With fixed cell size, it seems okay to me. How is your table configured?

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.

There is a lot of stuff that can improved in the VirtualFlow. Most of the modern table components all use fixed cells or have some kind of dynamic height calculation logic. They only rely on calculating the size themself when it really needs to (e.g. the developer turning it on).

You can for example check AG-Grid, which is a pretty nicely implemented table that is very fast and has a nice API design:
https://www.ag-grid.com/javascript-data-grid/row-height/
They also do not recommend setting the auto height, and also explain the side effects (cells and scroll bar jumping).

We only have the fixed cell size implemented, but it is not the default (and too late to change). This helps a lot since the math is very easy then.
For something like the RichTextArea, this might be more complex, so I can see why the VirtualFlow does not fit. It is more complex as a Table, where you most likely know the height in advance.

[johanvos]

I checked the changes in VirtualFlow and those are ok.
In general, we need a better approach to test and quantify performance, but realistically that should not be done as part of this PR. There are some tests in ListViewTest and TableViewTest that are based on the number of invocations of updateItem() (which is in most cases a good indication of performance), but they are mainly ad-hoc.

In absence of those tests, I believe this PR is a good step in the good direction.

[andy-goryachev-oracle]

looks good, thanks!

scrolling performance is not an issue: the horizontal one has improved, and the vertical one is on par with the master.