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 <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:
https://github.com/openjdk/jfx/commit/8e547571fb3d40df843c27fc11921b5d4765c481
I wonder if this is a bug?
Best regards,
Glavo
