On 9/5/07, Diederik van Lierop <mail@...1689...> wrote:
The last few days I've spent on improving the performance of the
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
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
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.
Inkscape. Draw Freely.