RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]

Johan Vos jvos at openjdk.java.net
Sun May 8 18:59:54 UTC 2022


On Mon, 25 Apr 2022 09:00:54 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> I agree with that observation. The mathematical perfect situation would be to pre-calculate the height of all items, so that the scrolbar position can be exact, and the content placing can be exact as well. That would be at the price of a major performance overhead for large lists. For small lists, this overhead is more acceptable.
>> 
>> I agree that this is something that could be rather application-defined instead of having heuristics in the ListView. 
>> 
>> As a historical note, before https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed, all items were considered of equali height for the position of the scrollbar. In the current case, if that precondition holds, the estimated size will be the real size, so in that case there is no need to calculate the height of every item before getting the correct total size.
>> This is again something the application knows best -- even with non-fixed cell heights, the expected variations might be small enough and if they are randomly spread, the estimate will soon be "good enough".
>
> @johanvos 
> As requested, we've made a unit test, which tests this bug.
> It's based on your test and our original test class. It can be added to the ListViewTest.
> You can find it, in the JDK ticket.
> 
> Btw, adding the cells incrementally seems to make a difference - which is why the new test class tests both cases.
> 
> It accepts various inputs of cell sizes - and should work with any inputs.
> It should catch all the cases from the original test class.
> Because it works with all possible inputs - one could even make a random test-cases generator to make sure it works in every case.
> 
> It basically only works well, when the sizes are only 20s - in most other cases it fails.

The later reported issues were due to the fact that the estimatedSize got updated during the layoutChildren call. That makes things much more complicated and leads to discrepancies. I disabled the updates to the estimated size during the layoutChildren call, so that all operations that are happening in that call are using a consistent value of the estimated size. We now pass all the tests added by @FlorianKirmaier on the JBS issue . Those tests are great regression tests.

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

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


More information about the openjfx-dev mailing list