On Thu, 14 Apr 2022 08:52:27 GMT, Johan Vos <j...@openjdk.org> wrote:
>> Johan Vos has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Don't shift cells if we are already showing the lowest index cell. > > 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. ------------- PR: https://git.openjdk.java.net/jfx/pull/712
