Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8277785: ListView scrollTo jumps to wrong location when CellHeight is changed #808

Closed
wants to merge 4 commits into from

Conversation

johanvos
Copy link
Collaborator

@johanvos johanvos commented Jul 4, 2022

In order to fix the issues reported in JDK-8089589, the VirtualFlow now uses the real sizes of the elements that are displayed. This allows for a more natural way of scrolling through lists that contain items of very different sizes.
The algorithm that is used, does not calculate the size of each individual cell upfront, as that would be a major performance overhead (especially for large lists). Instead, we estimate the total size and the size of the individual cells based on the real measured size of a (growing) number of cells.

There are a number of key variables that depend on this estimated size:

  • position
  • aboluteOffset
  • currentIndex

As a consequence, when the estimated size is changing, the absoluteOffset may change which may lead to a new currentIndex. If this happens during a layout phase, or a "complex" operation (e.g. scroll to an item and select it), this may lead to visually unexpected artifacts. While the rendering becomes more "correct" when the estimated size is improving, it is more important that we do not create visual confusion.

The difficulty is that there are a large number of ways to manipulate the VirtualFlow, and different entry points may have different expectations about which variables should be kept constant (or only changed gradually).

In this PR, we focus on consistency in the scrollTo method, where we want to keep the top-cell constant. In case the estimated size is improved during the scrollTo execution, or the next layoutChildren invocation, this implies keeping the result of computeCurrentIndex() constant so that after scrolling to a cell and selecting it, the selected cell is indeed the one that is scrolled to.

This PR contains a number of tests for this scrollTo behaviour, that should also be considered as regression test in case we want to add more invariants later.


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)

Issue

  • JDK-8277785: ListView scrollTo jumps to wrong location when CellHeight is changed

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 808

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

Using diff file

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

… and currentIndex

are all subject to change when the total estimated size of the entire list is changing.
Improvements in the estimated size should not lead to sudden changes during the layout
phase.
@bridgekeeper
Copy link

bridgekeeper bot commented Jul 4, 2022

👋 Welcome back jvos! 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 openjdk bot added the rfr Ready for review label Jul 4, 2022
@mlbridge
Copy link

mlbridge bot commented Jul 4, 2022

Webrevs

@mstr2
Copy link
Collaborator

mstr2 commented Jul 4, 2022

The proposed PR also fixes the issue with setPosition described here.

@kevinrushforth
Copy link
Member

/reviewers 2

@openjdk
Copy link

openjdk bot commented Jul 5, 2022

@kevinrushforth
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).

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix looks good to me, although I did leave a question about one of the boundary checks. This will need additional testing. Several of the assertEquals calls have the expected and actual args backwards. I also left a few minor formatting comments (I didn't note all of them).

@johanvos
Copy link
Collaborator Author

johanvos commented Jul 7, 2022

The fix looks good to me, although I did leave a question about one of the boundary checks. This will need additional testing. Several of the assertEquals calls have the expected and actual args backwards. I also left a few minor formatting comments (I didn't note all of them).

I did a reformat on the sections that you mentioned. Doing a reformat with NetBeans on the whole file would cause too many changes that would hide the real changes, so that is probably a bit too much?

@kevinrushforth
Copy link
Member

I did a reformat on the sections that you mentioned. Doing a reformat with NetBeans on the whole file would cause too many changes that would hide the real changes, so that is probably a bit too much?

Perfect (and yes, I prefer to only reformat the sections being modified).

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noted a couple more assertEquals calls where it looks like the expected and actual are backwards. The rest looks good. I'll finish my testing tomorrow.

Reverse expected and actual args in some tests.
@FlorianKirmaier
Copy link
Member

I've retested this version of the PR, and I can confirm, that it fixes the bug in the real-world application! So no regression happened when moving to the new PR! So great work!

Not sure whether the first two tests are still necessary.
The tests I wrote, basically used these test as a template and tried to generalize/parametrize it. But I guess more tests don't do any harm.

There are 2 issues, we shouldn't forget about after this PR:

1.) In my original tests I had a snippet which is removed in this version. I still think the test is correct but it fails. So we should investigate it.

// After clicking, the cells shouldn't move
listView.getSelectionModel().select(scrollToIndex);
listView.requestLayout();
Toolkit.getToolkit().firePulse();
assertEquals("Upper cell shouldn't move after changing heights and clicking", previousLayoutY, scrollToCell.getLayoutY(), 1.);

2.)
In the previous PR we reported issues when scrolling after jumping to an index - including a video. As discussed with Johan we would like to investigate this further after this PR.

