Improved performance of the object snapper
Hello,
The last few days I've spent on improving the performance of the object snapper. It used to take ages (e.g about 6 seconds on my machine) to move a simple rectangle over a large text box, but I've managed to reduce this significantly (i.e. < 1 sec.!). This was with both snapping to paths and snapping to nodes turned on. For this I had to refactor the object snapper code significantly, so I might have introduced new bugs or regressions. Please be aware of this and report any suspicious behavior, so we can have both fast and robust snapping in v0.46!
Please note that the performance has only increased when using the selector tool for transforming a number of points, e.g. when dragging a selection. Using the node tool to drag a single node will not benefit from this.
Now for those of you interested in some technical details:
Before, for _every_ point in the selection being transformed (using the selector tool), Inkscape would search for snapping candidates, build a list of nodes and paths, and finally call convertWithBackData(). Only then would it snap this single point and start all over again for the next point in the selection. Now we only do this collecting and converting stuff once, store the results, and then snap all points in the selection (using the stored data). Not having to call convertWithBackData really helps a lot! I think that in many common cases this improves the performance dramatically. However, there might also be some (rare?) cases showing a performance decrease, because the number of candidates might be higher. Before we would search for candidates within range of a single point. Now we search for candidates within range of any of the snappoints in the selection, so our list of candidates is longer which gives us more combinations to check. I do think that this will not really be an issue, as this use case is less common and there's still a performance gain at the same time.
Any feedback is appreciated!
Regards,
Diederik
On 9/5/07, Diederik van Lierop <mail@...2312...> wrote:
The last few days I've spent on improving the performance of the object snapper. It used to take ages (e.g about 6 seconds on my machine) to move a simple rectangle over a large text box, but I've managed to reduce this significantly (i.e. < 1 sec.!). This was with both snapping to paths and snapping to nodes turned on. For this I had to refactor the object snapper code significantly, so I might have introduced new bugs or regressions. Please be aware of this and report any suspicious behavior, so we can have both fast and robust snapping in v0.46!
Thanks, great news! Please add a note about that in the "speed and interactivity" section of the release notes as well.
Please note that the performance has only increased when using the selector tool for transforming a number of points, e.g. when dragging a selection. Using the node tool to drag a single node will not benefit from this.
I just tried to test this: opened new document, drew a spiral and a small rect, then opened doc prefs and turned on "snapping of: bbox corners" and "snapping to objects: snap to paths". But when I drag the rect it does not snap to the spiral. What am I doing wrong?
Before, for _every_ point in the selection being transformed (using the selector tool), Inkscape would search for snapping candidates, build a list of nodes and paths, and finally call convertWithBackData(). Only then would it snap this single point and start all over again for the next point in the selection. Now we only do this collecting and converting stuff once, store the results, and then snap all points in the selection (using the stored data). Not having to call convertWithBackData really helps a lot! I think that in many common cases this improves the performance dramatically.
Yes, this is approximately how I imagined that. The convertWithBackData, as all livarot functions, is very slow. Hopefully we'll be able to use 2geom for that task one day.
bulia byak wrote:
I just tried to test this: opened new document, drew a spiral and a small rect, then opened doc prefs and turned on "snapping of: bbox corners" and "snapping to objects: snap to paths". But when I drag the rect it does not snap to the spiral. What am I doing wrong?
Well, it should! The bbox corners of the rect should snap to any point on the bbox of the spiral. Are you sure it doesn't work that way? It does work like that at this side of the Atlanic ocean. The "snap to paths" is discarded in bbox-snapping-mode, as it is only applicable when snapping nodes.
Diederik
participants (3)
-
bulia byak
-
Diederik en Rezi
-
Diederik van Lierop