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

Hi Brian,

My thoughts.

 > 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?

As far as I can tell, inserting an animation element isn't specified.

The closest thing I could find in SMIL 3 [1] says

[[
Language designers integrating SMIL Animation are encouraged to disallow 
manipulation of attributes of the animation elements after the document 
has begun.
... and ...
Dynamically changing the attribute values of animation elements 
introduces semantic complications to the model that are not yet 
sufficiently resolved. This constraint may be lifted in a future version 
of SMIL Animation.
]]

Inserting an animation element would be an extreme case of manipulating 
attribute values?

That being said, I can think of use cases where inserting animation 
nodes via script would be useful.

 > 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.

I think what Alex describes as a "discontinuous seek" is actually 
"evaluating the (first) current interval at insertion time" - similar to 
getting the first current interval when a time container starts.

Time seeking a single element doesn't make sense (to me) if the inserted 
element has time dependent nodes or is a time dependent node.  Other 
elemnts of the document can be affected so the whole document would need 
to be time seeked each time an animation element is inserted?

 > 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.).

(assuming that an implementation is aware that undefined syncbase 
references can become defined at any time and then establish the 
necessary relationships)

My expectation is that at t=6s, a evaluates its current interval and 
determines that it has an active interval.  a notifies b that there has 
been an interval change.  a also fires a beginEvent at t=6s with a 
timestamp of 1s.  b receives the notification from a and re-evaluates 
it's current interval.  Since the calculated interval has ended, b does 
not begin and does not fire a beginEvent.

Ken Stacey

[1] 
http://www.w3.org/TR/SMIL/smil-animation.html#animationNS-Integrating-ConstraintsOnAttributes

On 15/10/2010 12:02 PM, Brian Birtles wrote:
> 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:55:23 UTC