@kevinrushforth
Copy link
Member

I think you missed one place where the assertEquals args are backwards. See #808 (comment)

I'll do final testing today, but so far everything looks good.

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@openjdk
Copy link

openjdk bot commented Jul 12, 2022

@johanvos This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8277785: ListView scrollTo jumps to wrong location when CellHeight is changed

Reviewed-by: kcr, fkirmaier, aghaisas

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 18 new commits pushed to the master branch:

  • eb8e9ef: 8289606: CustomSecurityManagerTest fails on Mac M1
  • b9a1ec5: 8288137: The set of available printers is not updated without application restart
  • 0132ac8: 8284676: TreeTableView loses sort ordering when applied on empty table
  • 8d5d3ca: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses
  • 437c078: 8289255: update Eclipse .classpath and other configuration files
  • 13f3e1f: 8289395: Fix warnings: Varargs methods should only override or be overridden by other varargs methods
  • c7d3fd9: 8283402: Update to gcc 11.2 on Linux
  • cbb53b2: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build
  • 187fbe1: 8289381: Fix warnings: The assignment to variable has no effect
  • 60c75b8: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue
  • ... and 8 more: https://git.openjdk.org/jfx/compare/b3eca1f64977343c06e6035fab385935055b6d6b...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Ready to be integrated label Jul 12, 2022
if (needsRecreateCells) {
lastWidth = -1;
lastHeight = -1;
releaseCell(accumCell);
// accumCell = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intentional or did you may forgot to add back this two lines of code?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intentional -- it was already moved to comments, and there is no need to destroy the accumCell (releasing it is what we need)

@johanvos
Copy link
Collaborator Author

/integrate

@openjdk
Copy link

openjdk bot commented Jul 14, 2022

Going to push as commit b8302f6.
Since your change was applied there have been 18 commits pushed to the master branch:

  • eb8e9ef: 8289606: CustomSecurityManagerTest fails on Mac M1
  • b9a1ec5: 8288137: The set of available printers is not updated without application restart
  • 0132ac8: 8284676: TreeTableView loses sort ordering when applied on empty table
  • 8d5d3ca: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses
  • 437c078: 8289255: update Eclipse .classpath and other configuration files
  • 13f3e1f: 8289395: Fix warnings: Varargs methods should only override or be overridden by other varargs methods
  • c7d3fd9: 8283402: Update to gcc 11.2 on Linux
  • cbb53b2: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build
  • 187fbe1: 8289381: Fix warnings: The assignment to variable has no effect
  • 60c75b8: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue
  • ... and 8 more: https://git.openjdk.org/jfx/compare/b3eca1f64977343c06e6035fab385935055b6d6b...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jul 14, 2022
@openjdk openjdk bot closed this Jul 14, 2022
@openjdk openjdk bot removed ready Ready to be integrated rfr Ready for review labels Jul 14, 2022
@openjdk
Copy link

openjdk bot commented Jul 14, 2022

@johanvos Pushed as commit b8302f6.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@nicholas-os
Copy link

nicholas-os commented Jul 15, 2022

This fix seems to break TreeTableView. The tree jumps to the top when a TreeItem is expanded or collapsed. Tested with 19-ea-9. Does not happen when running the same application with 19-ea-8.

@kevinrushforth
Copy link
Member

kevinrushforth commented Jul 15, 2022

This fix seems to break TreeTableView.

A new bug has been filed to track this: JDK-8290348.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated
7 participants