- From: a c <acstimpl@yahoo.com>
- Date: Fri, 27 Feb 2004 13:39:43 -0800 (PST)
- To: www-smil@w3.org
- Message-ID: <20040227213943.40542.qmail@web21403.mail.yahoo.com>
Hello, I am writing an implementation of SMIL and would like to support dynamic updates to the timeline, such as adding & removing elements, adding & removing begin & end values, and updating attribute values such as dur and min after the presentation has already started playing. My question is, for dynamic updates to the timeline, what is the acceptable behavior in relation to backwards seeking? For example, let's say the client removes an element that had an interval, and then does a backwards seek. The spec states that once resolved, begin times are not cleared by seeking to earlier times, and are only cleared when the element resets. Does this mean, then, that previous intervals of the element (and related resolutions of other elements) should occur again this time around? (I didn't see any mention of behavior of the timeline in relation to dynamic dom updates, but if exists somewhere, please point it out to me). Alternatively, since it has been removed, should the timeline behave as if the value never existed in the time graph? The same question arises for removed/added begin/end values, and changes made to attributes such as min/max, dur, etc, and any resultant resolutions. One thought is that any change to the element should be treated as destroying the old element, removing all instances from the time graph and essentially as adding a new element to the time graph. If this is the case, then all related resolutions and intervals would be cleared from the graph whenever such a change occurs, and backwards seeking will not display any such intervals. Also, regular playback of the timeline without seeking will progress as if the removed element never existed in the first place (by removing all resolutions of instances related to the removed element). Is this an acceptable approach? I'd appreciate any opinions, suggestions, or pointers to places where this has been addressed before. Thanks, Annie --------------------------------- Do you Yahoo!? Get better spam protection with Yahoo! Mail
Received on Friday, 27 February 2004 16:39:44 UTC