From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Sun, 5 Sep 2010 19:58:05 +0200

To: www-svg@w3.org

Message-Id: <201009051958.05814.Dr.O.Hoffmann@gmx.de>

Date: Sun, 5 Sep 2010 19:58:05 +0200

To: www-svg@w3.org

Message-Id: <201009051958.05814.Dr.O.Hoffmann@gmx.de>

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? OlafReceived on Sunday, 5 September 2010 18:16:13 GMT

*
This archive was generated by hypermail 2.3.1
: Friday, 8 March 2013 15:54:46 GMT
*