SMIL 3.0 Time Manipulations

14.1 Overview and Summary of Changes for SMIL 3.0

This section is informative.

The SMIL 3.0 specification leaves the SMIL 2.1 Time Manipulations Module [SMIL21-timemanipulations] unchanged.

14.2 Introduction

This section is informative.

This module introduces new attributes for advanced manipulation of time behavior, such as controlling the speed or rate of time for an element. These time manipulations are especially suited to animation and non-linear or discrete media. Not all continuous media types will fully support time manipulations. For example, streaming MPEG 1 video will not generally support backwards play. A fallback mechanism is described for these kinds of media.

Four new attributes add support for time manipulations to SMIL timing modules, including control over the speed of an element, and support for acceleration and deceleration. The impact on overall timing and synchronization is described. A definition is provided for reasonable fallback mechanisms for media players that cannot support the time manipulations.

An accessibility requirement for control of the playback speed is related to the speed control, but may also be controlled through some other mechanism such as DOM interfaces.

14.3 Module Overview

This section is normative

This section is informative

A common application of timing supports animation. The recent integration of SMIL timing with SVG is a good example of the interest in this area. Animation in the more general sense includes the time-based manipulation of basic transforms, applied to a presentation. Some of the effects supported include motion, scaling, rotation, color manipulation, as well as a host of presentation manipulations within a style framework like CSS.

Animation is often used to model basic mechanics. Many animation use-cases are difficult or nearly impossible to describe without a simple means to control pacing and to apply simple effects that emulate common mechanical phenomena. While it is possible to build these mechanisms into the animation behaviors themselves, this requires that every animation extension duplicate this support. This makes the framework more difficult to extend and customize. In addition, a decentralized model allows any animation behavior to introduce individual syntax and semantics for these mechanisms. The inconsistencies that this would introduce make the authoring model much harder to learn, and would complicate the job of any authoring tool designer as well. Finally, an ad hoc, per-element model precludes the use of such mechanisms on structured animations (e.g. applying time manipulations to a time container of synchronized animation behaviors).

A much simpler model for providing the necessary support centralizes the needed functionality in the timing framework. This allows all timed elements to support this functionality, and provides a consistent model for authors and tool designers. The most direct means to generalize pacing and related functionality is to transform the pacing of time for a given element. This is an extension of the general framework for element time (sometimes referred to as «local time»), and of the support to convert from time on one element to time on another element. Thus, to control the pacing of a motion animation, a temporal transform is applied that adjusts the pacing of time (i.e., the rate of progress) for the motion element. If time is scaled to advance faster than normal presentation time, the motion will appear to run faster. Similarly, if the pacing of time is dynamically adjusted, acceleration and deceleration effects are easily obtained.

The time manipulations are based upon a model of cascading time. That is, each element defines its active and simple time as transformations of the parent simple time. This recurses from the root time container to each «leaf» in the time graph. If a time container has a time manipulation defined, this will be reflected in all children of the time container, since they define their time in terms of the parent time container. In the following example a sequence time container is defined to run twice as fast as normal (i.e. twice as fast as its respective time container).

<seq speed="2.0">

<video src="movie1.mpg" dur="10s" />

<video src="movie2.mpg" dur="10s" />

<img src="img1.jpg" begin="2s" dur="10s">

<animateMotion from="-100,0" to="0,0" dur="10s" />

</img>

<video src="movie4.mpg" dur="10s" />

</seq>

The entire contents of&nbsp;the sequence will be&nbsp;observed to&nbsp;play (i.e., to&nbsp;progress) twice as&nbsp;fast. Each video child will be&nbsp;observed to&nbsp;play at&nbsp;twice the normal rate, and so&nbsp;will only last for 5&nbsp;seconds. The image child will be&nbsp;observed to&nbsp;delay for 1&nbsp;second (half of&nbsp;the specified begin offset). The animation child of&nbsp;the image will also &laquo;inherit&raquo; the speed manipulation from the sequence time container, and so&nbsp;will run the motion twice as&nbsp;fast as&nbsp;normal, leaving the image in&nbsp;the final position after only 5&nbsp;seconds. The simple duration and the active duration of&nbsp;the sequence will be&nbsp;21&nbsp;seconds (42&nbsp;seconds divided by&nbsp;2).

14.3.1 Overview of&nbsp;support

This section is&nbsp;informative

