Discussion:
[Inkscape-devel] Inkscape slowing down
LucaDC
2011-10-07 12:50:51 UTC
Permalink
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
moving objects.
After some investigation, I found that this is mainly due to bounding box
update, i.e. while an object (or a group of objects, but a single one is
enough) is moved, its bounding box is drawn as a dashed rectangle around it;
when I start moving, the rectangle stays in its original position for a
while (and moving is ok), then if I stop moving or after a while it gets
updated in the new position and this takes ages! I can't work with such a
slow update.
I've got a Pentium IV 3.2 GHz with 2 GB of RAM. I know it can be considered
pretty old a system, but I run all the software I need on it without any
problem. I feel that it should be fairly enough for an application like
Inkscape (I never use filters or other graphical features, only technical
drawing); and it was, up to few weeks ago.
I suspect that the bounding box is continuously recalculated but this is not
needed as the object cannot change while moving it; also, calculating the
bounding box for a single object should not be heavy at all.
So, should I start worrying for Inkscape requiring too much resources for me
in the near future (or even present) or can this be simply considered a bug?
I can easily trigger it by opening a new document, drawing a couple of
circles and a couple of rectangles, selecting all four objects and start
duplicating them with the spacebar: after a few duplications my CPU usage
goes very high and moving objects becomes a pain. It seems related to how
many objects are present in the drawing, which is a nonsense because moving
a single object should not depend on anything else but the object itself (I
tried with all snappings disabled too, of course).
Thanks and regards
Luca
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32606652.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
~suv
2011-10-07 13:22:33 UTC
Permalink
Post by LucaDC
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
moving objects.
After some investigation, I found that this is mainly due to bounding box
update, i.e. while an object (or a group of objects, but a single one is
enough) is moved, its bounding box is drawn as a dashed rectangle around it;
when I start moving, the rectangle stays in its original position for a
while (and moving is ok), then if I stop moving or after a while it gets
updated in the new position and this takes ages! I can't work with such a
slow update.
Only affects drawings with stroked paths.

See the earlier discussion of this issue in
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37154/focus=37158>

More precise bbox calculation -> caching of bbox values?
<http://wiki.inkscape.org/wiki/index.php/Caching>


~suv
Josh Andler
2011-10-07 15:34:28 UTC
Permalink
No, there is no need to worry about resources in the future (in fact,
aside from some current bugs, Inkscape requires far less memory than
before). As it's been known, Inkscape is currently going through a
refactoring development cycle. What you pointed out is a known issue
and as ~suv had linked, Krzysztof is aware if the problem. However,
the current plan is for him to actually work on a critical bugfix we
need in Pixman/Cairo before anything else directly in Inkscape. Please
don't worry and be patient while things are being worked on (Krzysztof
has a lot of the "heavy lifting" to do and he's also in school full
time right now).

Cheers,
Josh
Post by LucaDC
I've not been using Inkscape for a while lately.
Yesterday I made a new drawing and noted a considerable slowdown while
moving objects.
After some investigation, I found that this is mainly due to bounding box
update, i.e. while an object (or a group of objects, but a single one is
enough) is moved, its bounding box is drawn as a dashed rectangle around it;
when I start moving, the rectangle stays in its original position for a
while (and moving is ok), then if I stop moving or after a while it gets
updated in the new position and this takes ages! I can't work with such a
slow update.
I've got a Pentium IV 3.2 GHz with 2 GB of RAM. I know it can be considered
pretty old a system, but I run all the software I need on it without any
problem. I feel that it should be fairly enough for an application like
Inkscape (I never use filters or other graphical features, only technical
drawing); and it was, up to few weeks ago.
I suspect that the bounding box is continuously recalculated but this is not
needed as the object cannot change while moving it; also, calculating the
bounding box for a single object should not be heavy at all.
So, should I start worrying for Inkscape requiring too much resources for me
in the near future (or even present) or can this be simply considered a bug?
I can easily trigger it by opening a new document, drawing a couple of
circles and a couple of rectangles, selecting all four objects and start
duplicating them with the spacebar: after a few duplications my CPU usage
goes very high and moving objects becomes a pain. It seems related to how
many objects are present in the drawing, which is a nonsense because moving
a single object should not depend on anything else but the object itself (I
tried with all snappings disabled too, of course).
Thanks and regards
Luca
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32606652.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Krzysztof Kosiński
2011-10-08 02:31:20 UTC
Permalink
Just a quick note: I've been ill for the past week, which messed up
some of my plans.

