653928 - SVG complete animation of path d attribute with elliptical arcs discrete instead of continuous

Status: REOPENED

(Core :: SVG, defect)

Description

[Dr. Olaf Hoffmann]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110430 Firefox/6.0a1
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110430 Firefox/6.0a1

If flags in elliptical arc commands change, Gecko switches from continuous to
discrete animation for path d attribute.

SVG 1.1 notes clearly about the d attribute:
"Animatable: yes. Path data animation is only possible when each path data specification within an animation specification has exactly the same list of path data commands as the 'd' attribute."
http://www.w3.org/TR/SVG11/paths.html#PathElement

This is obviously the case for the samples.
How to manage the flags, if they are neither 0 or 1 (what appears typically, if between 0 and 1 is 
interpolated), is explained in the implementation notes:
http://www.w3.org/TR/SVG11/implnote.html#ArcOutOfRangeParameters

"Any nonzero value for either of the flags fA or fS is taken to mean the value 1."

This results finally in some discrete switch effect between zero and non zero,
but not for the complete path, only for the elliptical arc segment the flag
changes. And it is not related to calcMode, because this appears only due to
the specific interpretation of the flags. This is similar to the effect of
animating for example stroke-miterlimit - the animation can be continuous, nevertheless the effect from switching between miter and bevel will be discrete.


About the provided example:
animate animation test of the d attribute of the path-element
(represented by a blue curve). 
The curve changes from the dark gray curve to the light gray curve in 10s.
The yellow and orange circles belong to the initial
curve and the cyan and cyan-green circles belong to the final curve.
d contains the commands M, A, a corresponding to elliptical arcs.

Reproducible: Always

Steps to Reproduce:
1. Try the given sample
2. Compare with recommendations (citation is included above)
3. Compare with current versions of Opera

Actual Results:  
discrete Animation for the complete path

Additionally in the alpha version given as build identifier above, at least one
elliptical arc seems to be degenerated to a cubic curve, this seems to be a
regression compared to firefox 4 for example - but this seems to be another
bug related to an attempt to approximate elliptical arcs with cubic curves, that fails here, anyway even with this bug the animation remains discrete.

Expected Results:  
Continuous animation including a switch/jump in presentation related to a change
between nonzero to zero for flags.

And of course elliptical arcs, no cubic curves here ;o)

Animation of elliptical arcs seems to be difficult for many viewers, however 
after some attempts at least Opera manages this for some time now.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
> SVG 1.1 notes clearly about the d attribute:
> "Animatable: yes. Path data animation is only possible when each path data
> specification within an animation specification has exactly the same list of
> path data commands as the 'd' attribute."

The spec says (paraphrasing the last chunk):
 "Path data animation is only possible when [the commands are the same]"

It sounds like you're interpreting that to mean:
 "Path data animation is *always* possible when [the commands are the same]"

...but I don't agree with your interpretation.  (It's a logically different statement.)

Rather, I read the spec as saying "animation isn't possible when the commands differ", with no blanket statement about what happens when the commands are the same.

Comment 2

[Dr. Olaf Hoffmann]

What happens depends mainly on the calcMode.
If the attribute is not explictly provided by the author, indeed the viewer
has to find out, if discrete or linear applies (for animateMotion paced).
For some situations, for example for polygon or polyline with points lists of
different length, the calcMode becomes discrete, because there is no 
continuous animation possible.
For the path d attribute one can interpolate between the numbers, therefore
calcMode linear is the default, resulting in a continuous animation.
Only the flag switch between non zero and zero implicates some discrete behaviour,
but this is not much related to the calculation of the animation effect function,
only to the presentation.


And note, that SVG tiny 1.2 already allows different commands as animation
values, in this case this means discrete animation (In SVG 1.1 this means an
error message). But here the commands are the same, only the numbers are different.

And that it is possible, you can see with current Opera versions - no question,
that it is possible to interpolate between 0 and 1, whatever this means for
the rendering (what is defined as well in the implementation notes).

Another question is, whether the correct effect will be, what some authors may
expect, but I think, they will expect a discrete animation even less ;o)

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to comment #2)
> For some situations, for example for polygon or polyline with points lists of
> different length, the calcMode becomes discrete, because there is no 
> continuous animation possible.

