Clarification of reset behaviour

Dear all,

I believe some clarification of restart and reset behaviour in SMIL is
required. Specifically, it is not clear to me at what point in the
element life-cycle the restart (and corresponding reset) actually
occurs. Please allow me to illustrate.

Consider an animation with begin="indefinite", restart="always" and
where the following sequence of calls are made by script at time t=0s:

  beginElementAt(1)
  endElementAt(2)
  beginElementAt(3)
  endElementAt(4)
  beginElementAt(5)
  endElementAt(6)

This should generate an interval: 1s-2s. After that I believe the
behaviour is somewhat unclear and perhaps contradictory for the
following reasons:

1) It is not clear when restart and particularly reset behaviour should apply

SMIL 3.0 describes the behaviour for resetting element state which
includes clearing all instance times generated by DOM calls and events
in the past with the exception of the instance time defining the
beginning of the current interval.[1]

However it is not obvious to me at which point this behaviour is
effected. I believe the most natural reading of the spec is that the
reset occurs at t=3s as that is when the animation "restarts".

Thus, in the example, after the interval 1s-2s plays to completion
another interval will be constructed from 3s-4s. At t=3s the animation
becomes active again, the animation restarts, and the instance times
are reset.

Whether this reset occurs at t=2s or t=3s will produce different
results if further instance times are generated between t=2s and t=3s,
that is, whilst the animation is waiting to begin.

More significant however is the next issue:

2) Some end instances must be preserved

In the example, if a reset is performed at t=3s, all instance times
generated by DOM calls made in the past will be cleared except the
instance time defining the beginning of the current interval, i.e. the
begin instance time at 3s. Since all the DOM calls occurred at t=0s,
they will all be cleared leaving only the one begin instance time of
t=3s.

(ASSUMPTION: SMIL 3.0 refers to, "Any instance times associated with
past Event-values, Repeat-values, Accesskey-values or added via DOM
method calls..." I understand this to mean instance times generated by
a DOM call where the DOM call occured in the past, NOT instance times
that are "in the past" according to their position in the document
timeline relative to the current time. I believe this is consistent
with the other prose describing reset behaviour.)

This behaviour is problematic because, in the example, we have an
active interval from 3s-4s but after resetting the end instance of 4s
will have been cleared. Thus any action that causes us to reevaluate
the current interval will result in us noticing that our end instance
has disappeared and causing the interval to unexpectedly change or
even be deleted.

3) It is not implemented (in SVG implementations)

In my tests of Batik 1.7, Opera 10.10, and WebKit nightly (10 Dec 09),
all three show three intervals (although all differ in their actual
results: Batik seems to ignore the end constraints, WebKit seems to
use the final fill value). That is to say that it does not appear that
the instance times are cleared upon a restart or else we would have
only 1 or 2 intervals (depending on some of the issues discussed
above).

This is perhaps the least significant issue but I mention it because
it suggests I have entirely misunderstood this behaviour, or that
implementors have taken issue with it/overlooked it/misunderstood it,
or both.

4) It is not consistent

This ties in with (1) and I will not elaborate on it here except to
note that if my understanding is correct, that in the example the
reset occurs at t=3s, then this will produce different results
depending on whether we are beginning the first interval or the second
interval (as we do not reset instance times at t=1s). It would be more
consistent if we perform reset behaviour upon ending an interval (i.e.
at t=2s) and in that case it must be specified whether the instance
times are reset before or after establishing the next interval
(presumably it is after since otherwise it would be meaningless to
talk about keeping the instance time that defines the beginning of the
current interval).

5) The analogue with backwards seeking is not obvious

The description of backwards seeking behaviour in relation to
hyperlinking provides the following:

  Resolved begin times (e.g. a begin associated with an event) are not
  cleared or lost by seeking to an earlier time. Resolved end times
  associated with events, Repeat-values, Accesskey-values or added via
  DOM method calls are cleared when seeking to time earlier than the
  resolved end time. This follows the semantics for resetting element
  state.[2]

I cannot see an obvious analogue here between this behaviour which
makes such a sharp distinction between begin and end instance times
and the behaviour for resetting element state where the distinction is
more subtle.

(Furthermore, the behaviour is problematic because, as with (2), if we
clear end instances in this manner we may in fact cause an historical
interval to be deleted altogether since there is now no longer any
matching end instance with which to construct an interval. This, to
me, seems contrary to the intent of the spec here. Rather, as with
(2), certain end instances must be preserved.)


Thank you for any help you can offer! I apologise for such a long
message. I hope we can clarify some of these matters because, as I
have noted in (3), current implementations all differ on these matters
from one another and, I suspect, from the specification.

Best regards,

Brian Birtles

[1] http://www.w3.org/TR/SMIL/smil-timing.html#q44
[2] http://www.w3.org/TR/SMIL/smil-timing.html#q114

Received on Monday, 14 December 2009 04:29:28 UTC