Von: "John Hendrikx" <john.hendr...@gmail.com>
An: openjfx-dev@openjdk.org
Betreff: Re: List scrolling is very slow in JavaFX 17
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
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.- JohanOn Tue, Nov 22, 2022 at 9:24 AM Glavo <zjx001...@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:I wonder if this is a bug?Best regards,
Glavo
