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

Date: Thu, 30 Oct 2008 15:23:24 +0200

To: www-svg@w3.org

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

Date: Thu, 30 Oct 2008 15:23:24 +0200

To: www-svg@w3.org

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

>> … >> Therefore it does not help to define what 0 is, because the complete >>animation >> has no meaning, maybe only some error management can be defined for such >> by animations of non additive types, if it is required to have a defined >> behaviour. Cameron: >Of course. I might argue that the actual fix should be to ensure >list-of-length etc. are additive. Some of them are already explictly mentioned in the attribute/property definition to be not additive. For other like text x, y, rotate the length of the list can differ and the rules to complete the list are different and partly not trivial. And just for the last draft version, some types are changed to something, what is noted in 16.2.18 to be not additive. SMIL distinguishes between some additive operation, required to get some propper values for from-by animations and additive behaviour, therefore if it is a list of numbers (and variants), from-by is still defined, even for non additive attributes, by animations not. Interesting to see, that for example the adobe plugin manages many of them to be additive anyway, even if it is noted in SVG1.1 already, that they are not additive ;o) >I think transform animations are already a bit weird, because the >operation being performed for additive/cumulative animations is matrix >multiplication, not addition. In that context, saying that the zero >value is the identity matrix seems appropriate. >> "To avoid jumps, authors will typically choose animation functions which >>start at 0." >> >> If a cumulative by animation starts with 1 instead of 0, this will create >> unintended jumps not related to a by animation. This is just another >> indication, that 0 is not 1 in SMIL animation too and results in nonsense. >If addition of transform animations is treated as matrix multiplication >(which is what the spec says currently), I don’t think this problem >really exists. This seems to have historical reasons. Without testing anything, I think, scaling would be more consistent with having exp(sx),exp(sy) instead of sx,sy directly in the matrix (but this would exclude mirroring, but avoids the problem to have no inverse). If the first terms of the power series is used, then one gets 1+sx, 1+sy, avoiding some surprising animation effects and with the possiblity of mirroring again and some matrices without an inverse. However, now we have simply sx,sy in the matrix and it is a little bit late to change ;o) Cumulative animation is not matrix multiplication, it is simply addition of the values, this is one of the first steps to calculate the animation function and is not related to additive behaviour and there is not specific rule for animateTransform. I think, this was always managed consistently in the adobe plugin (and Opera). If an animateTransform is additive, this means simply, that the animation effect, the value is calculated according to SMIL. The result is postmultiplied to the underlying value, whatever it is. Therefore the specific postmultiplication rule is only important for the last step to calculate the presentation value and has therefore nothing to do with the initial value of the animation function, respectively the 0 of a by animation. Well, it took a longer time for me to understand this too, because the old SMIL animation recommendation is a little bit confusing about this, but SMIL2 and 3 define an (almost) clear procedure, how to calculate the animation effect. The only specific rule required for animateTransform is, that this effect is postmultiplied finally. And therefore for the type scale by="1,2" clearly corresponds to values="0,0;1,2" additive="sum". This is completely the same as for the type transform or rotate correspondingly. For example the adobe plugin and the current versions of Opera have implemented this correctly. That this always starts with a 0-dimensional object is a consequence only from the function, how the scaling was defined to relate to a transform matrix, but is not related to SMIL animation. There is no consistent way to avoid this without changing the definition of the scaling matrix as discussed above. And if authors want something different, they can use a values animation. However, if they do not start (or end) with a zero scaling, then they will have jumps in cumulative animations, this cannot be avoided too because of the definiton of the scaling matrix. The definition of skewing has a less dramatic problem, because for some angles the tangens goes to infinity (no inverse defined for this, by the way), what could have been avoided with another function for skewing, but too late now to change... >Is it relatively simple to identify what 0 is now? Well, yes, it’s not >too hard, but I would rather have it explicitly called out, especially >since we likely won’t be changing to normatively reference SMIL 3 at >this late stage. I have no problem, if it is mentioned explictly, but it should be the right identification and by animation should be applicable at all for the type ;o) I suggested already in a previous response, simply to adopt the by animation definition from SMIL3 in SVGT1.2, then this is already consistent forward compatible without referencing SMIL3 at all. This can be removed again in a future SVG version, referencing SMIL3 already. OlafReceived on Thursday, 30 October 2008 13:31:37 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:29:38 UTC
*