From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Wed, 1 Oct 2008 16:19:12 +0200

To: www-svg@w3.org

Message-Id: <200810011619.12877.Dr.O.Hoffmann@gmx.de>

Date: Wed, 1 Oct 2008 16:19:12 +0200

To: www-svg@w3.org

Message-Id: <200810011619.12877.Dr.O.Hoffmann@gmx.de>

Hello SVG WG, SMIL notes about the underlying value of an animation: "The base value of a target attribute 'a' at time t is the value of 'a' to which animation is applied at time t." and "Animations can be defined to either override or add to the base value of an attribute. In this context, the base value may be the DOM value, or the result of other animations that also target the same attribute. This more general concept of a base value is termed the underlying value." and "The underlying value u of a target attribute 'a' of an animation element at time t is the value of 'a' to which the animation effect is applied at time t." In the table of SVGT1.2 '16.2.18 Attributes and properties that can be animated' it is noted for transform: "Additive means that a transformation is post-multiplied to the base set of transformations." and in 16.2.17 The 'animateTransform' element: "When an animation is active, the effect of non-additive 'animateTransform' (i.e. additive="replace") is to replace the given attribute's value with the transformation defined by the 'animateTransform'. The effect of additive (i.e. additive="sum") is to post-multiply the transformation matrix corresponding to the transformation defined by this 'animateTransform'." The obvious conclusion is, that the underlying value for an additive animateTransform is the base set of transformations at the time t and that the result of the animateTransform has to be post-multiplied to the underlying value (which includes results from lower priority animations too). Surprisingly 16.2.17 notes too (different from SVG 1.1): "The underlying value of transform animations (see SMIL discussion of animation function values) is the corresponding identity transformation value." This means especially, following this sentence new in SVGT1.2 compared with SVG1.1, that a) the underlying value is time independent b) the underlying value is always the same Effectively this sentence prevents any visible effect from additive animateTransform in conflict with the table of 16.2.18 and the additive sample of 16.2.17 and example: 19_01.svg of 16.2.3 and samples in the test suite like animate-elem-81. My impression is, that it is neither intended that additive animateTransform show no difference to non-additive animateTransform nor that these conflicts are intended. It looks more like a misunderstanding of the meaning of the SMIL definition of the 'underlying value', therefore I suggest simply to skip in 16.2.17 the sentence "The underlying value of transform animations (see SMIL discussion of animation function values) is the corresponding identity transformation value." and to explicitly note 'underlying value' in the table of 16.2.18: "Additive means that a transformation is post-multiplied to the base set of transformations representing the underlying value." and in 16.2.17 too: "The effect of additive (i.e. additive="sum") is to post-multiply the transformation matrix corresponding to the transformation defined by this 'animateTransform' to the the base set of transformations representing the underlying value." Because from-to, from-by and by animations are defined in SMIL already to be equivalent to the corresponding values animation (tests are already available in the test suite), there remains no specific problem for those notations for animateTransform too. What remains is the problem with to-animateTransform, because this animation type is neither pure additive nor pure non-additive. The following requirements for to-animations come from SMIL: a) begin (additive) with the underlying value b) end non-additive with the to value c) specific formula defined in SMIL has to be used - the formula defines a specific feature or behaviour or functionality, not available with other combinations of animations in SMIL/SVG. The main functionality it typically a smooth change from the underlying value to the value specified with to d) specified attributes additive or accumulate have to be ignored The following requirement comes from SVG animateTransform e) animateTransform has to be post-multiplied to the underlying value There is especially a conflict between c) and e). There are different more or less useful and simple possibilities to solve this conflict. 1) If e) is skipped, this requires an animation of the complete transform matrix in general to meet c) - this might be not completely trivial but is possible. Mainly one has to express the underlying value as a matrix as well as the value of the to attribute and to interpolate between those two values as specified in SMIL to get the desired smooth change. Because to-animations behave always quite different from the other animation types, this does not create any inconsistency. 2) If c) is skipped, this results in the complete loss of the functionality of to-animations for animateTransform. If we accept this, possibilities could be 2.1) to define to-animateTransfrom always to be a discrete animation, this avoids a direct conflict between c) and e) too, because SMIL defines the behaviour of discrete to animation not conflicting with e), therefore to-animateTransform has effectively the same functionality as a set animation, not directly available for transform currently. 2.2) to define an arbitrary initial value as done by the current draft, using effectively the identity transformation as initial value. This provides no interesting functionality as well and means, that a) has to be skipped as well due to the problem with the underlying value as discussed above. 2.3) to specify that to-animateTransform has no effect, to indicate, that not all requirements can be met. Side note: In the table of 16.2.18 there are two notes about color conversion. This looks like a missing word: "Only additive if each value can be converted an RGB color." -> "Only additive if each value can be converted (in)to an RGB color."?Received on Wednesday, 1 October 2008 14:21:21 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 22:54:20 UTC
*