Details
-
Suggestion
-
Resolution: Unresolved
-
Not Evaluated
-
None
-
6.7.2
-
None
Description
When using a QSortFilterProxyModel to proxy some source model it will convert all move operations on the source model into layoutChange operations internally:
When using a QML ListView with a QSortFilterProxyModel model it will re-create every visible delegate every time a move operation is detected because of this layoutChange logic. This can cause significant jank if the delegates are expensive to instantiate.
I've attached a simple test project using a QStandardItemModel and a QSortFilterProxyModel exposed to QML to demonstrate this issue.
It includes two buttons, one will move the rows the other will move the rows but by removing and then inserting to avoid any rowsAboutToBeMoved signals. Notice how the move button causes all the visible ListView delegates to be recreated whereas removing and inserting only re-creates the newly inserted row.
One solution here might be to handle move operations as remove / insert operations in QSortFilterProxyModel as that appears to work better (at least with QMLs ListView). I would be curious to hear if there would be any downsides to that approach. Obviously properly handling move operations would be the ideal solution if possible.