Closed Bug 469040 Opened 11 years ago Closed 11 years ago

SVG SMIL: implement paced animation for rotation, scale, and transform

Categories

(Core :: SVG, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: birtles, Unassigned)

References

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081202 Minefield/3.1b3pre
Build Identifier: 

Some types animate several independent values. In particular when animateTransform has type 'translate', 'scale', or 'rotate' this is the case.

SVG 1.1 section 19.2.14 says:

> If calcMode has the value paced, then a total "distance" for each component of the transformation is calculated (e.g., for a translate operation, a total distance is calculated for both tx and ty) consisting of the sum of the absolute values of the differences between each pair of values, and the animation runs to produce a constant distance movement for each individual component.

Implementing this behavior requires changes to the SMIL animation architecture. Current types can return only one distance. What we really need is some way to take, for example, a rotation transformation and calculate the distance for the angle component, center-x component, and center-y component separately and then to interpolate these components individually as well.

Reproducible: Always
Depends on: 468996
This test case shows an example of paced rotation where the rotation angle and rotation center are animated with an animateTransform element.

The expected result is that the animation of bottom smiley is a combination of the 'paced rotation' and 'paced movement'. That is, the rotation is paced and so is the movement.

Batik provides an example of correct behaviour. Opera 9.62 Linux maintains a paced rotation but not paced movement.
Attached image reftest image
reftest image testing paced animation for rotation, scale, translation, and skewY
The expected result
Sorry, I messed up the quote. Here's the section:

> If calcMode has the value paced, then a total "distance" for each component of
> the transformation is calculated (e.g., for a translate operation, a total 
> distance is calculated for both tx and ty) consisting of the sum of the 
> absolute values of the differences between each pair of values, and the 
> animation runs to produce a constant distance movement for each individual 
> component.
(http://www.w3.org/TR/SVG/animate.html#AnimateTransformElement)
I notice SVG 1.2T has addressed this and simplified it: http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#complexDistances

It applies the distance formula to pairs of values and for rotate, it does not include the rotation center in calculating distances. This would be a lot easier to implement (it's what Opera seems to do) but I suppose we're tied to implementing SVG 1.1 here?
I think we're always going to treat 1.2 as a superset of 1.1, i.e. we're never going to switch to a different implementation of the same function based on the version.

So I don't see why we can't do what SVG 1.2 says and what Opera does.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Several people have now suggested this including those involved with the SVG WG. I'll wait to see if there are any objections to implementing the SVGT1.2 behaviour here and confirm with roc and dholbert that this is ok.
We seem to have consensus that we should adopt the SVGT1.2 behaviour here. Various people including WG members have suggested that the SVGT1.2 behaviour should be back-ported to SVG1.1 here.

I've implemented the SVGT1.2 behaviour in patch v1d (attachment 354749 [details] [diff] [review]) for bug 468996. Marking this as WONTFIX.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.