Re: Events when adding and removing SMIL animation elements in play

Hi Brian,


	Sorry my vague recollections of the SMIL spec. are a bit dated, so
I checked our code to see what it does and yes it plays all the intervals
up the current seek time.

	So you are correct, the seek is continuous and all the begin/end
events will fire. I guess the corollory is that if a totally new node
is inserted the events will fire too.

	The question of insertion and replaying old intervals is tricky.
I don't know if that's specified anywhere. In our case, already played
intervals in time won't run again if the node is removed and then
reinserted (since whatever the interval stack is contains an entry
for the already run interval). But that doesn't mean it's correct.

Cheers,
Alex

--Original Message--:
>Hi Alex,
>
>Thanks for your comments here. They're very helpful. I need to go over
>this again and reconsider all the implications but I just wanted to
>check your final point here.
>
>On 14 October 2010 09:29, Alex Danilo <alex@abbra.com> wrote:
>> Most of your logic is OK, but you do need to remember that
>> the seek is discontinuous and so intermediate intervals that
>> get skipped on a seek should not generate any events cause
>> they never ran.
>
>Where is this specified?
>
>Firstly, let me check I've understood correctly. Would you agree a
>seek on a document (e.g. by calling svgElement.setCurrentTime) is
>continuous?
>
>After all, if you set up a series of syncbase dependencies and then
>perform a seek on the document the intervals DO run (but don't fire
>events).
>
>As SMIL says:
>
>  After seeking a document forward, the document should be in largely
>the same state as if the user had allowed the presentation to run
>normally from the current time until reaching the element begin time
>(but had otherwise not interacted with the document). One exception
>relates to event-based timing in the document, and is described
>below.[1]
>
>And again:
>
>  If the presentation is authored with no beginEvent, endEvent or
>repeatEvent based timing and no automatic hyperlinks, then state of
>the document after a seek should be identical to that had the document
>presentation time advanced undisturbed to reach the seeked-to time.[1]
>
>So at least that kind of seek is continuous otherwise syncbase
>dependencies would not be updated and the document would not be "in
>largely the same state as if the user had allowed the presentation to
>run normally".
>
>However, if I understand correctly, you're saying that the seek
>performed on an inserted element is a different kind of a seek: a
>discontinuous seek.
>
>However, my reading of SMIL's description of pruning vs cutting off
>this sounds like more of an instance of cutting off.[2]
>
>SMIL gives the example:
>
>  <par begin="-10s" dur="20s">
>   <img xml:id="slide1" src="slide1.jpg" dur="3s" />
>   <img xml:id="slide2" src="slide2.jpg" begin="slide1.end+3s" dur="10s" />
>   <img xml:id="note1" src="note1.jpg" begin="slide1.beginEvent" dur="20s" />
>  </par>[2]
>
>And in this case "slide1" is cut off. That is, it's not shown but it
>does run in the sense of triggering "slide2". Isn't inserting an
>element analogous to this?
>
>e.g. if we have:
>
>  <circle .../>
>   <animate id="b" begin="a.begin+5s" ... />
>  </circle>
>
>And at t=5s we append another child element to the circle as such:
>
>   <animate id="a" begin="1s" ... />
>
>My expectation is that 'b' would get notified of the interval and
>would run at t=6s even though 'a' would not be shown. That seems to me
>to parallel the example from SMIL quoted above (and seems to make
>intuitive sense too as if one seeks the document back to 0 and then
>forward to 5 again the interval will certainly be created as per [1].
>I realise event-based timing works differently in this case but SMIL
>also makes it clear that event-based timing is special in this
>regard.).
>
>I think intervals that are entirely <= 0 are a special case that SMIL
>makes quite clear are invalid because they are before the parent
>simple begin. Such intervals are filtered out of the model.
>
>Intervals that merely precede the current time appear to be a
>different case. The current time can change, even go backwards, the
>parent simple begin cannot.
>
>The issue of whether events fire in this case of inserting elements
>still remains. You've mostly persuaded me they should NOT fire events
>for these historic intervals (although I want to look over this once
>more). However, I'm yet to be convinced the intervals don't run at
>all.
>
>Thanks again Alex, looking forward to your feedback,
>
>Brian
>
>[1] http://www.w3.org/TR/SMIL/smil-timing.html#Timing-HyperlinksAndTiming
>[2] http://www.w3.org/TR/SMIL/smil-timing.html#q89
>
>
>

Received on Friday, 15 October 2010 03:21:37 UTC