Hi Craig, That boils down to the same issue I described earlier in this thread, and that is also mentioned on https://bugs.openjdk.org/browse/JDK-8280442. I agree the workaround does not look pretty (I suggested it myself), but the fact that it works is not by accident. There is indeed a difference between calling updateItem on a visible versus an invisible cell. The boilerplate code required by the developer to distinguish between those cases should be avoided. We can do that by e.g. passing an additional boolean to the updateItem method, indicating if this is the accumCell or not. But the signature of `updateItem(Object, boolean)` is already hard to explain, especially combined with the requirement that `super.updateItem(...)` must be called.
- Johan On Tue, Nov 22, 2022 at 1:22 PM Craig Raw <craig...@gmail.com> wrote: > I encountered the same problem and described my solution here: > https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034764.html > > It's not pretty but it does seem to work. > > On Tue, Nov 22, 2022 at 1:18 PM Glavo <zjx001...@gmail.com> wrote: > >> We created an advanced list with titles, subtitles, icons, and tags, and >> updated these contents in the updateItem. >> >> I took a screenshot of it and uploaded it as a comment to GitHub next to >> the relevant code: >> >> >> https://github.com/huanghongxun/HMCL/pull/1849/commits/4f8cde63acf959d85416b706acf22f9b3c80ec63#r1029184905 >> >> It worked well in the past, but in JavaFX 17, it was so slow that it >> blocked the UI thread for a few seconds, making the operating system think >> that the program did not respond.‘ >> >> I improved the updateItem to make it ten times faster, but even so, it is >> still not as smooth as before, and there will be an obvious FPS drop. >> >> If possible, please check our code on GitHub through the above link. >> >> It is difficult to continue to optimize the updateItem method. Even if I >> use a Map to cache nodes created for elements, it will not become faster. >> Are we using it in the wrong way? >> >> On Tue, Nov 22, 2022 at 4:48 PM Johan Vos <johan....@gluonhq.com> 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 >>>> >>>>
