Dragging objects in compex document very slow in 0.48+devel

Bug #1198317 reported by lcampagn on 2013-07-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I am using 0.48+devel+12398+35~quantal1 from the inkscape-trunk PPA on Kubuntu 12.10, both with and without kwin compositing. I have been pleased that this version uses less memory and renders complex objects more quickly than the stable version. Keep up the great work!

The problem I have is when dragging an object inside a complex scene, inkscape becomes very unresponsive (and the CPU is pegged during this time). I can tell that some effort has been made to improve this, because for about the first half-second after I start dragging, it is very responsive (so apparently it is not trying to re-draw the entire object or the background with every frame). After this time, though, the frame rate drops to about 0.5Hz and it becomes more or less impossible to move / scale / rotate the object with the mouse. Furthermore, inkscape (or possibly gtk / X) seems to drop mouse events when it is overloaded, so I can't simply move the mouse to its final destination and wait for inkscape to catch up--I have to keep wiggling the mouse to generate new events until the object is in position. The performance is the same when moving objects with the keyboard. In contrast, changing the order of objects (pgup/pgdn) is very responsive.

Is there anything I can do to profile this? Anything I can try to fix it?

I have attached an example svg that demonstrates the problem on my system.

lcampagn (luke-campagnola) wrote :
jazzynico (jazzynico) wrote :

Confirmed on Windows XP, Inkscape trunk revision 12703.
With 0.48.4, moving the rectangle is slow when on the complex path, but performance is not affected when moving outside the complex path.
With r12703, it is significantly slower, and performance is affected everywhere (even on the blank parts of the workspace).

tags: added: performance
tags: added: regression
Changed in inkscape:
status: New → Confirmed
su_v (suv-lp) wrote :

Reminds me of
- Bug #906952 “Low performance while manipulating spirograph paths”

(performance improves in current trunk if removing the stroke from the large number of copies of the complex path, and assigning a fill only)

Changed in inkscape:
milestone: none → 0.49
status: Confirmed → Triaged
su_v (suv-lp) wrote :

Same performance lag when all 42 paths are spaced out (aligned in rows & columns) without any overlap.

Changed in inkscape:
importance: Undecided → High
su_v (suv-lp) wrote :

Reduced test case with spaced-out clones (AFAICT same performance lag, smaller file size).

Similar (reduced) testcase, with different stroked objects:
Performance (r12712) seems to depend on object/curve type.

Sorted from (relatively) fast to slow:
- stroked rects
- stroked rounded rects
- stroked polygons
- stroked bezier curves
- stroked circles

Note: all snap controls disabled, the bottom layer with the stroked
objects is locked. Invisible or filled objects without stroke have no
effect on performance.

Krzysztof Kosinski (tweenk) wrote :

This performance problem is probably related to the bounding box computation, which takes into account the precise shape of the stroke. To fix this, we would need to provide a faster bounding box routine for strokes in 2Geom.

ScislaC (scislac) wrote :

It definitely appears to be related to bounding box computation. Performance is noticeably worse with Visual bounding box compared to Geometric bounding box.

su_v (suv-lp) on 2014-11-06
Changed in inkscape:
milestone: 0.91 → 0.91.1
su_v (suv-lp) on 2015-09-30
Changed in inkscape:
milestone: 0.91.1 → 0.92
jazzynico (jazzynico) on 2017-01-04
Changed in inkscape:
milestone: 0.92 → 0.93
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers