You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
defpaint(self, painter, option, index):
painter.save()
# set background colorpainter.setPen(QPen(Qt.NoPen))
ifoption.state&QStyle.State_Selected:
painter.setBrush(QBrush(Qt.blue))
else:
painter.setBrush(QBrush(Qt.white))
painter.drawRect(option.rect)
# set text colorifindex.isValid():
painter.setPen(QPen(Qt.black))
value=index.data(Qt.DisplayRole)
painter.drawText(option.rect, Qt.AlignLeft, value)
painter.restore()
return
Here 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).
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.
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.
The text was updated successfully, but these errors were encountered:
In any case, to make it faster than what we currently have with the stylesheet problem fixed, we need a benchmark. For that, I think creating a test array that is larger than the screen then move by emulating continuous keypress events (down arrow) and time how long it takes to reach the end of the array seems like a good test. We could also make the same test using PageDown (but I guess that would give the same kind of information).
Uh oh!
There was an error while loading. Please reload this page.
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:
Here 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).
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.
The text was updated successfully, but these errors were encountered: