On Mon, 11 Jul 2022 13:59:36 GMT, Johan Vos <j...@openjdk.org> wrote:
>> 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. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > reverse one more expected/actual set of args. 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`. ------------- PR: https://git.openjdk.org/jfx/pull/808
