Low performance while manipulating spirograph paths

[dopelover]

Inkscape freezes for a while and consumes 100% processor time while moving or transforming paths generted by spirograph extension. The problem occurs even when I want add any element to Inkscape canvas.

This problem affects recent builds. Inkscape 0.48.2 is free of the problem. I've checked only windows builds under Windows XP.

There is a sample file attached to this report. The attachment contains one path generated by spirograph extension, so you may try to play with it.

[su_v (suv-lp)]

The reduced performance in current trunk builds is not really related to paths created with the 'Spiro Splines' live path effect itself AFAICT - it is a known issue with already moderately complex _stroked_ paths:
Remove the stroke of the path in your example and add a fill instead (just for testing): new objects can now be added and edited as fast as in the stable 0.48 version, as well as node-editing the existing one.

See also:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37154/focus=37156> (issue 2)
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37456>

Probably the same issue as reported in
Bug #844117 “Very slow when dealing with multiple objects”
<https://bugs.launchpad.net/inkscape/+bug/844117>
(unfortunately we never received feedback from the reporter of bug #844117).

[su_v (suv-lp)]

Not reproduced with Inkscape 0.48.2 (OS X 10.7.2Lion)
Reproduced with Inkscape 0.48+devel r10785 (OS X 10.7.2 Lion)

[su_v (suv-lp)]

Correction:
- created with the 'Spiro Splines' live path effect itself
- created with the 'Spirograph' extension itself

[Alvin Penner (apenner)]

- just confirming the slow response of the spirograph shape. The difference in performance between 0.48.2 and current trunk is quite amazing (in a bad way). Does not appear to be a rendering problem, since the dragged object moves quickly, it is the bounding rectangle that lags behind for 5 seconds or so.
- also confirming that removing stroke and adding fill solves the problem. Also, outline mode with no stroke works well.
- not sure if there is any connection to bounding box calculation, since this calculation should be necessary even if no stroke is present.

[su_v (suv-lp)]

Alvin Penner wrote:
> not sure if there is any connection to bounding box calculation (…)

Did you read both threads I linked to? IMHO it is the same issue as described by LucaDC in
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37456>
and confirmed by KK and other developers.

> (…) since this calculation should be necessary even if no stroke is present.

If there is no stroked object present in the file, there is no need to do the expensive precise bbox calculation where each stroke is converted to path to get the real extent (including miters and markers, and any (non-unifom) transformations in effect).
As mentioned by KK, something is wrong in the workaround currently in effect in trunk (until caching of the bbox values is implemented):
<quote>
  The calculation is done too many times. It should only be done for the
  rectangle which is moved. I think somewhere there is an uncached call
  that should use the geometric bounding box, but uses the visual one
  instead.
</quote>
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/37609>

[Alvin Penner (apenner)]

sorry about that, I didn't read that link

Alvin

[Alvin Penner (apenner)]

fix committed to rev 10835.
any testing would be welcome, since timing issues can behave very differently on different machines.

[dopelover (dopelover)]

I have just tested trunk revision no. 10922 under Windows XP and felt noticeable performance boost. Inkscape works far better now while dealing with the file I attached at the beginning of this report. But unfortunately it seems that the problem is only reduced but not resolved. I've generated just another spiro path with 1000 nodes and must admit that the problem still exists.
Open an attached file and try to manipulate the green rectangle.

[su_v (suv-lp)]

> But unfortunately it seems that the problem is only reduced but not resolved.

Reproduced with Inkscape 0.48+devel r10922 on OS X Lion (64bit).
Same as with the first sample file: after removing the stroke from the spirograph spline and using a solid fill instead -> no delay when editing / transforming an additional simple (stroked or filled) object.

No such issues with Inkscape 0.48.2: the rectangle can be grabbed and dragged across the canvas without noticeable delay.

[Johan Engelen (johanengelen)]

is the "spiro" part relevant? or does the problem disappear when the path with spiro is converted to a path? (object to path)

[su_v (suv-lp)]

@Johan - please open the file in Inkscape: there is no path effect in play. The path (with 1000 nodes) was created with the spirograph extension:
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions-Render.html#Extensions-Spirograph>

[su_v (suv-lp)]

Same path in a new file without an attached ICC profile (it did not have an effect on the perfomance, but just to make sure).

Varying the stroke width of the complex path (1px -> 10px, 0.5px, 0.1px) has no effect on the low performance when e.g. dragging an additional simple object (solid filled, unstroked square) - be it placed in the center or outside of the spirograph path.

[su_v (suv-lp)]

Steps to reproduce with basic Inkscape shapes:

1) delete/rename preferences file
2) launch inkscape
3) draw three stars (use default settings, but increase number of corners to 200)
4) draw a rectangle

Test 1:
5) drag the rectangle with the mouse
-> slight delay, depending on general system performance, but noticeably delayed compared to Inkscape 0.48.2

Test 2:
6) select the three stars, and change the stroke style to 'Round Join' and 'Round Cap'
7) drag the rectangle with the mouse
-> noticeably loss of performance

[Alvin Penner (apenner)]

refresh problem reproduced here using file drawing-spiro-test.svg. Unfortunately it does not appear to be caused by the routine Path::Coalesce, will need to look elsewhere...

[Alvin Penner (apenner)]

some switches have been put in, to switch between visual and geometric bounding boxes, depending on the settings in Prefs->Tools->Bounding Box. This should noticeably improve the performance if the geometric box is chosen.

committed to rev 10935

[Alvin Penner (apenner)]

- some further changes have been made in rev 11010 to try to speed up the calculation of the visual bbox without affecting its shape. I think this is the most trimming that can be done without affecting the shape.
- Details at http://inkscape.13.n6.nabble.com/Inkscape-slowing-down-td2854391i20.html
- any testing would be welcome.

[jazzynico (jazzynico)]

Tested with drawing-spiro-test.svg (from comment #9) on Ubuntu 11.04, Inkscape trunk revision 11619.
The trunk version is still a bit slower than 0.48.2 when moving the rectangle, but it's relatively smooth and we can't call it a freeze.
Does this bug still deserves a "High" importance status?

[su_v (suv-lp)]

See Bug #1049562 “Inkscape slow to load 30MB SVG file (vector data only)” for another real-life example where loading time has improved a lot in current trunk, but performance when trying to actually edit or add objects (after having been patient enough to zoom in (100%) to an area of interest) is much worse in trunk (compared to stable).
Neither stable nor trunk allow to edit the huge file without huge delays - but any performance gains due to lower memory usage and faster rendering in current trunk are cancelled out when trying to do some work on the drawing content.

[su_v (suv-lp)]

Closing as 'Fix Committed' based on earlier comments - fixed for the available test cases.

Follow-up reports about similar performance regressions e.g.:
- Bug #1049562 “Inkscape slow to load 30MB SVG file (vector data only)”
- Bug #1198317 “Dragging objects in compex document very slow in 0.48+devel”