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

Hi Anthony,

Thanks very much for getting back to me on this. It's helpful to know
we're in agreement on the expected behaviour here.

Thanks again,

Brian

On 12 October 2010 13:14, Anthony Grasso
<Anthony.Grasso@cisra.canon.com.au> wrote:
> Hi Brian,
>
> These are just my thoughts without having looked anything up in detail - see below.
>
>> -----Original Message-----
>> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
>> Of Brian Birtles
>> Sent: Tuesday, 12 October 2010 11:20 AM
>> To: www-svg
>> Subject: Events when adding and removing SMIL animation elements in
>> play
>>
>> (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.
>>
>> 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.
>>
>> 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.
>>
>> 2) Animation progress is retained and when the element is re-attached
>> either a forwards or backwards seek is performed as required.
>>
>> Personally, I think (1) is more intuitive, particularly as the element
>> may be re-attached to a different time container altogether.
>>
>
> I agree (1) seems to be the behaviour I'd expect to happen. Option (2) could potentially be more expensive in terms of resource usage for an implementation.
>
>> 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.
>>
>> 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])
>> * 2 x beginEvent as a result of re-attaching the animation element
>> (which will drive the animation through begin times 2s and 6s)
>>
>> Then after 3s,
>> * 1 x beginEvent when the third interval begins (at t=10s)
>>
>
> Yes, that is how I would expect the animation to work as well.
>
>> 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).
>>
>
> I short I agree with you again. Really the animation was removed (interrupted) before it ran its full specified duration. With that in consideration, I think generating an endEvent would be unintuitive.
>
> Cheers,
> Anthony
>
>> Any thoughts here would be greatly appreciated.
>>
>> Best regards,
>>
>> Brian Birtles
>>
>> [1] http://www.w3.org/TR/SMIL3/smil-timing.html#q114
> The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
>

Received on Wednesday, 13 October 2010 03:01:36 UTC