Currently the visual bbox calculation is done in a very inefficient
way using livarot. It could potentially be improved by using
cairo_stroke_extents instead.

Regards, Krzysztof
Alexandre Prokoudine
2011-10-08 14:50:38 UTC
Permalink
Post by Krzysztof Kosiński
Just a quick note: I've been ill for the past week, which messed up
some of my plans.
Currently the visual bbox calculation is done in a very inefficient
way using livarot. It could potentially be improved by using
cairo_stroke_extents instead.
Oh? I thought we ditched it entirely. Where else do we still use it?

Alexandre Prokoudine
http://libregraphicsworld.org
Krzysztof Kosiński
2011-10-08 20:12:14 UTC
Permalink
Post by Alexandre Prokoudine
Post by Krzysztof Kosiński
Just a quick note: I've been ill for the past week, which messed up
some of my plans.
Currently the visual bbox calculation is done in a very inefficient
way using livarot. It could potentially be improved by using
cairo_stroke_extents instead.
Oh? I thought we ditched it entirely. Where else do we still use it?
Most path operations still use it: the tweak tool, offsets, stroke to
path, boolean operations and probably a few other things; only LPEs
are exclusively based on 2Geom. The livarot rasterizer is still used
in the text layout class.

Regards, Krzysztof
LucaDC
2011-10-10 12:21:47 UTC
Permalink
Post by Krzysztof Kosiński
Currently the visual bbox calculation is done in a very inefficient
way using livarot. It could potentially be improved by using
cairo_stroke_extents instead.
Thanks for all the replies/explanations. Ok, I'll positively wait for an
improvement on this side.
But maybe it's worth saying that I always use geometrical bounding boxes, so
I can't understand why all these useless calculations on strokes are
performed anyway (if I correctly understand).
Also, I've never experienced such problems so they must have been introduced
by some recent modification: could you point it out so, for now, I can
revert to just before it?
Regards.
Luca
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32623348.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
~suv
2011-10-10 13:44:28 UTC
Permalink
Post by LucaDC
Also, I've never experienced such problems so they must have been introduced
by some recent modification: could you point it out so, for now, I can
revert to just before it?
The initial message of the thread I linked to earlier gives the revision
Post by LucaDC
Revision 10589 removes all trace of libnr from Inkscape's code, which
was a major refactoring goal. This is a rather big change and might
~suv
LucaDC
2011-10-12 09:13:44 UTC
Permalink
Post by ~suv
The initial message of the thread I linked to earlier gives the revision
Ok, thanks. I hoped not to have to go so much backward but indeed rev 10588
works as expected.
Unfortunately, I'll have some difficulties in checking and appreciating
Diederik's progresses (I've read "3) groundwork for tangential/perpendicular
snapping" in rev 10672 comment :)
Post by ~suv
The problem is a bit deeper. There was a lot of code that used the
"approximate" bounding box, which is not well defined, but roughly
corresponds to the visual bounding box and is easy to calculate. I
changed most code that used approximate bbox (which was the default)
to use the visual bbox and removed the default value from methods that
take a bounding box type, to force people to specify which kind of box
they mean. As I worked through the code it became apparent that a lot
of it is wrong and should use the geometric box, but this could cause
regressions.
Does this mean that there's still a lot of work left before seeing a correct
management of visual/geometric bounding box? If so, why not still keeping
the quick "approximate" bounding box (at least for now) that worked so well
instead of forcing the use of the much heavier visual one in all those cases
where it's not really needed? Implementations would still remain wrong until
they are corrected to use the geometric one. If I correctly understood the
problem, of course.

What I surely didn't understand is why the overload rises with the number of
objects present in the drawing: if I have a lot of rectangles, moving a
single one is a pain while it's not when I have only a couple. I can't catch
the relationship with the complexity of bounding box calculation (and,
anyway, we are speaking of rectangles...).

