02-02-2022, 12:02 PM
The plugin "Replicate path along another path" is now faster. New version 0.7 is in
http://kmarkku.arkku.net/Path_replicate_...aster.html
That mouse-and-cat example of denzjos came from 167.688 seconds down to 16.635 seconds. Not bad. (The times were taken on my old and slow machine.)
For anybody interested: The main culprit was the procedure pdb.gimp_vectors_stroke_point_at_dist(). The plugin uses it to find on the Target path points at some given distance x from the start. And it is called veeery many times. Experimenting now a little I noticed that its running time depends on the number of anchors. I did like this: I started with a 2-anchor path. Then I clicked to the path more and more anchors, thus subdividing the path to more and more segments. And I saw that doubling the number of segments almost doubles the running time! That happens even if the curve remains the same, only the number of anchors on it grows. So I believe that the procedure works segment by segment, and not with the curve as a whole.
So, when my plugin got as input a Target path with a large number of anchors, like denzjos' cat, it took a long time to run.
What I did was that now the plugin first chops the Target path at its anchors to shorter paths, each with only 2 anchors. And I arranged things so that it suffices to call that pdb procedure only for one such small piece at a time. And at the same time some other time-consuming routines became by-passed. That's that.
But complicated paths may still mean long running times.
I hope I didn't mess anything up. Please report if the plugin does something odd.
I put here a little playing. The Base is the little red line, precisely one sixth of the width of the Source. Though I have said that the Base should be long enough, it seems that it is not always so very necessary. Then I ran the plugin with suitable parameters, joined the strokes of the resulting path, and deleted some anchors at both ends. Finally path to selection and bucket fill.
http://kmarkku.arkku.net/Path_replicate_...aster.html
That mouse-and-cat example of denzjos came from 167.688 seconds down to 16.635 seconds. Not bad. (The times were taken on my old and slow machine.)
For anybody interested: The main culprit was the procedure pdb.gimp_vectors_stroke_point_at_dist(). The plugin uses it to find on the Target path points at some given distance x from the start. And it is called veeery many times. Experimenting now a little I noticed that its running time depends on the number of anchors. I did like this: I started with a 2-anchor path. Then I clicked to the path more and more anchors, thus subdividing the path to more and more segments. And I saw that doubling the number of segments almost doubles the running time! That happens even if the curve remains the same, only the number of anchors on it grows. So I believe that the procedure works segment by segment, and not with the curve as a whole.
So, when my plugin got as input a Target path with a large number of anchors, like denzjos' cat, it took a long time to run.
What I did was that now the plugin first chops the Target path at its anchors to shorter paths, each with only 2 anchors. And I arranged things so that it suffices to call that pdb procedure only for one such small piece at a time. And at the same time some other time-consuming routines became by-passed. That's that.
But complicated paths may still mean long running times.
I hope I didn't mess anything up. Please report if the plugin does something odd.
I put here a little playing. The Base is the little red line, precisely one sixth of the width of the Source. Though I have said that the Base should be long enough, it seems that it is not always so very necessary. Then I ran the plugin with suitable parameters, joined the strokes of the resulting path, and deleted some anchors at both ends. Finally path to selection and bucket fill.