Three general time manipulations are defined:

accelerate, decelerate

These two attributes provide a&nbsp;simple shorthand for controlling the rate of&nbsp;progress of&nbsp;element simple time to&nbsp;simulate common mechanical motion. A&nbsp;simple model is&nbsp;presented to&nbsp;allow acceleration from rest at&nbsp;the beginning of&nbsp;the simple duration, and/or deceleration to&nbsp;rest at&nbsp;the end of&nbsp;the simple duration. This model has the advantage that it&nbsp;preserves the simple duration. The model is&nbsp;sometimes presented to&nbsp;authors as&nbsp;&laquo;Ease-In, Ease-Out&raquo;.

autoReverse

When set to&nbsp;&laquo;true&raquo; causes the simple duration to&nbsp;be&nbsp;played once forward, and then once backward. This will double the declared or&nbsp;implicit simple duration. Support for autoReverse is&nbsp;often presented to&nbsp;authors as&nbsp;&laquo;Play Forward, then Backward&raquo;.

speed

Controls the pacing (or&nbsp;speed) of&nbsp;element active time. The speed effectively scales the rate of&nbsp;progress of&nbsp;the element active duration, relative to&nbsp;the rate of&nbsp;progress of&nbsp;the parent time container.

When the speed of&nbsp;time is&nbsp;filtered with any of&nbsp;the time manipulations, this affects how a&nbsp;document time is&nbsp;converted to&nbsp;an&nbsp;element simple time. To&nbsp;understand this, think of&nbsp;the contents of&nbsp;an&nbsp;element progressing at&nbsp;a&nbsp;given rate. An&nbsp;unmodified input time value is&nbsp;converted to&nbsp;an&nbsp;accumulated progress for the element contents. Element progress is&nbsp;expressed as&nbsp;filtered time. This allows the effect of&nbsp;any rate (including acceleration and deceleration) to&nbsp;cascade to&nbsp;any timed children. If&nbsp;element progress is&nbsp;advancing at&nbsp;a&nbsp;constant rate (e.g. with a&nbsp;speed value of&nbsp;2), the filtered time calculation is&nbsp;just the input time multiplied by&nbsp;the rate. If&nbsp;the rate is&nbsp;changing, the filtered time is&nbsp;computed as&nbsp;an&nbsp;integral of&nbsp;the changing rate. The equations used to&nbsp;calculate the filtered time for a&nbsp;given input time are presented in&nbsp;Converting document time to&nbsp;element time.

The accelerate and decelerate features are applied locally on&nbsp;the simple duration, and have no&nbsp;side effects upon the length of&nbsp;the simple duration or&nbsp;active duration of&nbsp;the element. When applied to&nbsp;a&nbsp;time container, accelerate and decelerate apply to&nbsp;the time container simple duration and all its timed children, affecting the observed duration of&nbsp;the timed children.

The autoReverse feature is&nbsp;applied directly to&nbsp;the simple duration, and doubles a&nbsp;declared or&nbsp;implicit simple duration. Thus if&nbsp;the simple duration is&nbsp;defined (according to&nbsp;the normal timing semantics) to&nbsp;be&nbsp;5&nbsp;seconds, setting the autoReverse to&nbsp;&laquo;true&raquo; will cause the simple duration to&nbsp;be&nbsp;10&nbsp;seconds. Thus if&nbsp;the active duration is&nbsp;defined in&nbsp;terms of&nbsp;the simple duration (for example by&nbsp;specifying a&nbsp;repeatCount), then autoReverse will also double the active duration. However if&nbsp;the active duration is&nbsp;defined independent of&nbsp;the simple duration (for example by&nbsp;specifying a&nbsp;repeat duration, an&nbsp;end value and/or min and max values), then autoReverse may not affect the active duration. The active duration is&nbsp;computed according to&nbsp;the semantics of&nbsp;the Timing and Synchronization model; the only change is&nbsp;to&nbsp;use the modified (doubled) simple duration value.

