> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes.
Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Don't recalculate estimated size while doing a layout cycle. There are a number of paths possible that first calculate an offset/position, and later do a layoutChildren pass. The offset/position calculations (e.g. in scrollTo calls) assume a specific estimatedSize. If that size is changed between the first call and the layoutChildren logic, the result will not look as intended. Hence, we should avoid updating the estimated size at the start of the layout phase. We can do it safely at the end. Thanks to Zeiss and Florian Kirmaier for providing additional tests. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/2b1b4bdc..aa08ba26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=712&range=03-04 Stats: 116 lines in 2 files changed: 115 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
