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

Hi Brian,

	SMIL people probably know more about this than me, but a couple
of comments inline:

--Original Message--:
>(This was originally posted to www-smil, but as suggested there, I'm
>reposting to www-svg since there are probably more people actively
>working on SMIL in this list.)
>
>Dear all,
>
>I wish to clarify the expected behaviour of SMIL animations that are
>dynamically removed and added from a document with regards to the
>events that are generated.
>
>Suppose an animation is in play when it is temporarily removed from
>the document. Later, that same animation is re-attached to the
>document. In the meantime however, the time of the document (or, more
>accurately, the time container) may have changed either through
>seeking the document or simply due to the wallclock time that has
>elapsed.

If it is temporarily removed, at the time of removal it effectively
disappears from the SMIL sandwich. What happes due to that are
your questions below. Remember it's just one active time interval
in the sandwich.

>When the animation is re-attached it must either catch-up or wind back
>to the document time. However, just how this should be done is not, so
>far as I know, specified.

Well, I don't know if catch-up/wind-back is the right way to look
at it but I get what you are asking.

>Some options include:
>
>1) When the element is removed, all information regarding the
>animation's progress is lost. Re-attaching effectively performs a kind
>of forwards-seek on the animation.

Well the animation is removed from the SMIL sandwich - in the simple
case, i.e. one animation the animation stops happening and presumably
the effects of fill="..." and additive/accumulate would cease to
have an effect on the document while it's been removed.

Whether the animation node 'remembers' the time intervals that have
run and associated info doesn't seem to be specified.

Generally you can pick any time and the animation element if
inserted dynamically 'jumps' to the current time and the SMIL
intervals are keyed off that time.

e.g. if you had (out of tree) <animation begin="3s" dur="2s"...
and inserted it into the tree at 4s, then it would start the
animation, generate a begin event for the new interval and
the first value that gets applied is half way through the
animation, so it's calculated once, there'e no catch up and
the animation progess between 3s and 4s never happens.

Thought experiment: the animation element above is in the
original document, removed at 4s and re-inserted at 4.1s.
What happens?

You'd expect the thing being animated to skip the 0.1s of
animation, as there are 2 separate instances of the animation
since nothing happens in the 0.1s since it's not in the tree.

The animation has ended at 4s, by removal or by end of the
time since it did end. So should the end event fire when
it's removed from the tree? Probably yes.

What will happen on re-insertion is that the animation is not
running anymore since it wasn't in the tree. The SMIL logic
should see that the node has a begin/end interval that means
it should run. The SMIL code then generates a new interval
to run, fires the begin event and sets the interpolated time
to 4.1s.

If you didn't fire the end event on removal of a running animation
you'd end up with 2 begin events and one end event at 5s or so.
Seems a bit non-intuitive.

Remember in SMIL a new simple duration or whatever it's called is
generated as each animation starts/ends. So the single animation
node above would have generated two intervals since it was in
and out of the tree just as a node with 2 begin/end times would.

I don't think you'd discard anything. Just the logic of what you
do with what you already had needs to be handled. The knowledge
of intervals that have run etc. is probably owned by the node
and not by the SMIL machinery which manages nodes in the tree
and does the interpolation calculations, etc.

>2) Animation progress is retained and when the element is re-attached
>either a forwards or backwards seek is performed as required.

Yes the SMIL model is pretty clear here.

Imagine <animation begin="-10s, -5s, 0s" dur="2s" ...

in the original document that starts at time 0. In the absence of
any seeking the only interval run is the one from time 0s.

>Personally, I think (1) is more intuitive, particularly as the element
>may be re-attached to a different time container altogether.
>
>However, regardless of which it is, there is still the question of the
>nature of the seek. Generally, when seeking is performed most events
>that would otherwise be generated along the way are suppressed.[1] So,
>is attaching an element a genuine seek in that sense or should all
>events still be generated? My feeling is that they should still be
>generated.

No they should not.

The example above will not generate an event for -10s, -5s etc.
because the animation did not run. The end time was past the
current time and so in SMIL no interval was created.

This is covered in Patrick Schmitz's document about the animation
for Batik design which I think you have. SMIL is pretty clear
that intervals before the current time will not magically be
generated and so, no events should be generated either.

>Thus for the attached example which I've simplified below:
>
><svg>
> <script>
>   function seek()
>   {
>     svg.setCurrentTime(11);
>     circle.removeChild(animate);
>     svg.setCurrentTime(7);
>     circle.appendChild(animate);
>   }
>   document.addEventListener("SVGLoad", seek, true);
> </script>
> <circle ...>
>   <animate begin="2s; 6s; 10s" dur="2s" id="animate" .../>
> </circle>
></svg>
>
>My understanding is that we should get:
>
>* 1 x beginEvent as a result of the initial seek to t=11s (as per my
>interpretation of [1])

Yes.

>* 2 x beginEvent as a result of re-attaching the animation element
>(which will drive the animation through begin times 2s and 6s)

No. It's a seek, not a hyper fast forward.
There should be 1 beginEvent at 7s when the SMIL interval was
added to the nodes interval stack (can't remember the terminology
here exactly).

There's also and endEvent at t=8s.

>Then after 3s,
>* 1 x beginEvent when the third interval begins (at t=10s)

Yes

>Another issue is whether detaching an animation that is in play should
>generate an endEvent. Personally I think it should not since otherwise
>a lot of events would be generated on document teardown unless
>implementations differentiate between these two situations
>(script-based removal and document teardown).

The begin/end events are generated when an animation begins and
ends an interval. Whether that's from time or removal from the
tree is something that can be argued. Insertion into the tree
should definitely generate a begin event.

Removal is debatable I guess. For simplicity I agree detaching
the animation shouldn't generate an endEvent because of your
reasoning at least for document teardown, but I'd be inclined
to generate them for scripted node removal since the document
is still active and there may be chained animations that are
listening for the end event - the listened to animation would
stop and the dependent ones would never trigger.

>Any thoughts here would be greatly appreciated.

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.

Cheers,
Alex

>Best regards,
>
>Brian Birtles
>
>[1] http://www.w3.org/TR/SMIL3/smil-timing.html#q114
>
>
>

Received on Thursday, 14 October 2010 00:30:07 UTC