- From: Ken Stacey <ken@svgmaker.com>
- Date: Fri, 15 Oct 2010 15:14:45 +1000
- To: Brian Birtles <birtles@gmail.com>
- CC: www-svg@w3.org
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