Description
With each feature the UI feels a bit slower when many cells are visible. I thought it was caused by the overhead of the default implementation which calls the model.data method many times (once per role * number of visible cells), but after experimenting a lot with this, progressively turning off features, it turns out that even with a custom delegate with a custom paint method (which can choose to only ask the model for the displayRole -- or even, for the sake of the experiment, not call it at all), it still does not feel as responsive as I would like. eg. adding this method to our ArrayDelegate:
def paint(self, painter, option, index):
painter.save()
# set background color
painter.setPen(QPen(Qt.NoPen))
if option.state & QStyle.State_Selected:
painter.setBrush(QBrush(Qt.blue))
else:
painter.setBrush(QBrush(Qt.white))
painter.drawRect(option.rect)
# set text color
if index.isValid():
painter.setPen(QPen(Qt.black))
value = index.data(Qt.DisplayRole)
painter.drawText(option.rect, Qt.AlignLeft, value)
painter.restore()
returnHere is an unordered mind dump of all I did for the last 1.5 days:
-
the stylesheet is the main culprit of the slow down
-
using another graphics engine does not really help (Qt4 supports native (default), raster and opengl).
_app.setGraphicsSystem("native") # default
_app.setGraphicsSystem("raster")
_app.setGraphicsSystem("opengl")This does not work on Qt5 (cannot be set) where I think opengl is the default anyway
-
running with Qt4 seems a bit faster than Qt5 but still sluggish.
-
running the program with the NVidia processor (I have a dual GPU on my laptop) instead of the integrated graphics chip (default) does not help.
-
QTableView is known to be slow for a large number of visible cells. rolling our own table might be an option: https://stackoverflow.com/questions/19691577/qtableview-slow-performance-with-1000s-of-visible-cells
-
alternatively, we could reimplement the paintEvent method of QTableView which I suppose would fix the problem but would make it easier to support edition.
-
some people suggest using QML instead, but I don't see how that would be faster.
-
Using an Opengl canvas (as in: https://doc.qt.io/archives/qq/qq26-openglcanvas.html) was also suggested by some to make things faster, but I doubt it would help given that I think qt5 does this by default.
-
We could implement "fixed" rows/columns using a single QTableView/model as long as we scroll one cell at a time. It would be a bit tedious to map positions of "visible" cells with real cells, but we will need similar tricks when we implement the "buffer" thing (a la ViTables) and I am starting to think it would be less painful than what we are currently doing.
-
the sluggish scrollbar seems to be almost independent of the keyboard scrolling speed. It might be caused by the synchronisation of the different TableView (though I didn't test this!). Isn't the scrollbar sending a change event which changes the second view scrollbar position, which in turn sends an event to the first scrollbar? This might be avoidable by using some kind of timer.