Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8252811

The list of cells in a VirtualFlow is cleared every time the number of items changes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: openjfx11, openjfx15
    • Fix Version/s: openjfx16
    • Component/s: javafx
    • Labels:

      Backports

        Description

        When new items are constantly added to a TableView control, the calls to com.sun.javafx.binding.ExpressionHelper.removeListener() (that is part of https://bugs.openjdk.java.net/browse/JDK-8185886 and https://github.com/openjdk/jfx/pull/108) are triggered by the change of the number of cells in VirtualFlow::setCellCount.

        This happens every time the number of items in the TableView control changes, as the VirtualFlow keeps track of the number of virtual cells (cellCount is the total number of items) while the number of actual cells or number of visible nodes used is given by sheetChildren.size().

        This means that all the actual cells (usually 5 to 20 nodes) that are used by the VirtualFlow are disposed and recreated all over again every time the number of items changes, triggering all those calls to unregister those nodes from the scene that ultimately lead to remove the listeners with ExpressionHelper.removeListener.

        This seems unnecessary, as the number of actual cells/nodes doesn't change that much and the VirtualFlow manages to update them properly, however, it causes very bad performance and high CPU usage.

        This issue should explore the option of removing the call to:

        sheetChildren.clear();

        taking care of a possibly very old comment:

        // Fix for RT-13965: Without this line of code, the number of items in
        // the sheet would constantly grow, leaking memory for the life of the
        // application. This was especially apparent when the total number of
        // cells changes - regardless of whether it became bigger or smaller.

        If we could get some information about RT-13965, we might see if it is something to be taken into account or not.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                jpereda Jose Pereda
                Reporter:
                jpereda Jose Pereda
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: