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

Oops.  Re-reading my last message.. I made an error... for some reason I 
had  begin="1s" dur="5s" in my head.  Sorry for any confusion.

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

The last part should read - The calculated interval begins at 6s and b 
fires a beginEvent.

Which is what Brian expects

 >  > My expectation is that 'b' would get notified of the interval and
 >  > would run at t=6s even though 'a' would not be shown.

What I don't agree with is that there is any document time seeking back 
and forward required.  Only current interval evaluation.

Ken

On 15/10/2010 1:54 PM, Ken Stacey wrote:
> 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 05:15:37 UTC