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

8089589: [ListView] ScrollBar content moves toward-backward during scrolling. #398

Closed
wants to merge 8 commits into from

Conversation

johanvos
Copy link
Collaborator

@johanvos johanvos commented Feb 9, 2021

This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589)
The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive.
Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change.
This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8089589: [ListView] ScrollBar content moves toward-backward during scrolling.

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/398/head:pull/398
$ git checkout pull/398

Update a local copy of the PR:
$ git checkout pull/398
$ git pull https://git.openjdk.java.net/jfx pull/398/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 398

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/398.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 9, 2021

👋 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.

@johanvos johanvos changed the title [WIP] 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. Feb 15, 2021
@openjdk openjdk bot added the rfr Ready for review label Feb 15, 2021
@mlbridge
Copy link

mlbridge bot commented Feb 15, 2021

Webrevs

@kevinrushforth
Copy link
Member

/reviewers 2

@openjdk
Copy link

openjdk bot commented Feb 16, 2021

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

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 reviewed the code, and tested this, both using automated tests and various manual tests, and it looks good to me. In addition to the simple test attached to the bug report, I can reproduce the bug with HelloTableView and the HorizontalListView sample of Ensemble8.

HelloTableView

  1. Run HelloTableview program
  2. Sort by first name
  3. Slowly scroll down by dragging the thumb
    BUG: the scrolling jitters slightly when you reach the taller row (Jacob Smith Smith Smith)

Ensemble8

  1. Run Ensemble8 and select HorizontalListView sample
  2. Scroll all the way to the right
  3. Slowly scroll to the left by dragging the thumb
    BUG: the scrolling jitters slightly when you reach the wider row (Long Row 3)

All three test cases run fine with the fix.

I left a few inline questions and comments (mostly about code style w.r.t., inline whitespace, and a couple typos).

return (int) (getPosition() * getCellCount());
double total = 0;
int currentCellCount = getCellCount();
double estSize = estimatedSize/currentCellCount;
Copy link
Member

Choose a reason for hiding this comment

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

MInor: missing spaces before and after /

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

changed

}
// Make sure we have enough space in the cache to store this index
while (idx >= itemSizeCache.size()) {
itemSizeCache.add(itemSizeCache.size(), null);
Copy link
Member

Choose a reason for hiding this comment

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

Can this be simplified to itemSizeCache.add(null);?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That won't add enough elements. For example, in case idx = 10, and the itemSizeCache has 5 elements, we need to add 5 empty elements to the cache, as they might get queried/pushed, e.g. we might do
itemSizeCache.set(7, 123.45);

Copy link
Member

Choose a reason for hiding this comment

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

Sure, that's why you need the while loop. What I meant is that the following two calls are equivalent for any list:

    list.add(list.size(), null);

and

    list.add(null);

@johanvos
Copy link
Collaborator Author

Thanks for the review. I answered the questions, and corrected the styling errors.

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.

Thanks for the explanations about the algorithm. I have no more questions on the logic.

I think Ajit will review this later this week.

Btw, I did another pass over the code and noted a few more formatting inconsistencies (missing spaces).

if (viewportLength >= estimatedSize) {
setPosition(0.);
} else {
setPosition(absoluteOffset/(estimatedSize - viewportLength));
Copy link
Member

Choose a reason for hiding this comment

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

Minor: spacing

Copy link
Collaborator

@aghaisas aghaisas left a comment

Choose a reason for hiding this comment

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

Code changes are OK. I have noted a few minor comments.

@openjdk
Copy link

openjdk bot commented Apr 16, 2021

@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:

8089589: [ListView] ScrollBar content moves toward-backward during scrolling.

Reviewed-by: kcr, 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 44 new commits pushed to the master branch:

  • 05ab799: 8208088: Memory Leak in ControlAcceleratorSupport
  • e8689fe: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0
  • c8384a1: 8264928: Update to Xcode 12.4
  • 808b107: 8260245: Update ICU4C to version 68.2
  • d808dd1: 8258663: Fixed size TableCells are not removed from sene graph when column is removed
  • 28475cb: 8263807: Button types of a DialogPane are set twice, returns a wrong button
  • cc94e96: 8217955: Problems with touch input and JavaFX 11
  • 9796a83: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock
  • 5898858: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set
  • e63931e: 8262366: Update glib to version 2.66.7
  • ... and 34 more: https://git.openjdk.java.net/jfx/compare/d4058a181a16615d604582f95d4fc2be6bda98ab...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 Apr 16, 2021
@johanvos
Copy link
Collaborator Author

/integrate

@openjdk openjdk bot closed this Apr 16, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Ready to be integrated labels Apr 16, 2021
@openjdk openjdk bot removed the rfr Ready for review label Apr 16, 2021
@openjdk
Copy link

openjdk bot commented Apr 16, 2021

@johanvos Since your change was applied there have been 44 commits pushed to the master branch:

  • 05ab799: 8208088: Memory Leak in ControlAcceleratorSupport
  • e8689fe: 8265031: Change default macOS min version for x86_64 to 10.12 and aarch64 to 11.0
  • c8384a1: 8264928: Update to Xcode 12.4
  • 808b107: 8260245: Update ICU4C to version 68.2
  • d808dd1: 8258663: Fixed size TableCells are not removed from sene graph when column is removed
  • 28475cb: 8263807: Button types of a DialogPane are set twice, returns a wrong button
  • cc94e96: 8217955: Problems with touch input and JavaFX 11
  • 9796a83: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock
  • 5898858: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set
  • e63931e: 8262366: Update glib to version 2.66.7
  • ... and 34 more: https://git.openjdk.java.net/jfx/compare/d4058a181a16615d604582f95d4fc2be6bda98ab...master

Your commit was automatically rebased without conflicts.

Pushed as commit 8e54757.

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

// When the position is changed explicitly, we need to make sure
// the absolute offset is changed accordingly.
adjustAbsoluteOffset();
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems to violate the invariant setPosition(...)positionProperty().set(...).

Your comment indicates that this is by design, but how do you prevent people from invoking positionProperty().set(...) and getting a different behavior?

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
Development

Successfully merging this pull request may close these issues.

4 participants