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.