The speed attribute scales the progress of&nbsp;element time for the element. When applied to&nbsp;a&nbsp;time container, the contents of&nbsp;the time container collectively play at&nbsp;the scaled speed. If&nbsp;an&nbsp;element plays twice as&nbsp;fast as&nbsp;normal, the observed simple duration will be&nbsp;only half as&nbsp;long as&nbsp;normal. This may or&nbsp;may not affect the active duration, depending upon how it&nbsp;is&nbsp;defined for the element. The attributes repeatDur, min and max are all measured in&nbsp;element active time, and so&nbsp;the associated values will be&nbsp;scaled by&nbsp;the element speed. Similarly, an&nbsp;element defined with a&nbsp;repeatCount will also be&nbsp;scaled, since the simple duration is&nbsp;scaled. However, if&nbsp;an&nbsp;element specifies an&nbsp;end attribute, the end value is&nbsp;not affected by&nbsp;the element speed. Offset values for the end attribute are measured in&nbsp;parent simple time, and so&nbsp;are excluded from the effects of&nbsp;element speed. Other values (including syncarc-values, event-values, etc.) must be&nbsp;converted to&nbsp;parent simple time, and are similarly unaffected by&nbsp;the element speed.

Note that a&nbsp;speed attribute on&nbsp;an&nbsp;element does not affect the element begin time. Offset values for the begin attribute are measured in&nbsp;parent simple time, and so&nbsp;are excluded from the effects of&nbsp;element speed. (The begin time is&nbsp;affected by&nbsp;any time manipulations on&nbsp;the parent or&nbsp;other ascendant time containers).

When these time manipulations are applied to&nbsp;a&nbsp;time container, they affect the way that the entire contents of&nbsp;the time container proceeds&nbsp;&mdash; i.e. they affect all timed descendants of&nbsp;the time container. As&nbsp;a&nbsp;global time is&nbsp;converted to&nbsp;element time, the time manipulations for each ancestor are applied, starting with the root of&nbsp;the timegraph and proceeding down to&nbsp;the parent time container for the element. Thus the simple time and active time for a&nbsp;given element are ultimately computed as&nbsp;a&nbsp;function of&nbsp;the time manipulations of&nbsp;all ascendant time containers, as&nbsp;well as&nbsp;any time manipulations defined on&nbsp;the element itself. This is&nbsp;described more completely in&nbsp;Details of&nbsp;timing model arithmetic.

The net cascaded speed of&nbsp;an&nbsp;element is&nbsp;a&nbsp;function of&nbsp;any time manipulations on&nbsp;the element and all of&nbsp;its ascendant time containers. Although this may be&nbsp;computed directly from the described values, the speed may also be&nbsp;thought of&nbsp;as&nbsp;the derivative of&nbsp;the rate of&nbsp;time (i.e. the rate of&nbsp;progress) at&nbsp;any point.

This section is&nbsp;informative

This model lends itself well to&nbsp;an&nbsp;implementation based upon &laquo;sampling&raquo; a&nbsp;timegraph, with non-linear media (also called &laquo;random access&raquo; media). The time manipulations model is&nbsp;based upon a&nbsp;model commonly used in&nbsp;graphics and animation, in&nbsp;which an&nbsp;animation graph is&nbsp;&laquo;sampled&raquo; to&nbsp;calculate the current values for the animation, and then the associated graphics are rendered. Some linear media players may not perform well with the time manipulations (e.g. players that may only play at&nbsp;normal play speed). A&nbsp;fallback mechanism is&nbsp;described in&nbsp;which the timegraph and syncbase-value times are calculated using the pure mathematics of&nbsp;the time manipulations model, but individual media elements simply play at&nbsp;the normal speed or&nbsp;display a&nbsp;still frame.

Some of&nbsp;the examples below include animation elements such as&nbsp;animate and animateMotion. These elements are defined in&nbsp;the Animation section of&nbsp;SMIL 3.0. Additional elements and attributes related to&nbsp;timing and synchronization are described in&nbsp;the Timing section of&nbsp;SMIL 3.0.

14.3.2 Attribute syntax

The accelerate and decelerate attributes

These attributes define a&nbsp;simple acceleration and deceleration of&nbsp;element time, within the simple duration. The values are expressed as&nbsp;a&nbsp;proportion of&nbsp;the simple duration (i.e. between 0&nbsp;and&nbsp;1), and are defined such that the length of&nbsp;the simple duration is&nbsp;not changed by&nbsp;the use of&nbsp;these attributes. The normal play speed within the simple duration is&nbsp;increased to&nbsp;compensate for the periods of&nbsp;acceleration and deceleration (this is&nbsp;how the simple duration is&nbsp;preserved). The modified speed is&nbsp;termed the run rate. As&nbsp;the simple duration progresses (i.e., plays back), acceleration causes the rate of&nbsp;progress to&nbsp;increase from a&nbsp;rate of&nbsp;0&nbsp;up to&nbsp;the run rate. Progress continues at&nbsp;the run rate until the deceleration phase, when progress slows from the run-rate down to&nbsp;a&nbsp;rate of&nbsp;0. This is&nbsp;illustrated in&nbsp;Figure&nbsp;1, below:

