SVG Animation - Freezed values with calcMode="discrete"

Hello all.

I have some questions regarding freezed values in combination with
calcMode="discrete" in SVG/SMIL.

(Note that I don't necessarily take any side here, I would only like
  to hear other opinions and hopefully get some consensus on the matter,
  before eventually changing our current behaviour)

Consider this animation element, relentlessly ripped from its
surroundings: [2]

    <animate xlink:href="#c2"
         attributeName="cx"
	calcMode="discrete"
         attributeType="XML"
	values="100; 350; 600; 850"
	keyTimes="0;0.25;0.5;0.75"
	dur="12s"
	begin="0s"
	end="9s"
	fill="freeze" />

What is a bit unclear to me when reading the specification, is what
the freezed value should be?

_Ignoring_ the end attribute above, the application of values looks
like this in my head

(drawn as a graph)
       ^
       |
       |
       |              ------------ ...
   800 |
       |
   700 |
       |
   600 |         -----
       |
   500 |
       |
   400 |
       |    -----
   300 |
       |
   200 |
       |
   100 -----
       |
     0 +----|----|----|----|------>
       0s   3s   6s   9s  12s

(and in words)
The value of 0 is applied from 0s up until, but not including, 3s.
The value of 350 is applied from 3s up until, but not including, 6s.
The value of 600 is applied from 6s up until, but not including, 9s.
The value of 850 is applied from 9s up until, but not including, 12s.
The value of 850 is applied from 12s to indefinitely. (FROZEN)

When the active duration is shrunk to exclude the last sub-interval,
(using the end-attribute), how should the freezed value be calculated?

Dr. Hoffman says[2]:

"begin and end define a time interval, this means, the intervals
starts with included 0s and ends with excluded 9s. Therefore the final
presentation value is 600 and not 850."

This _sounds_ reasonable, but it does not fit into our current model
in Opera how to calculate freezed values:

In Opera currently, the value to apply in the frozen state is the
value calculated using the exact time where the active duration
ends. If the interval ends at 9s, as in this example, we use 9s to
calculate the value of the freezed value. This value gives 850 and not
600 since we treat the sub-intervals as end-point exclusive. This is
the issue being brought up by Dr. Hoffman.

What Dr. Hoffman suggests, is to in some way "see" what the last
applied value within the (end-point exclusive) active duration is, and
use that as freezed value.

To me, this last applied value is not easily mapped to a _point in
time_ and this is where I would like some clarification.

At which point in time should the freezed value be calculated, if
any? And if that can not be defined for discrete animation, how should
the freezed value be calculated (when as in this example the active
duration is shorter than the simple duration)?

Currently, viewers do the following:

  - Opera does what I describe above (850 as freezed value)

  - Batik (SVN from 070104) share the behaviour of Opera. (850 as
    freezed value)

  - Adobe SVG Viewer 3.01 seems to do what Dr. Hoffman suggests. Not
    sure how, though. (600 as freezed value)

  - KSVG? I'm not sure that KSVG supports calcMode or not. The test
    case did not work with my installed version
    (ksvg_3.5.5-2_i386.deb).

[1] http://www.w3.org/TR/2001/REC-smil-animation-20010904/#IntervalTiming
[2] http://olaf.kilu.de/opera/#b2006060501

-- 
David Vest <davve@opera.com>

Received on Thursday, 4 January 2007 13:37:48 UTC