List scrolling is very slow in JavaFX 17

[John Hendrikx]

I took a quick look, I didn't see any Node creation, the updateItem 
calls look pretty normal (setting some labels and a list of tags).

I downloaded the application and installed the application (it's nicely 
packaged) and clicked on "download" which shows the problematic list.  
It indeed performs badly (10 fps orso), even when showing only about 100 
items (of which 6 were visible at a time).  All items are the same 
height.  When turning on another option (snapshots) there are probably 
1000 items or more, still showing at most 6 at a time and FPS drops to 
like 2 or 3; I'd consider it pretty unusable.  It doesn't seem to 
improve after a while either.

I don't like the fact that it seems to get slower with more items in the 
list, but still only 6 showing at a time.

Is there a description somewhere of how the current implementation 
works?   Is it trying to get the sizes of all cells (eventually) to make 
an accurate scroll bar representation?  I don't quite see how that could 
possibly work without querying all cells, as a single cell could be 
large enough to influence the scroll bar size and position significantly 
even among thousands of items...

Thinking further, once a list passes a certain size, the scrollbar thumb 
will be at its minimum size, there is little point to try to get the 
exact relative sizes of position and knob then that may require 
information on all cells. Does the implementation have an option to 
switch to a more simplistic scrollbar representation (1 cell = 1 
position, regardless of size) when the number of visible cells are 
vastly outnumbered by the total number of items?

The fixedCellSize property probably will alleviate the performance 
problems, but I find it hard to use as generally I only know that my 
cells are all the same size, but I don't know what that size actually is 
as it depends on the styles used.

--John

On 22/11/2022 09:48, Johan Vos wrote:
> Hi Glavo,
>
> There are more frequent calls to updateItem() since the VirtualFlow 
> tries to gradually improve its estimation how large the total list 
> size is (rather than assuming all cells have the same size). The major 
> point is that if you override updateItem, it should not do more than 
> strictly needed (e.g. don't create a Node etc). That method should 
> return as fast as possible.
>
> There are many completely different usecases for VirtualFlow in 
> general, and it's not trivial to come up with a single implementation 
> that deals "best" with all usecases. Therefore, I recently 
> solicited for feedback and it might be good if you can give yours too?
> See 
> https://mail.openjdk.org/pipermail/openjfx-dev/2022-September/035851.html 
> for the start of the discussion.
>
> - Johan
>
>
> On Tue, Nov 22, 2022 at 9:24 AM Glavo <zjx001202 at gmail.com> wrote:
>
>     Hi,
>
>     I'm one of the maintainers of the open source project HMCL (Hello!
>     Minecraft Launcher/)/. This is a Minecraft launcher based on JavaFX.
>
>     In the past year, we have received a lot of feedback on
>     performance problems. Through performance analysis, I noticed that
>     from JavaFX 17 ea+8, the performance of list scrolling is terrible.
>
>     I analyzed the method calls and noticed that the updateItem method
>     of ListCell is called 8 times more frequently in JavaFX 17 than in
>     JavaFX 16.
>
>     I guess this is due to the following commit:
>
>     https://github.com/openjdk/jfx/commit/8e547571fb3d40df843c27fc11921b5d4765c481
>
>     I wonder if this is a bug?
>
>     Best regards,
>     Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20221122/0d22982d/attachment.htm>