Open
Bug 653928
Opened 13 years ago
Updated 2 years ago
SVG complete animation of path d attribute with elliptical arcs discrete instead of continuous
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
REOPENED
People
(Reporter: dr.o.hoffmann, Unassigned)
References
()
Details
Attachments
(1 file)
6.95 KB,
patch
|
dholbert
:
review+
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
(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.
Reporter | ||
Comment 2•13 years ago
|
||
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•13 years ago
|
||
(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?
Reporter | ||
Comment 4•13 years ago
|
||
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•13 years ago
|
||
Yes, I think we should allow continuous animation between arc flag values.
Comment 6•13 years ago
|
||
Assignee: nobody → longsonr
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #568943 -
Flags: review?(dholbert)
Comment 7•13 years ago
|
||
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
Attachment #568943 -
Flags: review?(dholbert) → review+
Comment 8•13 years ago
|
||
(Thanks for picking this up, BTW -- I'd forgotten about this bug!)
Comment 9•13 years ago
|
||
pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/12b227a42623
Flags: in-testsuite+
Comment 10•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/12b227a42623
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Comment 11•13 years ago
|
||
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•13 years ago
|
||
Webkit and Opera have this functionality.
Comment 13•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Reporter | ||
Comment 17•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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.
Status: RESOLVED → REOPENED
Flags: in-testsuite+
OS: Linux → All
Hardware: x86 → All
Resolution: FIXED → ---
Target Milestone: mozilla10 → ---
Version: unspecified → Trunk
Updated•13 years ago
|
Assignee: longsonr → nobody
Updated•6 years ago
|
See Also: → https://github.com/w3c/svgwg/issues/543
Comment 20•6 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•