Thanks, David. I'm primarily seeing pauses when switching ME display
modes, particularly with the new ones I've added in my FR branches. I'll
see if I can come up with a recreatable example using only note names in
master.
Ironically I have made some small changes (in my branches) to reuse
QSettings instances instead of creating new ones, but they were all at
startup or mode switch, not during scrolling. It wasn't a performance
issue, just seemed like the right thing to do.
I'll try profiling to see if the topics I asked about are the cause of
the slowdowns I've noticed. On the other hand, even if not, shouldn't I
be following "best practices" anyway? If calling
QGraphicsScene::removeItem(item) before "delete item" is recommended,
why not add that one extra line? If keeping large numbers of hidden
items is known to have an impact, regardless how small, and removing
them doesn't involve trade-offs like the ones I speculated about, I'd
tend to factor that into the new code I'm writing.
On 3/27/22 1:57 PM, David Faure wrote:
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
--
MARK
markr...@yahoo.com
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
