QQuickTableView: don't recalculate content width while flicking

There are now three mechanisms in TableView that works together to
ensure that the table ends up edge-to-edge with the content view. They
are applied in the following order:

1. Adjust the content size, based on the predicted size of the table.
2. Adjust the origin and endExtend on the fly, if the content size is wrong.
3. Move the table directly to where it should be, in case we don't have
    time to wait for the origin to change.

We could have, strictly speaking, setteled with just one of them, but choose
to use them all at the same time for best flicking experience. Still, 1. and
2. sometimes step on each others feet when they both detect that something is
a bit off, and adjust.

So rather than adjusting the size of the content view every time we load a
new row or column, we just keep the first prediction. And then we leave all
later ajustments to 2. and 3. This turns out to be a more stable, and will
avoid some glitches that occur when flicking using a scrollbar, if several
mechanisms kick in at the same time.

Change-Id: Ib551a0bf8f6ee59ac9b3556b9462c91adb9cc80b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
 
 
 

1 files changed, 19 insertions, 26 deletions

diff --git a/src/quick/items/qquicktableview.cpp b/src/quick/items/qquicktableview.cpp
index 2b49200eaa..9583ef4231 100644
--- a/src/quick/items/qquicktableview.cpp
+++ b/src/quick/items/qquicktableview.cpp
@@ -305,9 +305,7 @@
     \l view, which means that the table's width could be larger or smaller than
     the viewport width. As a TableView cannot always know the exact width of
     the table without loading all columns in the model, the \c contentWidth is
-    usually an estimate based on the columns it has seen so far. This estimate
-    is recalculated whenever new columns are flicked into view, which means
-    that the content width can change dynamically.
+    usually an estimate based on the initially loaded table.
 
     If you know what the width of the table will be, assign a value to
     \c contentWidth, to avoid unnecessary calculations and updates to the
@@ -324,9 +322,7 @@
     \c view, which means that the table's height could be larger or smaller than the
     viewport height. As a TableView cannot always know the exact height of the
     table without loading all rows in the model, the \c contentHeight is
-    usually an estimate based on the rows it has seen so far. This estimate is
-    recalculated whenever new rows are flicked into view, which means that
-    the content height can change dynamically.
+    usually an estimate based on the initially loaded table.
 
     If you know what the height of the table will be, assign a
     value to \c contentHeight, to avoid unnecessary calculations and updates to
@@ -1539,19 +1535,6 @@ void QQuickTableViewPrivate::processLoadRequest()
     if (rebuildState == RebuildState::Done) {
         // Loading of this edge was not done as a part of a rebuild, but
         // instead as an incremental build after e.g a flick.
-        switch (loadRequest.edge()) {
-        case Qt::LeftEdge:
-        case Qt::TopEdge:
-            break;
-        case Qt::RightEdge:
-            updateAverageEdgeSize();
-            updateContentWidth();
-            break;
-        case Qt::BottomEdge:
-            updateAverageEdgeSize();
-            updateContentHeight();
-            break;
-        }
         updateExtents();
         drainReusePoolAfterLoadRequest();
     }
@@ -1838,9 +1821,23 @@ void QQuickTableViewPrivate::layoutAfterLoadingInitialTable()
         syncLoadedTableRectFromLoadedTable();
     }
 
-    updateAverageEdgeSize();
-    updateContentWidth();
-    updateContentHeight();
+    if (syncView || rebuildOptions.testFlag(RebuildOption::All)) {
+        // We try to limit how often we update the content size. The main reason is that is has a
+        // tendency to cause flicker in the viewport if it happens while flicking. But another just
+        // as valid reason is that we actually never really know what the size of the full table will
+        // ever be. Even if e.g spacing changes, and we normally would assume that the size of the table
+        // would increase accordingly, the model might also at some point have removed/hidden/resized
+        // rows/columns outside the viewport. This would also affect the size, but since we don't load
+        // rows or columns outside the viewport, this information is ignored. And even if we did, we
+        // might also have been fast-flicked to a new location at some point, and started a new rebuild
+        // there based on a new guesstimated top-left cell. Either way, changing the content size
+        // based on the currently visible row/columns/spacing can be really off. So instead of pretending
+        // that we know what the actual size of the table is, we just keep the first guesstimate.
+        updateAverageEdgeSize();
+        updateContentWidth();
+        updateContentHeight();
+    }
+
     updateExtents();
 }
 
@@ -1856,8 +1853,6 @@ void QQuickTableViewPrivate::unloadEdge(Qt::Edge edge)
             unloadItem(QPoint(column, r.key()));
         loadedColumns.remove(column);
         syncLoadedTableRectFromLoadedTable();
-        updateAverageEdgeSize();
-        updateContentWidth();
         break; }
     case Qt::TopEdge:
     case Qt::BottomEdge: {
@@ -1866,8 +1861,6 @@ void QQuickTableViewPrivate::unloadEdge(Qt::Edge edge)
             unloadItem(QPoint(c.key(), row));
         loadedRows.remove(row);
         syncLoadedTableRectFromLoadedTable();
-        updateAverageEdgeSize();
-        updateContentHeight();
         break; }
     }