[go: up one dir, main page]

Improve Layers and Objects dialog performance

Fixes #3176 (closed), but for Inkscape 1.3-dev, in which the problem became worse, in my opinion. A comment from the issue with some call statistics and code review: #3176 (comment 1317373568)

As far as I understood, the problem is that on every desktop "selection changed" event the dialog gets fully rebuilt. Some operations, like ungrouping, undoing, converting to paths e.t.c., emit the "selection changed" event per every object and with a lot of objects this could lead to hanging-alike situations.

Mike (@mkov) suggested a solution to defer update on selection change to idle event. Which is what this MR does. Seems like it's working, but testing is required, of course. Documentation for Glib::signal_idle().connect() / .connect_once() says that the functions are not thread safe. There's also some priority parameter which I do not know how to handle, set it to my preference.

The selected parameter of ObjectsPanel::selectionChanged(Selection *selected) is not used anymore since DialogBase::getSelection() returns the same objects, as it seemed to me.

Results:

My test file consists of 1600 rectangles which I convert to paths with Layers and Objects dialog open. Here I give a before-after comparison.

ObjectsPanel methods call chain in call order:

Before this patch
Frame Method name Calls Time spent, %
5 selectionChanged() 1610 0.06
4 unpackToObject() 1285600 0.12
3 cleanDummyChildren() 1285601 0.12
2 removeDummyChildren() 1285601 0.06
1 hasDummyChildren() 1285600 15.10
0 isDummy() / getRepr() 2059529605 45.95
After this patch
Frame Method name Calls Time spent, %
- selectionChanged() 1608 0.00
5 _selectionChanged() 6 0.00
4 unpackToObject() 3200 0.00
3 cleanDummyChildren() 3201 0.00
2 removeDummyChildren() 3201 0.00
1 hasDummyChildren() 3200 0.00
0 isDummy() / getRepr() 6407203 0.00

Zero time doesn't mean the operation finished instantaneously :) It is still slower than without the dialog, but this time only about x3 times (vs x60 as before), have not measured the exact timings though.

Edited by Christian Rohlfs

Merge request reports

Loading