Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-61763

QTreeView updates slow down with increasing delay if scrollToBottom is used

    XMLWordPrintable

Details

    • 2672a9a767909eab04ec6706bdef8a891a8f3d21

    Description

      When populating a large TreeView there is gradually worsening performance issue as the treeview is getting larger. I attached the test app for reproducing the issue. (treeupdatetest.tar.gz)
      In top of the window there is a text that helps in detecting the performance problem.
      On a normal run (uniform row heights or no scroll to bottom), first 7 updates to the text look like this:

      2000 ms (diff 0 ms), inserted 0%, tree rows: 594
      2001 ms (diff 1 ms), inserted 0%, tree rows: 1194
      2000 ms (diff -1 ms), inserted 0%, tree rows: 1794
      2000 ms (diff 0 ms), inserted 0%, tree rows: 2394
      2000 ms (diff 0 ms), inserted 0%, tree rows: 2994
      2000 ms (diff 0 ms), inserted 0%, tree rows: 3594
      2000 ms (diff 0 ms), inserted 0%, tree rows: 4194

      On a failing run they look like this:

      2000 ms (diff 0 ms), inserted 0%, tree rows: 594
      2103 ms (diff 102 ms), inserted 0%, tree rows: 1194
      3045 ms (diff 942 ms), inserted 0%, tree rows: 1794
      4170 ms (diff 1125 ms), inserted 0%, tree rows: 2394
      5321 ms (diff 1151 ms), inserted 0%, tree rows: 2994
      6448 ms (diff 1127 ms), inserted 0%, tree rows: 3594
      7682 ms (diff 1234 ms), inserted 0%, tree rows: 4194

      Legend for the print:

      • The first number is the time it took for 100 timer expires to be handled (20ms timer, this should always be 2000ms).
      • Second number is the difference to previous time it took for 100 timer expiries (this should always be 0ms).
      • Third number is the current progress of waiting for the 100th expiry to occur.
      • Last number is the number of rows in the model.
        The delay is not only longer when neither of the workarounds are used, but the delay also increases by about 1150ms on every time 100 additions have been done. Eventually the delay grows into several seconds and the UI becomes unusable.

      The test app adds new items to end of the list and keeps the focus at the end of list. In short the code for updating is:
          beginInsertRows(QModelIndex(), parents.size(), parents.size() + lines.count());
          /* append children here */
          endInsertRows();

          treeView->scrollToBottom();

       

      Please note: 

      • If we don't do the scrollToBottom(), the updates happen in constant time, regardless of the amount of items.
      • If we set "treeView->setUniformRowHeights(true)", the updates happen in constant time, regardless of the amount of the items.

      However for software with height items and focus on bottom of list (e.g. a news group reader with preview line(s), neither workaround can be used.

      Since uniform row heights fixes the increasing delay problem, I assume that after the update the row height data is no longer cached for the already existing items (the ones that were not added), although the data should be in cache as the area of change is given and already existing list does not get changed.

      Attachments

        For Gerrit Dashboard: QTBUG-61763
        # Subject Branch Project Status CR V

        Activity

          People

            chehrlic Christian Ehrlicher
            ottoryynanen Otto Ryynänen
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes