W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2010

ISSUE-2306 (smil-integer): SMIL calcMode="linear" and animation of integers is underspecified [SVG Core 2.0]

From: SVG Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Thu, 18 Feb 2010 22:27:40 +0000 (GMT)
To: public-svg-wg@w3.org
Message-Id: <20100218222740.99ADAC6DB9@barney.w3.org>

ISSUE-2306 (smil-integer): SMIL calcMode="linear" and animation of integers is underspecified [SVG Core 2.0]

http://www.w3.org/Graphics/SVG/WG/track/issues/2306

Raised by: Jonathan Watt
On product: SVG Core 2.0

Here's the comment that I added to one of Mozilla's tests:

  <!-- Our implementation strategy for animating integers with
       calcMode="linear" is to use round(), with the slight twist that we
       round "to the NEXT value" when the current time puts us exactly midway
       between two integer values. (This is so that the result of midpoint
       rounding does not depend on whether we're animating up to a higher
       value or animating down to a lower value.) Note that one of the quirks
       of using round() is that the start and end values of any integer
       range only receive half as much time as any intermediary values. This
       is as you would expect mathematically, but it's probably unexpected
       for most users!

       We could try to avoid this round() quirk by coming up with a better
       implementation strategy for calcMode="linear", but animation of the
       few integer attributes in SVG 1.1 is extremely unlikely (so this
       issue is very low priority), and it's actually difficult to find a
       better strategy that doesn't have its own undesirable quirks.

       One alternative could be to divide the time evenly amoungst each
       integer. (I.e. it would be similar to calcMode="discrete", except it
       would also visit all the intermediary values, not just the start and
       end values). The issue with this approach is that for a simple "to"
       animation the animation wouldn't actually seem to change anything until
       interpolation reaches the second integer value. This could be avoided
       by skipping the initial value and distributing the time between the
       other values, but then in the case of a "from-to" animation where the
       from value is different to the underlying attribute value, the
       animation would seem to skip the first value. Not that the same sort of
       problem exists at the other end of the simple duration, where it will
       reach the final integer value before the end of the simple duration.
       This could be avoided by only setting the final value right at the end
       of the simple duration and distributing the time between evenly
       between the other values, but then the final value will only be seen if
       fill="freeze".

       There are many other problems with other implementation strategies. The
       more you think about them, add the complexity of 'values', 'by' etc,
       and think of cases where they behave strangely (e.g. animating between
       just two adjacent integers, up or down, etc.), the more ugly it gets.
       It's really not worth it for SVG 1.1. Maybe if you could use SMIL for
       'font-size' or something even more likely to be animated it would be.
  -->
Received on Thursday, 18 February 2010 22:27:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:43 UTC