- From: Brian Birtles <birtles@gmail.com>
- Date: Fri, 25 Mar 2011 11:16:02 +0900
- To: www-svg <www-svg@w3.org>
Dear all, I would like to propose an amendment to SVG 1.1 regarding the behaviour of frozen to-animation. Currently, SMIL Animation defines the following behaviour for a to-animation when it becomes frozen: The value for F(t) when a to-animation is frozen (at the end of the simple duration) is just the to value. If a to-animation is frozen anywhere within the simple duration (e.g., using a repeatCount of "2.5"), the value for F(t) when the animation is frozen is the value computed for the end of the active duration. Even if other, lower priority animations are active while a to-animation is frozen, the value for F(t) does not change.[1] SMIL 3.0 defines the same behaviour but with different wording: A frozen to animation takes on the value at the time it is frozen, masking further changes in the underlying value. This matches the dominance of the to value at the end of the simple duration. Even if other, lower priority animations are active while a to animation is frozen, the value does not change.[2] I find this behaviour to be counter-intuitive when a to-animation is frozen part way through its simple duration (e.g. using repeatCount=0.5). In such a case I would expect the partially applied to animation to continue to constrain the underlying value but not mask it completely. See the following test case: http://brian.sol1.net/svg/interop/frozen-to-animation-simplified.svg The dotted line shows the behaviour defined by SMIL. Current status of implementation: --------------------------------- WebKit -- Sets the 'to' value when frozen even if frozen part-way through the simple duration (i.e. ignores the 'at the time it is frozen' condition). Opera -- The value continues to change but is constrained by the partly applied to-animation (i.e. ignores the 'masking further changes in the underlying value' condition) Firefox -- Follows the spec I believe (there is code specially for this condition) but fails when seeking the document or if the frame-rate is low. Not only is this behaviour counter-intuitive (or at least, that's my contention), but it is difficult to implement. Consider what the user agent must do when a seek is performed: 1. Detect any such to-animations that become frozen within the seek interval 2. Seek to the time when the animation becomes frozen 3. Sample all underlying animations at that point in time 4. Store the underlying animation value 5. Proceed to the next such point, and so on before finally proceeding to the seek time In fact, this is not only the case for seeking but is necessary on every sample since a low sample rate may mean we skip over the time when the animation became frozen. If we simply say that a frozen partially-complete to-animation constrains but does not mask the underlying value then this complication is avoided and no special casing is required. Proposed change: ---------------- In section 19.2.9 'Attributes that define animation values over time' change the paragraph: The processing rules for the variants of from/by/to animations are described in Animation function values. to: The processing rules for the variants of from/by/to animations are described in Animation function values with the following exception. For the case of a to-animation that is frozen within its simple duration, the frozen animation continues to constrain the underlying value rather than masking it completely as SMIL Animation defines. That is, the result of F(t) will continue to change as the underlying value, v_cur, continues to change, but the value of t used for interpolation remains fixed at the end of the active duration. That last sentence is a bit cludgy. It's a bit hard to fix the wording of SMIL Animation when it comes to these formulae (since SMIL Animation contains a number of inaccuracies rectified in subsequent specifications such as describing v_cur in terms of the base value rather than the underlying value). For SMIL 3.0 it's simple, just drop the f_f(t,u) = v_f formula altogether, no special case is required. Rationale: ---------- In summary the current behaviour is: * Counter-intuitive (as evidenced by the special casing required in the specification and in implementations) * Hard to implement * Not implemented correctly (anywhere I'm aware of) The proposed behaviour removes the need for special casing and is already implemented in Opera. Best regards, Brian [1] http://www.w3.org/TR/smil-animation/#FromToByAndAdditive [2] http://www.w3.org/TR/SMIL/smil-animation.html#animationNS-ToAnimation
Received on Friday, 25 March 2011 02:16:48 UTC