As described in the post linked below there's a potential point of confusion with regards to how event-based timing that uses TimeEvents interacts with backwards seeking. Specifically, when a backwards seek is performed certain TimeEvents may be fired which may trigger animations to start such that the state of animation does not correspond to the state when that time was previously visited. See: http://lists.w3.org/Archives/Public/www-smil/2010JulSep/0004.html Although in that query I suggested that we should probably ignore TimeEvents resulting from a backwards seek I'm no longer sure that's right. Firstly, it gets really confusing when you have dependencies in other time containers. Should you ignore the event in that case? Secondly, it may be possible to do something reasonable by setting the timestamp of the event appropriately (as the text of the SMIL spec suggests). That, of course, depends on us setting the timestamp correctly (bug forthcoming). I'm filing this bug to track the response from www-smil. Depending on the feedback there we may decide not to do anything.
This patch just demonstrates one potential fix to this situation. I'm NOT suggesting we apply it for the following reasons: 1) As described above, I'm doubtful about if we really need to ignore these events or not. 2) The patch creates a new event type to store the extra bool representing if this is an event we should ignore or not. If we first fix the timestamps in TimeEvents we can probably do without this new event type. 3) There's the outstanding issue of what to do with dependencies in other time containers. So I'm just posting this for posterity.
9 years ago
Assignee: nobody → birtles
I no longer think this is necessary.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.