From: Doug Schepers <schepers@w3.org>

Date: Tue, 07 Oct 2008 07:40:13 -0400

Message-ID: <48EB4A9D.6030905@w3.org>

To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>

CC: www-svg@w3.org

Date: Tue, 07 Oct 2008 07:40:13 -0400

Message-ID: <48EB4A9D.6030905@w3.org>

To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>

CC: www-svg@w3.org

Hi, Dr. Olaf- Thanks for your comment. I've recorded this as ISSUE-2089 in our Tracker. The SVG WG will discuss this and get back to you soon. Regards- -Doug Dr. Olaf Hoffmann wrote (on 10/1/08 10:19 AM): > 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 Tuesday, 7 October 2008 11:40:53 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 8 March 2017 09:47:15 UTC
*