Regards.
Luca
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p32636800.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Krzysztof Kosiński
2011-11-09 11:22:44 UTC
Permalink
Post by LucaDC
What I surely didn't understand is why the overload rises with the number of
objects present in the drawing: if I have a lot of rectangles, moving a
single one is a pain while it's not when I have only a couple. I can't catch
the relationship with the complexity of bounding box calculation (and,
anyway, we are speaking of rectangles...).
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.

(Sorry for absurdly long delay in replying)

Regards, Krzysztof
Jon Cruz
2011-11-12 07:54:57 UTC
Permalink
Post by Krzysztof Kosiński
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.
Thanks for the info.

Do you think it might be good to start a bit of a page on the wiki going to keep short notes on these?

We might be able to get some support for helping you hunt these down if we can get some help going.

Thanks.
Alvin Penner
2011-12-28 23:38:26 UTC
Permalink
Attached is some timing information concerning the bounding box
calculation, using Inkscape rev 10794. For a test case I used the file
spirograph.svg from LP Bug 906952.
https://bugs.launchpad.net/inkscape/+bug/906952
The time delay appears to be located almost exclusively in the routine
Path::Coalesce (file livarot\PathSimplify.cpp) which is called from the
routine item_outline (file splivarot.cpp) which is called from the routine
SPShape::sp_shape_bbox (file sp-shape.cpp) which may also optionally be
called from the routine sp_group_bbox (file sp-item-group.cpp).
On my machine, with this svg file, it takes 5 seconds to calculate the
bounding box. The time required depends on the stroke. If I change the
stroke from 0.5 px to 10 px, it takes only 1 second, but changing back from
10 px to 0.5 px takes 8 seconds, using the Fill and Stroke editor to modify
stroke.
In addition, the bounding box is often calculated twice, once if the
object is selected, and once again in order to calculate the bbox of the
whole image. Even if the complicated object is not selected, the bbox for it
will still be calculated, no matter which object is selected or moved, as
has been noted previously in this thread. This call appears to come from
sp_group_bbox, as far as I can tell.
In Inkscape 0.48.2, it appears that the bbox (with stroke) was
calculated using the option SPItem::APPROXIMATE_BBOX, which no longer
exists. This option compensated for stroke by adding half the stroke to the
bbox at each side, but did not take into account the style of endpoints. It
does not respond to any changes in EndCap style in the Fill and Stroke
editor (but it is faaast).
It appears that we need a compromise of sorts: if the path touches the
(geometric) bbox tangentially, then we can ignore endcap style and use the
half stroke width as in APPROXIMATE_BBOX (which is very fast), and if the
path endpoint is touching the (geometric) bbox then we need to compensate
for endcap style as is currently being done.

hth,
Alvin
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p33048008.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Jasper van de Gronde
2011-12-29 09:38:35 UTC
Permalink
Post by Alvin Penner
On my machine, with this svg file, it takes 5 seconds to calculate the
bounding box. The time required depends on the stroke. If I change the
stroke from 0.5 px to 10 px, it takes only 1 second, but changing back from
10 px to 0.5 px takes 8 seconds, using the Fill and Stroke editor to modify
stroke.
... It appears that we need a compromise of sorts: if the path touches the
(geometric) bbox tangentially, then we can ignore endcap style and use the
half stroke width as in APPROXIMATE_BBOX (which is very fast), and if the
path endpoint is touching the (geometric) bbox then we need to compensate
for endcap style as is currently being done.
This is tricky, as we do not only need to take endpoints into account,
but also corners of paths. I am a little surprised by your report that
apparently calculating the bounding box takes an amount of time that
depends on the stroke width. Or did I misunderstand your report?
Alvin Penner
2011-12-29 13:04:18 UTC
Permalink
Post by Jasper van de Gronde
This is tricky, as we do not only need to take endpoints into account,
but also corners of paths. I am a little surprised by your report that
apparently calculating the bounding box takes an amount of time that
depends on the stroke width.
-yes, I forgot about that, one would need to distinguish between smooth
joints and cusps.

- and yes, the time depends on stroke width. I open the Fill and Stroke
Editor and select the complex shape. I force the bbox to refresh itself by
editing the stroke width without actually moving the object. When I change
from stroke width 10 to 0.5 then the bbox recalculates itself (twice) and
each calc takes 8 seconds. When I change from 0.5 to 10, then each
recalculation takes about 1 second.
--
View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p33050102.html