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

[Johan Vos]

On Fri, 9 Apr 2021 22:27:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 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.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2883:
> 
>> 2881:         double newPosition = Math.min(1.0d, absoluteOffset/(estimatedSize - viewportLength));
>> 2882:         // estimatedSize changes may result in opposite effect on position
>> 2883:         // in that case, modify current position 1% in the requested direction
> 
> Have you done testing to show that a 1% adjustment is a good heuristic?

This is just a visual aid, so it's hard to test. I tried this with both small and large lists. We really don't want to jump in the wrong direction, but on the other hand, moving too much in the "correct" dimension would increase the discrepancy between where we really are in the list versus where we expected to be, given the information we had before this modification. If we increase this to 10%, the mismatch will be even bigger, and might be visually noticed. 

The 1% is a compromis between the UI going crazy (backward) and the mathematical correctness (which would go backward). I initially had this to 0% but then there would be no visual change, while we want to give the user some visual confirmation about the direction she is moving. 
With both small/large lists, this 1% occurs "natural" to me. The lower, the better, but if we change less than 1 pixel, there won't be a visual effect.

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

PR: https://git.openjdk.java.net/jfx/pull/398