<animation dur="10s" accelerate="0.3" decelerate="0.3" .../>

Figure&nbsp;1: Effect of&nbsp;acceleration and deceleration upon the rate of&nbsp;progress.

These attributes apply to&nbsp;the simple duration; if&nbsp;these attributes are combined with repeating behavior, the acceleration and/or deceleration occurs within each repeat iteration.

accelerate = &quot; number &quot;

Defines a&nbsp;simple acceleration of&nbsp;time for the element. Element time will accelerate from a&nbsp;rate of&nbsp;0&nbsp;at the beginning up&nbsp;to&nbsp;a&nbsp;run rate, over the course of&nbsp;the specified proportion of&nbsp;the simple duration.

The default value is&nbsp;0 (no&nbsp;acceleration).

Legal values are floating point values between 0&nbsp;and&nbsp;1 (inclusive).

decelerate = &quot; number &quot;

Defines a&nbsp;simple deceleration of&nbsp;time for the element. Element time will decelerate from a&nbsp;run rate down to&nbsp;0&nbsp;at the end of&nbsp;the simple duration, over the course of&nbsp;the specified proportion of&nbsp;the simple duration.

The default value is&nbsp;0 (no&nbsp;deceleration).

Legal values are floating point values between 0&nbsp;and&nbsp;1 (inclusive).

The sum of&nbsp;accelerate and decelerate must not exceed 1. If&nbsp;the individual values of&nbsp;the accelerate and decelerate attributes are between 0&nbsp;and 1&nbsp;and the sum is&nbsp;greater than&nbsp;1, then both the accelerate and decelerate attributes will be&nbsp;ignored and the timed element will behave as&nbsp;if&nbsp;neither attribute was specified.

If&nbsp;the simple duration of&nbsp;the element is&nbsp;not resolved or&nbsp;if&nbsp;it&nbsp;is&nbsp;resolved to&nbsp;be&nbsp;indefinite, then the accelerate and decelerate attributes are ignored.

For details of&nbsp;computing the run-rate, and for converting from parent simple time to&nbsp;element simple time when accelerate and/or decelerate are specified, see Computing the element run-rate and Converting document time to&nbsp;element time.

This section is&nbsp;informative

Examples

In&nbsp;this example, a&nbsp;motion path will accelerate up&nbsp;from a&nbsp;standstill over the first 2&nbsp;seconds, run at&nbsp;a&nbsp;faster than normal rate for 4&nbsp;seconds, and then decelerate smoothly to&nbsp;a&nbsp;stop during the last 2&nbsp;seconds. This makes the motion animation look more realistic.

<img ...>

<animateMotion dur="8s" accelerate=".25" decelerate=".25" .../>

</img>

In&nbsp;the following example, the image will &laquo;fly&nbsp;in&raquo; from offscreen left, and then decelerate during the last second to&nbsp;&laquo;ease&nbsp;in&raquo; to&nbsp;place. This assumes a&nbsp;layout model that supports positioning (for example CSS positioning, or&nbsp;the position of&nbsp;a&nbsp;region in&nbsp;SMIL&nbsp;Layout).

<img ...>

<animate attributeName="left" dur="4s" decelerate=".25"

from="-1000" to="0" additive="sum" />

</img>

The autoReverse attribute

Another common mechanical phenomenon is&nbsp;that of&nbsp;a&nbsp;process that advances and reverses. Some examples include:

pendulum motion&nbsp;&mdash; a&nbsp;partial rotation that advances and reverses

pulsing effects&nbsp;&mdash; usually a&nbsp;scale transform, but sometimes an&nbsp;intensity or&nbsp;color change that advances and reverses

simple bouncing&nbsp;&mdash; motion that advances and reverses

