W3C home > Mailing lists > Public > www-smil@w3.org > July to September 2010

Events raised during a seek

From: Brian Birtles <birtles@gmail.com>
Date: Tue, 10 Aug 2010 12:56:26 +0900
Message-ID: <AANLkTikepFZeSHu+RVqK0jCoWfXFc2G6A9QBoUA13WAd@mail.gmail.com>
To: www-smil@w3.org
Dear all,

I wish to clarify the behaviour of events raised as a result of
seeking a time container as described in SMIL 3.0 Timing and
Synchronization, 5.4.5 Semantics of the Timing Model, Hyperlinks and
Timing: http://www.w3.org/TR/SMIL3/smil-timing.html#q114

There are two issues:

1) beginEvents raised from seeking

For the case of a forwards seek we have:

  If the element ends during the seek interval, an endEvent is raised.
The associated time for the event is the document time before the
seek.

For a backwards seek we have something similar:

  If an element is active at the time of hyperlinking and the
element's current interval begins during the seek interval, the
element is turned off and an endEvent is raised. The associated time
for the event is the document time before the seek. This action does
not resolve any times in the instance times list for end times.

In summary, if the seek ultimately results in a transition from active
to inactive, regardless of how many intervals may have been skipped
over along the way, we raise an endEvent.

Should we not also raise a beginEvent for the reverse situation, a
seek that results in a transition from inactive to active?

For example, an animation has an interval from 2s to 4s. At 5s a seek
is performed on the time container to 3s. I believe a beginEvent
should be raised in this situation. (As to what timestamp is
associated with the event I am unsure.)

repeatEvents are explicitly said not to be raised, understandably.
However, beginEvents are not mentioned except to say they are not
raised for intervals that are entirely skipped.

The use case I have in mind is some script that should be synchronised
with an animation and registers for beginEvents and endEvents. Perhaps
it changes the background colour of the containing web page whilst the
animation is active. It simply needs to know when the animation is
active and when it is not.

2) Ignoring events raised from backwards seeking

The second issue is whether events raised as a result of a backwards
seek should be ignored.

If the purpose of a backwards seek is largely to restore the state of
animation at an historical time then it seems that firing additional
events could undermine that.

For example, consider the following test case:

<svg xmlns="http://www.w3.org/2000/svg" onload="seek()">
  <script type="text/javascript">
    function seek()
    {
      var svg = document.documentElement;
      svg.pauseAnimations();
      // See into the middle of the interval and then back to
      // before the interval was begun
      svg.setCurrentTime(0);
      svg.setCurrentTime(30);
      svg.setCurrentTime(10);
    }
  </script>
  <rect width="100" height="100" fill="green">
    <set attributeName="x" to="0" begin="20s" dur="20s" id="a"/>
    <set attributeName="fill" attributeType="CSS" to="red"
      begin="a.endEvent"/>
  </rect>
</svg>

In this case it seems that the backwards seek should not trigger the
second animation if the expected behaviour is to restore the animation
to its state at 10s.

More generally, it seems that performing a backwards seek from the
middle of an active interval to a time prior to the interval begin
should not trigger animations that are waiting for the intervals end
event.

Is this correct?

(I note that the sentence quoted in section (1) above, "This action
[raising an endEvent as part of a backwards seek] does not resolve any
times in the instance times list for end times." was added as an
erratum to SMIL 2.0 but this does not seem to be related. It refers
only to the list of end instance times (in the example it is a begin
instance time that we don't want to resolve) and therefore presumably
refers to the end instance time list of the animation that is being
seeked and not that of any dependent animations.)


Thank you in advance for any help you can offer!

Best regards,

Brian Birtles
Received on Tuesday, 10 August 2010 03:56:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 10 August 2010 03:56:59 GMT