- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Tue, 6 Apr 2010 11:59:59 +0100
- To: Daniel Holbert <dholbert@mozilla.com>, vbs85@gmx.de, www-svg@w3.org
Daniel Holbert: .... > In addition to the situation Dirk brought up, we get the following > paradoxical but correct-according-to-the-spec behavior: > a) The animation... > <animateTransform type="scale" by="0".../> > ...makes its target disappear. > b) If you stack N copies of... > <animateTransform type="scale" by="1" fill="freeze" .../> > ...all targeting the same element, the final frozen result will be at > scale=1 (as opposed to scale=N+1 or scale=N). > > (In part (b), if we had N animations with |by="2"| instead of |by="1"|, > we'd end up with a result at scale=2^N) > > Anyway, I agree with Dirk that the existing Opera & Firefox-nightly > behavior isn't immediately intuitive, but it does appear spec-correct > (based on the animateTransform-specific text) and it does make more > sense after reviewing that chunk of spec. > > ~Daniel Note, that you get similar surprising effects for the types skewX and skewY, however you will only notice a major effect with specific values or in precision tests: For skewing <g transform="skewX(45)"> <animateTransform type="skewX" by="45".../> </g> is quite different than <g> <animateTransform type="skewX" values="45;90".../> </g> (note the mad angle 90 degree for skewing ;o) just because tan(a+b) is typically not the same as tan(a) + tan(b), what corresponds to a wrong order of calculating the animation effect function and doing the matrix multiplication. Similar should happen for rotations with a changing rotation center (with T the translation part, D the rotation part, a and b representing the corresponding values): T(a)D(a)T(a)^-1T(b)D(b)T(b)^-1 is typically not the same as T(a+b)D(a+b)T(a+b)^-1 For simple rotations around the same center and translations the transformation effect is chosen in such a way, that such operations commutate, therefore for them even a slightly wrong interpretation of the recommendations provide the right result as it does for animations using the elements animate, animateColor or animateMotion. For most attributes and properties it does not matter, in which order to compute additive and cumulative behaviour, therefore there is a high risk, that it is done wrong, what can be only exposed with such few types and tests, where it matters. The situation is more problematic for to-animation for animateTransform, because to-animations are neither exactly additive nor non-additive and the intention for a continuous to-animation is to have a continuous change from the underlying value to the to-value. There is an explict formula in SMIL how to get this, but this is problematic for animateTransform with its postmultiplicative behaviour - what does not directly apply to to-animations, because they are not really additive. However there was no consensus to define for example, that one has to apply the SMIL formula to the matrices related to the CTM and the to-value, therefore the behaviour for animateTransform and for a to-animation is still undefined. Personally I would have needed this continuous behaviour already several times for some practical applications similar to the new CSS3-transitions, therefore I think, this gap is more annoying than the minor unavoidable surprises with by-animations - but it is not a perfect world ;o) Olaf
Received on Tuesday, 6 April 2010 11:02:15 UTC