Redundant TableView updates.

Formally it is not a bug, but probably something that is done inaccurately and it can be really frustrating for UI developers like me.

TableView in my sample app displays N,K - M in its cells, where N - column number, K - row number and M - the number of times the models data() method was called with Display role. When I randomly drag the content of this TableView with mouse cursor the cells that stay visible are not updated (their data() method is not called):

but when I add a new row at the end of the table that is far beyond the visible range and reflect the changes with beginInsertRows / endInsertRows all the visible cells are updated with the same effect as if beginResetModel() / endResetModel() is called.

What are this redundant updates for? Why not to update the cells that are really affected? Ideally data() method with Display role should be called only when an invisible row becomes visible or when dataChanged() signal is emitted, but not when the layout changed, right?

Also, for example, beginMoveRows()/endMoveRows() do not require data() method to be called at all if the rows being moved are visible before and after the move, right?

The delegates are reused, but redundant rebinding them to new values still affects the performance, right?

In my real-life app beginMoveRows() and beginEraseRows() also update all the visible cells, but not the rows they affect. The app displays some real-time list of about 2000 rows that are actively sorted and when its main window is resized to the full screen it starts to consume 15% CPU on my Windows 10 machine with Intel i7, but with disabled sorting in TableView it consumes only 2% CPU. The workaround is to call beginResetModel() / endResetModel() once a second and do not call beginMoveRows() at all and let the user see the changes with 1 second delay.