Grid snapping hangs in large drawings

Bug #1348959 reported by Werner Simbürger on 2014-07-26
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Diederik van Lierop

Bug Description

Inkscape 0.48.5 r10040 (32-bit)
running on Windows-7 64-bit OS
3.7 GHz Quad Core i7/, 16 GByte RAM
 Nvidia Quadro 2000

In large drawings the grid snapping function became extremely slow, even become useless. Maybe the grid search and snap algorithm should not always overlook the whole database but just only the screen region or even a smal reagion around the cursor.

Please open Schematic.svg (attached drawing file) and "Enable snapping" .

And then try to move one of the grey shaded octagonal blocks (there is a label HPPI_RI6_1 in this block).

Its almost impossible to move the block with grid snapping.

Inkscape does not crash and it does recover, but it can not be used for about 20 seconds.

Furthermore, the responsivness of the graphics could be improved.
For example, if you move around with the middle mouse button pressed (in "Schematic.svg") then the responsivness of the
screen movements become slow (even with high end hardware) because of the large drawing.

However, Inkscape is really great tool.
It is a diamond milestone in open source development .

Best regards,
Werner
Munich, Germany

su_v (suv-lp) on 2014-07-26
tags: added: snapping
su_v (suv-lp) wrote :

Responsiveness in stable 0.48.5 is much improved after toggling off the 'Snap to paths' setting.

Responsiveness in trunk 0.48+devel with same snap settings has improved, but with the overlay objects (red circles) and nearby paths visible while dragging, snapping to paths appears to still slow down dragging such complex groups noticeably. Alternatively (if snap to path is required in all situations), removing (or hiding e.g. on a layer above) those overlay/nearby objects while adjusting the position of the complex groups may improve responsiveness too.

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

> Inkscape does not crash and it does recover, but it can not
> be used for about 20 seconds.

On OS X 10.7.5, with default (new) prefs:
- not reproduced with Inkscape 0.48.2, 0.48.3.1
- reproduced with Inkscape 0.48.4, 0.48.5
- partially reproduced with current trunk 0.48+devel r13471 (not as "snappy" as 0.48.2 or 0.48.3.1)

@Diederik - maybe you could comment? This might be related to changes (in stable >= 0.48.4 and in trunk) wrt switching (or not) to convex hull corner snapping when dragging complex groups?

tags: added: regression
Changed in inkscape:
assignee: nobody → Diederik van Lierop (mail-diedenrezi)

Will look into what's causing this, but one work-around has not been mentioned yet: you might want to enable the option in the preferences to "only snap the node closest to the mouse pointer", that will already help a lot! See preferences -> Behaviour -> Snapping

yes right - I think the combination of disabling "snap to paths" and
"only snap the node closest to the mouse pointer" solves the issue.
Thanks for this hint.

BR,
Werner

> Will look into what's causing this, but one work-around has not been
> mentioned yet: you might want to enable the option in the preferences to
> "only snap the node closest to the mouse pointer", that will already
> help a lot! See preferences -> Behaviour -> Snapping
>

OK, so we're trying to snap nodes to paths, which takes a very long time. I just found out that we have an upper limit on the number of nodes (200) which we're hitting. That's ok. But there's no limit on the number of paths, which is in this case 2610! That gives an awful lot of combinations to test!

Not that we ever had such a limit on the number of paths, but we should.

What has changed though recently that triggers this is still unknown

Something else I noticed: in the document properties, "always snap" has been chosen for the object snapper, instead of the default "snap only when closer than...". Because of this, Inkscape will try to snap any object in the document, no matter how far away it is! When I revert this to the default setting again only 50 paths are considered for snapping to, as opposed to the initial 2610. This makes Inkscape reasonably responsive again.

yes agree, therfore most likely no change in the code is necessary (then
it was a "user problem")...

> Something else I noticed: in the document properties, "always snap" has
> been chosen for the object snapper, instead of the default "snap only
> when closer than...". Because of this, Inkscape will try to snap any
> object in the document, no matter how far away it is! When I revert this
> to the default setting again only 50 paths are considered for snapping
> to, as opposed to the initial 2610. This makes Inkscape reasonably
> responsive again.
>

In rev. 13483 the number of paths to snap to has been limited to max. 200. That should be enough for everyone ;-)

I don't agree that this is just a user's error. Inkscape should stay responsive, and some sensible limits should have been implemented.

This makes me wonder though: shouldn't we just remove the "always snap" options for the object and guide snapping, and only keep it for grid snapping? Are these options useful at all?

Changed in inkscape:
status: Confirmed → Fix Committed
su_v (suv-lp) on 2014-08-02
Changed in inkscape:
importance: Undecided → Medium
milestone: none → 0.91
Bryce Harrington (bryce) on 2015-02-23
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers