(comments below)
On 4 September 2015 at 15:21, Kristopher Giesing <kris.giesing@gmail.com>
wrote:
> Are you suggesting that this global animation clock scaling would also
> affect the interpretation of values passed to setTimeout (which is also
> sometimes used to control animations)? That seems like it might be going a
> bit far...
>
Too far, I agree. For request animation frame, I wasn't suggesting that
you change how frequently the callback is run, only change the parameter it
receives. The author would decide whether and how to use it.
> As an alternative, the global animation clock could be exposed as one of
> several clocks, with APIs for converting values between clocks with
> different rates. That might add a lot of API though.
>
I don't know that you need multiple clocks, just access to the main
animation clock. For example, the SVG/SMIL clock's current time can always
be retrieved from the SVG element. Authors already have access to the
system clock through core JS functions. It would still tick away as normal.
That said, the full SMIL model (never implemented in SVG) does include the
concept of nested "time containers", each of which can be paused, sped up
or slowed down, but which also inherit changes to their parent's flow of
time. The main use is for syncing parts of an animation with audio, video,
etc., which might be paused without pausing everything in the document.
It's a something to keep in mind for future extensions.
~ABR