- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sun, 21 May 2006 16:40:34 +0200
- To: www-svg@w3.org
Hello, I think, from SVG1.0/1.1 it is not quite clear, how a scaling animateTransform is applied correctly for many authors and implementors. As far as I have seen, the situation can get worse with SVG1.2 mobile and SMIL2.0/2.1 for animateTransform in general. Because animateTransform is just specified in SVG, this is mainly a problem of SVG and not of SMIL, to get the behaviour correct, useful and consistent in the viewers. In the SVGmobile1.2 draft, section 16.2.16 it is added: "If from or to attributes are not specified, the underlying value (see SMIL discussion of animation function values) is the corresponding identity transformation value." I tried to understand it but it is still a little bit surprising what the use of this is. The simplified meaning is, that under the described conditions animateTransform cannot be used with additive="sum". If there is no underlying value explicitly defined, shouldn't the identity matrix be the underlying value for all animation types, not just for values-animations and by-animations (they are the only animation types not using 'from' or 'to' attributes)? According to the SMIL recommendation we have five types of animation: 1. values-animation (no from, no to, no by) 2. from-to-animation (no values, no by) 3. from-by-animation (no values, no to) 4. by-animation (no values, no from, no to) 5. to-animation (no values, no from, no by) No (from or to) is the same as (no from) and (no to). 4. and 5. have a definition of special behaviour in SMIL. To get the correct behaviour of an animateTransform as to-animation, viewers need to implement something like an animation of the matrix type, everything else is explained in detail in SMIL. But 5. is the only type clearly excluded by this rule, 2. and 3. seem to be excluded, but this is not the case, as we will see later. The special rule from the animateTransform section is for values-animations and by-animations, but is it really the intention of the working draft to define something like this for values-animation and by-animations? This means in this example for a values-animation: <g transform="translate(100,100) scale(0.5,0.5)"> <animateTransform attributeName="transform" attributeType="XML" type="scale" values="1.5,1.5;4,-4" dur="5s" additive="sum" /> <use xlink:href="#somecontent" /> </g> for this simple animation without lower priority animations the underlying value is the same as the base value "translate(100,100) scale(0.5,0.5)" and it is overwritten by the identity matrix, e.g, scale(1,1). Therefore the additive sum is ignored. But animateTransform is described to support the attribute additive in the 1.2 mobile draft (section 16.2.17) as in SVG1.0/1.1. This is a contradiction in the draft. The visible effect for this values-animation is the same as: <g transform="translate(100,100) scale(0.5,0.5)"> <animateTransform attributeName="transform" attributeType="XML" type="scale" values="1.5,1.5;4,-4" dur="5s" /> <use xlink:href="#somecontent" /> </g> or as: <g transform="scale(1,1)"> <animateTransform attributeName="transform" attributeType="XML" type="scale" values="1.5,1.5;4,-4" dur="5s" /> <use xlink:href="#somecontent" /> </g> But the problem is even bigger, because SMIL2.0/2.1 defines from-to- and from-by-animations as shortcuts for values-animations. This means, the special rule has to be applied to from-to- and from-by-animations too. For this case, the second example for animateTranform is wrong too. This rule is even more interesting for a by-animation, because this is defined to be additive sum in general by SMIL and not as additive replace. This new rule means effectively, that by-animations should be ignored for animateTransform, because it is not a solvable contradiction, SMIL says: 'Normative: A by animation with a by value vb is equivalent to the same animation with a values list with 2 values, 0 and vb, and additive="sum". Any other specification of the additive attribute in a by animation is ignored.' Even if we replace 0 carefully by the identity matrix, this will not solve the problem, because the underlying value is set to the identity matrix too and this is the same as additive="replace". And the SVG1.2mobile-draft refers to SMIL for details. But it cannot be both, additive sum and additive replace ;o) From the old specification the behaviour of a by-animation (not accumulative) was the same as an additive from-by-animation with the identity matrix as the value of the from-attribute. Is it the intention of this part to say just this? But this from-value has nothing to do with the underlying value in SMIL. If not, it would be easier to write the special rule as follows: "The attribute value additive="sum" is not supported anymore for animateTransform in SVG1.2mobile. by-animation is not supported anymore for animateTransform in SVG1.2mobile. Note, that SMIL defines a special behaviour for to-animations." If this is not the intention, it would be very helpful for authors and developers, to clearify this in detail, else we will get different interpretations in different versions in every SVG-viewer. Authors will skip such type of animation, because it is not usable. Anyway, I think there is another question about the correct behaviour of accumulate="sum" for animateTransform. Is every iteration step post-multiplied to the previous interation step or something else? Especially it is not clear, how an accumulative by-animation for scale should work (maybe for other animation types too). Example: <animateTransform attributeName="transform" type="scale" by="1,1" accumulate="sum" repeatCount="2" begin="0s" dur="1s" fill="freeze" /> Is this the same visual effect as (classical SVG1.0/1.1/SMILanimation style, not implemented correct up to now in any SVG viewer, as far as I have seen): <animateTransform attributeName="transform" type="scale" from="1,1" to="2,2" begin="0s" dur="1s" fill="freeze" /> <animateTransform attributeName="transform" type="scale" from="2,2" to="3,3" begin="1s" dur="1s" fill="freeze" /> or as (SMIL2.0/2.1, jump-style): <animateTransform attributeName="transform" type="scale" from="1,1" to="2,2" begin="0s" dur="1s" fill="freeze" /> <animateTransform attributeName="transform" type="scale" from="3,3" to="4,4" begin="1s" dur="1s" fill="freeze" /> or as (post-multiplicative style?): <animateTransform attributeName="transform" type="scale" from="1,1" to="2,2" begin="0s" dur="1s" fill="freeze" /> <animateTransform attributeName="transform" type="scale" from="2,2" to="4,4" begin="1s" dur="1s" fill="freeze" /> or as (SVG1.2 mobile? ignore-almost-everything-additive-style): <animateTransform attributeName="transform" type="scale" from="1,1" to="2,2" begin="0s" dur="1s" fill="freeze" /> <animateTransform attributeName="transform" type="scale" from="1,1" to="2,2" begin="1s" dur="1s" fill="freeze" /> The source of these difficulties is, that scaling is a multiplicative operation (1 or the identity matrix is the neutral element of this operation and not 0 as for other transformations like translation or rotation). To get a useful result for animation, it will be necessary to define in detail, what are the changes compared to other animations to get a useful and consistent behaviour. And if the desired behaviour should be different as defined by SMIL-animation, it is not useful to use the same values and to refer to SMIL for details. Best wishes
Received on Sunday, 21 May 2006 14:42:39 UTC