Because so&nbsp;many common use-cases apply repeat to&nbsp;the modified local time (as&nbsp;in&nbsp;the examples above), this function is&nbsp;modeled as&nbsp;modifying the simple duration. As&nbsp;such, autoReverse doubles the declared or&nbsp;implicit simple duration. When combined with repeating behavior, each repeat iteration will play once forwards, and once backwards.

autoReverse = ( &laquo;true&raquo;&nbsp;| &laquo;false&raquo; )

Controls autoReverse playback mode.

Argument values are Booleans.

The default value is&nbsp;false (i.e. play normally).

When this is&nbsp;applied to&nbsp;a&nbsp;time container, it&nbsp;will play the time container forwards and then backwards. The semantics of&nbsp;playing a&nbsp;time container backwards are detailed in&nbsp;Implications of&nbsp;time manipulations on&nbsp;time containers.

This section is&nbsp;informative

The autoReverse time manipulation does not initially require a&nbsp;resolved simple duration, although it&nbsp;will not begin playing backwards until the simple duration is&nbsp;resolved and has completed. This may happen when the simple duration is&nbsp;defined by&nbsp;an&nbsp;unresolved implicit simple duration (such as&nbsp;the intrinsic media duration). In&nbsp;this case, the element will continue to&nbsp;play forward until the implicit simple duration is&nbsp;resolved (or&nbsp;until the active duration or&nbsp;the parent time container cuts short the simple duration, as&nbsp;described in&nbsp;the Timing section of&nbsp;SMIL 3.0). If&nbsp;the implicit simple duration becomes resolved before the end of&nbsp;the active duration, then the simple duration will be&nbsp;resolved to&nbsp;2&nbsp;times this implicit duration, and the implicit simple duration will play backwards.

Any time that the element will play backwards, including the second part of&nbsp;the autoReverse manipulation, the simple duration must be&nbsp;resolved. See also The speed attribute.

In&nbsp;this example, a&nbsp;motion path will animate normally for 5&nbsp;seconds moving the element 20&nbsp;pixels to&nbsp;the right, and then run backwards for 5&nbsp;seconds (from 20&nbsp;pixels to&nbsp;the right back to&nbsp;the original position). The repeating behavior causes it&nbsp;to&nbsp;repeat this 2&nbsp;more times, finally leaving the element at&nbsp;its original location. The computed simple duration of&nbsp;the animation is&nbsp;10&nbsp;seconds, and the active duration is&nbsp;30&nbsp;seconds.

<img ...>

<animateMotion by="20, 0" dur="5s" autoReverse="true" repeatCount="3"/>

</img>

In&nbsp;the following example the motion path will behave as&nbsp;above, but will end at&nbsp;the earlier of&nbsp;15&nbsp;seconds or&nbsp;when the user clicks on&nbsp;the image. If&nbsp;the element ends at&nbsp;15&nbsp;seconds (if&nbsp;the user does not click), the motion path will leave the element at&nbsp;the end of&nbsp;the defined path, 20&nbsp;pixels to&nbsp;the right. Since the active duration is&nbsp;defined by&nbsp;the repeatDur and end, the active duration is&nbsp;not affected by&nbsp;the autoReverse attribute in&nbsp;this case. The semantics of&nbsp;fill are not changed by&nbsp;time manipulations: the media state at&nbsp;the end of&nbsp;the active duration is&nbsp;used during any fill period. The end of&nbsp;the active duration may fall part of&nbsp;the way through a&nbsp;play forward interval, or&nbsp;part of&nbsp;the way through a&nbsp;play backward interval.

<img ...>

<animateMotion by="20, 0" dur="5s" autoReverse="true"

repeatDur="15" end="activateEvent" fill="freeze"/>

</img>

The accelerate and decelerate attributes may be&nbsp;combined with autoReverse, and are applied to&nbsp;the unmodified simple duration. For example:

<img ...>

<animateMotion by="20, 0" dur="4s" autoReverse="true"

accelerate=".25" decelerate=".25" />

</img>

This will produce a&nbsp;kind of&nbsp;elastic motion with the path accelerating for 1&nbsp;second from the original position as&nbsp;it&nbsp;moves to&nbsp;the right, moving slightly faster than normal for 2&nbsp;seconds, and then decelerating for 1&nbsp;second as&nbsp;it&nbsp;nears the points 20&nbsp;pixels to&nbsp;the right. It&nbsp;accelerates back towards the original position and decelerates to&nbsp;the end of&nbsp;the reversed motion path, at&nbsp;the original position.