0.47 very slow or freezes when combing complex paths (ctrl + k)

[marcel]

I am working with complex paths.
Theses paths orginate from a 3D-Cadra model saved as pdf from SolidWorks.
I open the pdf with inkscape.

When I break a path (consisting of around 2000 or more objects) apart (Ctr+shift+k) everything is fine.
When I combine the objects (around 2000 or more) to a single path again Inkscape 0.47 is very very slow or freezes.
0.46 is fine, within seconds it can combine 2000 or more objects.

(Windows XP)

[marcel (marcel-tippmann)]

this shows part of a 3D model consisting of 2 paths:

path a: 3921 nodes

path b: 21527 nodes

[su_v (suv-lp)]

reproduced with Inkscape 0.46-2 and 0.47-1 on OS X 10.5.8,
hardware: MBP 15", Intel Core 2 Duo 2.4 GHz, 2GB RAM

After breaking apart one of the paths in 'example.svg', combining all segments again into a single path takes a lot more computing resources and time in Inkscape 0.47 than compared to Inkscape 0.46 but it doesn't freezes (crash) Inkscape 0.47 on my system.

[su_v (suv-lp)]

I had added the 'renderer' tag because I see (known) rendering glitches depending on zoom level with the original (large) paths that disappear after breaking apart and grouping each of the two paths. It seems however unrelated to the reported performance issue with 'Ctrl+K'.

[Diederik van Lierop (mail-diedenrezi)]

Probably not related, but I also see additional horizontal lines at some zoom levels (see attached screen shot). These lines disappear when zooming in.

Using today's Inkscape revision on Fedora 12

[Diederik van Lierop (mail-diedenrezi)]

Fixed as of revision 8927 & 8928! The path combining code was rewritten in this revision

http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/4981

In this new code the selection was cleared only after all paths had been deleted, instead of before like it used to be. This invoked an update of the selection each time an object was deleted, i.e. about 2200 unnecessary updates. (I discovered this using gprof)

After the fix Inkscape takes about 15 seconds on my pc to combine the paths, incl. refreshing of the drawing. Before the fix it took about 3 minutes.

BTW: I cannot reproduce the horizontal lines I mentioned earlier

[su_v (suv-lp)]

fix confirmed with Inkscape 0.47+devel r8928 custom on OS X 10.5.8:

Fixed:
- Combining 2'235 paths (resulting in a single path with 21'527 nodes) is at least as fast as in Inkscape 0.46 (compared by running Inkscape 0.46 and 0.47+devel side-by-side).

Still present:
- Rendering errors at certain zoom levels: see attached screenshot at zoom level 100%. I see the same rendering error with Inkscape 0.46 at 100% (similar issues have been reported before).
- Overall slow performance in handling complex paths with many nodes (e.g. dragging and selecting&de-selecting). This hasn't changed since Inkscape 0.46.

[Diederik van Lierop (mail-diedenrezi)]

About the slow rendering performance: I believe that's mainly caused by the Shape class in src/livarot/shape.cpp. Unfortunately, that class is hardly documented at all with even part of the comments in French. Maybe it takes a complete re-write of that code.

I've attached the profiling data, taken after the fix mentioned above. The profiling session consisted of opening the complex file, having it rendered, combining its paths, and having it rendered again. If you dive into these profiling data then you'll notice that lots of time is spend in Shape::ConvertToShape, which is apparently needed to do nr_arena_shape_update_stroke and _fill.

                0.11 2.65 835/4133 nr_arena_shape_update_fill(NRArenaShape*, NRGC*, NRRectL*, bool) [32]
                0.42 10.47 3298/4133 nr_arena_shape_update_stroke(NRArenaShape*, NRGC*, NRRectL*) [4]
[5] 46.6 0.53 13.13 4133 Shape::ConvertToShape(Shape*, fill_typ, bool) [5]
                0.11 2.05 145199/145199 Shape::CheckAdjacencies(int, int, Shape*, int) [51]
                0.00 2.00 4007/4007 Shape::SortPointsRounded() [60]
                0.38 1.27 4007/4007 Shape::GetWindings(Shape*, Shape*, bool_op, bool) [70]
                0.10 1.31 145199/145199 Shape::CheckEdges(int, int, Shape*, Shape*, bool_op) [81]
                0.02 1.19 1552384/1552384 Shape::TesteIntersection(SweepTree*, Side, bool) [87]
                0.24 0.88 4007/4007 Shape::AssembleAretes(fill_typ) [90]
                0.02 1.01 605692/605692 Shape::SubEdge(int) [93]
                0.07 0.74 145199/145199 Shape::AssemblePoints(int, int) [113]
                0.04 0.20 737489/1107268 Shape::AddPoint(Geom::Point) [165]
                0.07 0.13 1106488/1106488 Shape::AddChgt(int, int, Shape*&, int&, Shape::sTreeChangeType, Shape*, int, Shape*, int) [236]
                0.06 0.10 4007/4007 Shape::initialiseEdgeData() [266]
                0.00 0.14 368642/368642 SweepEventQueue::extract(SweepTree*&, SweepTree*&, Geom::Point&, double&, double&) [276]
                0.00 0.13 77319/77319 SweepTree::Insert(SweepTreeList&, SweepEventQueue&, Shape*, int, bool, bool) [298]
                0.05 0.04 11774509/200165037 Shape::getEdge(int) const [78]

[su_v (suv-lp)]

Between revision 8924 and 8928 s small regression was introduced when combining paths: the last of the selected paths to combine is additionally added as separate path on top of the combined path (i.e. it is appended in the node list as seen in the XML Editor).

to reproduce:
1) create a text object "12345"
2) convert it to path, ungroup, keep selection
3) combine
4) drag a selection window around the combined path: 2 paths
5) select the bigger path, move it down
6) break it apart, keep selection
7) combine
8) drag a selection window around the combined path: 2 paths
...
alternately (depending on z-order of the 'broken-apart' paths) the left-most or right-most character is duplicated.

@Diederik - could it be that this is caused by your fix committed in rev 8927 or should I better file a separate report? I noticed it first in a current build (r8941) but had older builds still around to verify that it doesn't happen with r8924 but does with r8928.

possibly related to these changes for Inkscape 0.47:
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Converting_text_to_path_produces_a_group>
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Combine_works_on_groups>
though it happens both when combining a group of or a selection set of individual paths.

[jazzynico (jazzynico)]

Regression confirmed on Ubuntu 9.10, Inkscape 8945.

[Diederik van Lierop (mail-diedenrezi)]

I will look into this, but it might take a few days because my Inkscape
source is currently not a in compilable state (due to some heavy
refactoring of the snapping API)

[Diederik van Lierop (mail-diedenrezi)]

Fixed as of rev. #8961. It was indeed caused by my recent work.

Thanks for paying attention!