Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> 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 shift cells if we are already showing the lowest index cell.
I don't believe that it is possible to position the content and scrollbar
**exactly**, if the VirtualFlow **estimates** the size of the cells.
For that case we need an external cell size provider, that I, as an application
developer, can provide to the e.g. ListView.
I thought of something like this. The existing estimation logic can then be
implemented as a default cell size provider.
interface CellSizeProvider {
/**
* Returns the size of all cells.
* IMPORTANT: Be carefully by implementing this method. It can drastically
degrade the performance of a component.
*/
double getTotalSize();
/**
* Returns the size of the cell for an item given by its index.
* IMPORTANT: Be carefully by implementing this method. It can drastically
degrade the performance of a component.
*/
double getCellSize(int);
/**
* The callback which is set by the VirtualFlow. It allows to calculate the
cell size for an item given by its index.
* IMPORTANT: This callback returns the exact value, but it may be slow.
*/
void setCellSizeCalculator(Function cellSizeCalculator);
}
-
PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> 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 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". - PR: https://git.openjdk.java.net/jfx/pull/712