Right, that's somewhat equivalent to what we're doing here. (We detect that we can't interpolate, so we fall back to discrete animation.)

(In reply to comment #0)
> "Any nonzero value for either of the flags fA or fS is taken to mean the value
> 1."

This^ is interesting... I'd previously assumed that these boolean flags *had* to be 0 or 1,  but I guess that's not true.

So that means that (at least in theory) we can interpolate these flags like any other path data parameter, and it will just turn out that every non-zero interpolated-value will yield the "1" behavior.  I suspect that's the outcome that falls most logically out of the spec.

That should simplify the code a good bit, and it'd make Dr. Hoffman's testcase here work (albeit with a sudden jump in rendering when the flag hits 0).  jwatt, heycam, what do you guys think?

Comment 4

[Dr. Olaf Hoffmann]

Well, just to show, that there is some minor stress itself within the
recommendation, the BNF notes for flags 0|1, therefore authors should not note
anything different, but the implementation notes seem to be slightly more gentle
with inattentive authors or it considers situations as here with animation, 
where it gets possible to have other values than 0|1 for other reasons, not just
because an author did something nasty - or it is simply not completely consistent here. Or because it is only mentioned in the implementation notes,
this is really only intended for implementation to keep things working, not for
something, that authors should note within documents. 
Some intermediate result within animation is not noted by the author directly,
therefore the author is not guilty here not to follow the BNF
(what would be an error in SVG 1.1 documents).

Comment 5

[Cameron McCormack (:heycam)]

Yes, I think we should allow continuous animation between arc flag values.

Comment 6

[Robert Longson [:longsonr]]

Attachment: patch

Comment 7

[Daniel Holbert [:dholbert]]

Comment on attachment 568943 [details] [diff] [review]
patch

>+  // SECOND: ensure non-zero flags become 1.
>+  if (SVGPathSegUtils::IsArcType(segType)) {
>+    if (aResultSeg[LARGE_ARC_FLAG_IDX] != 0) {
>+      aResultSeg[LARGE_ARC_FLAG_IDX] = 1;
>+    }
>+    if (aResultSeg[SWEEP_FLAG_IDX] != 0) {
>+      aResultSeg[SWEEP_FLAG_IDX] = 1;

s/0/0.0f/
s/1/1.0f/

r=me with that

Comment 8

[Daniel Holbert [:dholbert]]

(Thanks for picking this up, BTW -- I'd forgotten about this bug!)

Comment 9

[Robert Longson [:longsonr]]

pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/12b227a42623

Comment 10

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/12b227a42623

Comment 11

[Jonathan Watt [:jwatt]]

I missed this bugmail. I actually deliberately had the code not interpolate because the flipping of the flag isn't useful, IMO, and I wanted to prevent anyone coming to rely on non-useful flipping behavior when the spec could define something useful. One case when I can imagine you would want to animate from an arc with a large arc to small, is when animating a pie slice and changing its size through the 180 degrees. You would want the flat to be flipped intelligently when the pie is about to pass the 180 degree point though. Basically I wanted to wait until we worked out some spec text to describe how that should be done (I found it quite tricky so didn't do it while implementing path animation) and implement that behavior once spec'ed.

Comment 12

[Robert Longson [:longsonr]]

Webkit and Opera have this functionality.

Comment 13

[Daniel Holbert [:dholbert]]

Branch date is in a week, so if we end up needing to back this out, we'd need to do it by then to keep this from making it to Aurora.

Having said that, I agree with Robert that matching Webkit/Opera on this is nice, and per comment 3, I think this behavior is what the existing spec text calls for.  I also worry a little about having special-interpolation-behavior for special number values, when all other numbers are treated the same.

But I suspect this behavior isn't used / exercised thoroughly on the web, so I don't really feel strongly about this, if there really is a Better Way coming.

Comment 14

[Robert Longson [:longsonr]]

Jonathan, if you still can't live with this then back it out. As a group the Peers must operate with consensus regarding patches.

Comment 15

[Jonathan Watt [:jwatt]]

Well let me try again in explaining my thinking first. :)

Imagine you're doing some data visualization by animating the proportion that a pie chart's slices take up, and one slice has to pass through the 180 degree angle. With this patch it's impossible to do with a single SMIL animation, since you can't make the largeArc flag flip at the right point, so your chart graphic will completely screw up. Even with script or script assisted SMIL animation it's virtually impossible, because of the way arc segments are parametrized on end points (the maths is too hard for most people). To me this seems like something that should be relatively easy for authors to do though. While the new behavior may be consistent and easy on implementers, to me it seems like it's useless, and in fact is just going to immensely frustrate content authors that need to animate through 180 degrees, and lead them to waste time trying to figure out how to work around it (the vast majority of whom will have to give up).

That Webkit/Opera do what the patch makes us do is an argument against the patch, for me. If implementations are inconsistent, the SVG WG tends to be open to standardizing on the most useful behavior, even if that's something new. (The rational being that authors are less likely to be relying on any existing behavior.) If implementations are consistent, then there is a lot more reluctance to change even brain dead useless behavior. (The rational being that people may be relying on it anyway in some stupid way.)

Hopefully that makes sense, even if you don't agree.

Comment 16

[Robert Longson [:longsonr]]

If you back it out I'll live, I think this is a rather an edge case feature really.

It's more difficult to see how you'd implement your idea with discrete animations.

Comment 17

[Dr. Olaf Hoffmann]

I think, if authors need to animate a circle segment (pie chart), it will be much simpler to animate a circle element. (if user agents had no accuracy problems or bugs, one could simply use stroke-dasharray for a pie chart ;o).

If you animate an elliptical arc with the SVG endpoint notation, the result will be typically surprising, with and without this flag switching. Due to this and current bugs of viewers, typically authors have to approximate the arc anyway with a larger set of cubic curves to get a more smooth animation and not the typical elliptical arc drama, resulting from the endpoint notation mainly.
However, apart from boring (and maybe meaningless applications like elliptical pie charts) applications, the funny behaviour of elliptical arc animation
can be pretty interesting for animated art works, because it is not trivial to simulate such a behaviour with cubic curves (but of course - who cares about arts today? ;o)

To get an intuitive and simple behaviour for authors, one needs a notation in polar coordinates. I provided already a proposal about this to the W3C-SVG-group, but as far as I have seen, there is no decision about this yet. And I'm not sure, if there are really enough use cases for the majority of authors, if 
pie charts are the only application ;o) Obviously one could propose a new circle segment element for such specific applications like pie charts, if it turns out, that many authors need to use them in a simple way.

Comment 18

[Daniel Holbert [:dholbert]]

(summing up discussion w/ jwatt in #svg just now):
So presumably, there's not really any "nice" time to flip the sweep-flag, except when the path is 0-length. (that's the clockwise-vs-counterclockwise-ish flag IIUC)

But for large-arc-flag, **if our arc is animating across a 180-degree boundary**, I can see that this would be really nice time to transition the flag for the pie-chart case. I worry a little that it'd be computationally tough to compute whether/when a 180-degree crossover will take place (particularly since we'd have to do it every sample, to recompute the world).  And also, if there's no 180-degree-crossover, there's not really any intuitive time to transition the large-arc-flag aside from what this bug already does.

So I suppose any spec clarification on this would be have to end up very special-casey, for the pie-chart example, with fallback behavior being something clunky like what this bug's patch already does.  Maybe that's OK, though, since I agree that it'd be nice for pie-charts to animate nicely. :)

So, I'm OK with backing this out, given comment 15.

Comment 19

[Jonathan Watt [:jwatt]]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/ae79993b6eb9 to allow the SVG WG to consider this issue at some point for SVG 2.

Dr. Hoffmann, I'd like to see support for ellipse segments in polar coords, but as you say, it may not have enough demand.

Comment 20

[Boris Chiou [:boris]]

https://github.com/w3c/svgwg/issues/543 has a new update for this:

RESOLUTION: Flipping boolean and integers half way for path interpolation

This will be added in SVG 2, I think.