Re: normalizedPathSegList in SVGPathElement

Dirk Schulze:
....
>
> > If elliptical arcs are approximated with cubic curves, one
> > always has to do the approximation for each animation
> > interpolation step. And because it is an approximation,
> > to provide a simple rule to get the cubic curves path segments
> > representing an elliptical arc within the requirement of SVG to
> > have at least an accuracy of one device pixel might be not trivial.
> > For this to hear some ideas how to get it correct enough
> > and fast (with a minimal number of cubic curves to meet
> > the required precision) at the same time would be interesting :o)
>
> For arc we take the center parameterization and split the arc to cubic
> curves every 45 degree (at least if I remember correctly). And yes, we
> do it for every single interpolation step on animations at the moment.
> It could be more efficient to use the flattened path directly, but this
> depends on the maths that would be needed to do so.
>

I think, at least for declarative animations you have to do the conversion 
for every interpolation step. To convert only the paths in the values list and
to interpolate between them will typically result in something
completely different, because cubic curves behave completely
different then the arcs (including all the possible corrections and
the possible discontinuous behaviour due to a flag flip). Typically
the interpolated cubic curves will not even look like an elliptical arc
for arbitrary elliptical arcs in a values list.
There were already some 'fun versions' of Opera in the past,
that provided interpolation between the cubic curve approximations
instead of the interpolation between the elliptical arcs - very entertaining,
but far away from correct ;o) Fortunately in current versions and in 
Squiggle and WebKit this seems to work. Unfortunately the adobe plugin 
manages only something like discrete animations of elliptical arcs - 
maybe for a similar reason.

But for scripting I'm not sure, if there is a similar problem,
this is always a discrete change of the curve without interpolation,
therefore just for scripting there might be no problem with the
approximation because there is no interpolation - or are there
situations, the script engine has to interpolate on its own?

Sure, that 45 degree segments are always sufficient?
(Maybe I will have some tries ;o)
I know for a complete circle an almost perfect approximation with
three cubic path segments, but for elliptical arcs I use typically
more to avoid visible deviations.

>
> Nevertheless, I think the complicated part here is the synchronization.
> Short example (complete example on the bottom of this mail):
>
> We have a path: d="M 10 50 A 40 40 180 1 0 90 50 l 0 -40 z" (MAlz).
>
> We take a reference to the arc segment:
>   var arcAbsSegment = path.pathSegList.getItem(1);
>
> Now we take the normalizedPathSegList (MCCLZ on Opera) and modify the
> lineToAbs:
>   path.normalizedPathSegList.getItem(3).y = 50;
>
> The pathSegList gets synchronized with the normalPathSegList now.
> There are two ways to do so:
> We could either completely replace the pathSegList with the
> normalizedPathSegList, or just replace the relative lineTo with the
> absolute lineTo from the normalizedPathSegList.
> The specification recommends to use the second one, but I think both
> ways are possible.[1]
>

This depends maybe, for what authors want to use such a list.
Because I never did, I have no concrete examples for the usage.
If an author tries to provide his own scripted interpolation between 
two elliptical arcs or needs something to control this or modify this, 
I suspect, that cubic path approximations in cartesian coordinates are 
not necessarily a help to do this - because the arcs are quite different in
behaviour - maybe such cubic curves in polar coordinates  as I suggested once 
would be a help - but can we assume, that this would  be often used?

Olaf

Received on Sunday, 5 September 2010 18:16:13 UTC