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

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Brian Birtles (:birtles)]

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

Comment 1

[Brian Birtles (:birtles)]

Attachment: Simple rotation testcase

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.

Comment 2

[Brian Birtles (:birtles)]

Attachment: reftest image

reftest image testing paced animation for rotation, scale, translation, and skewY

Comment 3

[Brian Birtles (:birtles)]

Attachment: reference image for attachment #352449

The expected result

Comment 4

[Brian Birtles (:birtles)]

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)

Comment 5

[Brian Birtles (:birtles)]

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?

Comment 6

[Robert Longson [:longsonr]]

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.

Comment 7

[Brian Birtles (:birtles)]

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.

Comment 8

[Brian Birtles (:birtles)]

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.