SMIL:Challenges

From MozillaWiki
Jump to: navigation, search

Following is a collection of difficulties encountered in implementing and authoring SMIL as well as some wishes for the future.

Pain points

  • Discrete to-animation is counter-intuitive. As discussed in bug 544855, particularly comments 11 and 12 and the referenced test cases, the behaviour defined here is likely to cause headaches for authors. Various browsers and even test cases in the SVG test suite do not follow the spec here, further suggesting it is counter-intuitive.
  • Frozen to-animation is hard to implement and counter-intuitive. As described in detail here, correct frozen to-animation requires visiting the time at which a to-animation finishes and becomes frozen and storing the underlying base value at that time. This is particularly difficult to implement when seeking and also seems quite counter-intuitive.
  • Resetting of instance times is confusing. See this thread on www-svg. There are a whole lot of difficulties with this behaviour. As described in this thread a sequence of calls such as beginElementAt(3); endElementAt(4) can cause us to create a new interval, begin it, and then instantly delete it since the end time will be reset.
// Events leave the end open-ended. If there are other conditions
// that have not yet generated instances, they must be unresolved.
if endHasEventConditions()
   OR if the instance list is empty
   tempEnd = UNRESOLVED;
// if all ends are before the begin, bad interval
else
    return FAILURE;
  • This causes havoc. The presence of a single end time or end instance changes the behaviour considerably. See particularly these two messages. Furthermore, at least one test in the SVG 1.2T test suite requires further modification of this code to support certain types of self-referential end conditions.
  • Perhaps this condition makes sense for other types of media, but for SVG it would probably be best to remove this condition altogether (i.e. let tempEnd be unresolved which will subsequently be overwritten with the calculated active end). In the mean time, most animations can probably get more consistent behaviour by adding an indefinite end instance time (i.e. end="... ; indefinite").
  • animateTransform requires clarification. We've encountered a number of problematic areas here although these are not so much problems with the SMIL model as with the SVG spec.

Other areas of simplification

  • Remove min and max properties. They don't seem useful to SVG at least. Can anyone put forward a case for keeping them?
  • Remove syncbase timing and use time containers instead. More description to come but for now see the section on future features below. This could potentially make SMIL several times simpler and more consistent addressing a lot of the concerns on this page. Definitely warrants investigation.

Areas requiring clarification

  • Tree surgery. For example:
    • If an <animate> element is removed whilst in play and later rebound what animation state is preserved? Currently we discard all animation state and recreate it since the element may be rebound to another container. See http://lists.w3.org/Archives/Public/www-svg/2010Oct/0048.html and discussion in bug 628407.
    • Similarly if an <svg> element is removed and rebound what state is preserved? Currently we remember the current time. This is problematic because when we rebuild the timegraph there may be many events that need to be dispatched leading to a performance hit. See bug 628407. Can we say that the document acts as if a seek were performed and suppress most events?
    • Tests would also be welcome for dynamic modification of timing properties. For example, if the fill attribute is set to 'freeze' after an animation has finished, presumably the appropriate fill value should be instantly applied. This is not specified but seems intuitive and should be tested.

      Perhaps we can follow Jansen et. al's approach of testing a change to each attribute/element when the affected item is:
      1. currently active
      2. has been active in the past
      3. will only become active in the future
  • Inter-document dependencies. We currently allow separate SVG document fragments within the one compound document to have syncbase dependencies. This introduces a bit of complexity with regards to updating dependencies when fragments are paused independently. At very least some tests in this area would be good.
  • Syncbase cycle detection. See this test case which produces different results in every browser we've tested.
  • Animation sandwich priorities. Last I check we were the only ones who'd implemented this. Is there a reason?

Future features

  • The swelling button use case. That is, create a button that swells over a period of 1s on mouseover, and shrinks at the same rate back to its original size on mouseout. Currently this does not appear to be possible if the mouseout occurs midway through the swelling phase. If the mouseout occurs after 0.3s, it should take 0.3s to return to the original size.

    Suggest this should be a container level operation so that a group of animations could be reversed easily and sensibly. See the next point.
  • Cancelling a chain of animations. For example: A, B, and C are configured in a chain so that, e.g. B.begin = A.end+1s; C.begin=B.begin+3s. A has both a simple duration and an end event, e.g. <animate dur="5s" end="elem.mouseout" .../>

    We'd like to distinguish between A running to completion (in which case we want B and C to play) and A being cancelled via a mouse out event (in which case we DON'T want B and C to play). This is very tricky to achieve with SMIL animation but is perhaps easy with SMIL time containers (e.g. <seq> -- although I'm not sure that <seq> will do the job when we want B.begin = A.end-1s)
  • Ability to apply the same animation to a range of elements. Aka SMIL Timesheets. Note that the interaction with syncbase timing needs to be considered here. For example, any change to the document structure could potentially cause rebuilding of the timegraph since new intervals may be created/deleted potentially triggering a chain of updates.
  • Co-operation with CSS Transitions / Animation. So far as possible it would be good to have both a shared syntax and timing model. It should be possible to synchronise the two. They should probably also dispatch the same events and have similar DOM interfaces. Better still, could we just have one spec?
Retrieved from "https://wiki.mozilla.org/index.php?title=SMIL:Challenges&oldid=284966"