Rule number 1 of optimizing performance is to run a profiler in order to find out what is slow.
Since you referenced FR#489 I opened a .rg file, opened the matrix editor and enabled View / Show Note Names. Scrolling left/right isn't actually slow on my machine, but this uses quite some CPU so I profiled that operation using hotspot (https://github.com/KDAB/hotspot/). The main reason why this operation uses lots of CPU is the following: LoopRuler::paintEvent() and others call GUIPalette::getColor() which *creates* a QSettings object every time. That's slow, it means parsing one or multiple config files from disk! The QSettings instance should be kept around. Apart from this, it all seems fine, actually. Can you give me a .rg file where you see "unacceptable performance", together with instructions on how to trigger that? Then I can give you another profiling result. But better fix that QSettings usage first :-) Cheers, David. On dimanche 27 mars 2022 21:29:42 CEST mark_at_yahoo via Rosegarden-devel wrote: > I have some questions regarding the above subject line, directed towards > anyone who'd care to offer advice. I ask because I'm seeing unacceptable > (to me) performance in the Matrix Editor with compositions containing a > large number of notes. (I run on a very fast system and imagine it would > be far worse on less capable hardware.) The questions are particularly > applicable to the code I've written to implement feature requests #501 > and #503 and am currently writing for #500, but regardless whether those > will eventually be merged into the master branch, the issues also apply > to the existing codebase, particularly FR #489. > > I've researched these topics online and haven't found any definitive > answers, or in fact many at all. I apologize if my poor search skills > are to blame. > > 1) Qt documentation explicitly states: > > https://doc.qt.io/qt-5/qgraphicsitem.html#dtor.QGraphicsItem > QGraphicsItem::~QGraphicsItem() > Destroys the QGraphicsItem and all its children. If this item is > currently associated with a scene, the item will be removed from > the scene before it is deleted. > Note: It is more efficient to remove the item from the > QGraphicsScene before destroying the item. > > This is not currently being done in the Matrix Editor. Is the > performance hit for not doing so significant? This applies not only to > destructing large numbers of MatrixElements when an ME is closed, but > more importantly if they are going to be dynamically created and > destroyed, pending answers to the following questions. > > > 2) QGraphicsItem::hide() vs QGraphicsScene::removeItem(QGraphicsItem *item) > > Is having a large number of hidden items in a scene a performance hit? > I'm guessing that if they're kept in a separate list and not tested for > QGraphicsView visibility the answer is "no", but I don't know if that's > the case. > > I came across: > > > https://forum.qt.io/topic/41184/solved-qgraphicsscene-clear-delete-items/10 > Asperamanca May 13, 2014, 2:56 AM > If all you really want to do is hiding and showing them, then > just call hide() and show(), and leave them in the scene. Adding > and removing items (and especially widgets!) from a scene is a > pretty expensive operation. > > If that's true (or still true, see "2014" above) and hidden items *do* > slow down rendering, then obviously the two factors need to be weighed > against each other. In the case of small numbers of items that will be > re-shown later it's obviously one answer, and for large numbers that > likely will not it's another. Also, the removeItem() and addItem() hit > happen very infrequently compared to constant panning/zooming view changes. > > > 3) > When doing a large number of addItem() calls, is it worthwhile to consider: > > https://doc.qt.io/qt-5/qgraphicsview.html#ViewportUpdateMode-enum > enum QGraphicsView::ViewportUpdateMode > > https://doc.qt.io/qt-5/qgraphicsview.html#viewportUpdateMode-prop > viewportUpdateMode : ViewportUpdateMode > > https://doc.qt.io/qt-5/qgraphicsview.html#updateScene > QGraphicsView::updateScene(const QList<QRectF> &rects) > > In the default QGraphicsView::MinimalViewportUpdate mode, are the > visibility tests and redrawing done after each addItem()? If so, is it > worth switching to QGraphicsView::NoViewportUpdate before adding the > items and then doing an explicit updateScene() and restoring > MinimalViewportUpdate afterwards? > > > Thanks for any feedback. Yes, I'm both an optimization nutjob, and > largely focused on the Matrix Editor (which is my primary use for RG). > > > _______________________________________________ > Rosegarden-devel mailing list > Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
