gimp_vectors_bezier_stroke_lineto() working backwards?
On 03/21/2011 02:34 PM, Simon Budig wrote:
Ofnuts (ofnuts@laposte.net) wrote:
Why is gimp_vectors_bezier_stroke_lineto(vectors, stroke_id, x0, y0)
(and Stroke.lineto(x,y)) working backwards? If I add a lineto() to the
stroke, the point of origin
(the one returned by gimp_vectors_stroke_get_point_at_dist(0,..))
changes... I'm sure there is a good reason, but I can't find it. Can
someone enlighten me?
The reason is simply the internal data structure as well as a
(possibly over-)optimzation in the code. A lineto basically needs to add
three anchors to the list of anchors. If the "current point" is the
beginning of the list, you can add these three anchors in an O(1)
operation. If you'd append them to the end you'd have to first search
for the end, making this an O(n) operation (unless you of course keep
track of the other end).
That's one reason :)
The API does not guarantee consistency for the distance->point mapping
when the length of the total path changes. When I designed the API I
tried to avoid the idea of a specific "start" and "end" for each stroke,
since this would introduce a directionality which would not be visible
in the User Interface.
But there is directionality.... if you stroke the path using a
gradient you somewhat have to know where it starts and where it ends.
I'm writing a scrirt that draws a path parallel to another one and if I
don't want it to switch sides around a circle directionality is
important: on a circle, there are always two points where the tangent
has the same slope, but in one the outside is above and oin the other
the outside is below, and to tell which "locally" you have to know in
which direction you are going.
Do you need to have get_point_at_dist(0...) staying constant while
constructing the stroke with the _lineto-family of commands?
My need is to be able to iterate between two points in the stroke (as
located by their "distance" since that's the only thing we have) and not
have this change if I add segments to the path. But I think I can
iterate a copy of the stroke instead.
However if point_at_dist(0) currently returns the "end" instead of the
"start", going for the "start" isn't that easy since
stroke.point_at_dist(stroke.get_length()) often fails (due to round-off
errors, likely). I conclude that the best way to get at the beginning of
the path is to look at the last points in stroke.points?
