[web-animations] Fixing start times for new animations

Hi,

Following up on the discussion in the last telcon[1] here is a strawman 
proposal for one way to approach start times in Web Animations.

Problem: Creating new animations to start at the current time, where 
current time=time of last sample, is problematic for two reasons:

   1. Sometimes the distance between the last sample and the next one is 
massive
    e.g. If we have a hidden iframe, we might decide not to sample it 
all. As a result the current time won't change. If we later add 
animations based on that current time as their start time and then 
unhide the iframe we'll jump well into the animations or probably past them.
    Likewise if you sleep your laptop you get the same problem.
    You'll also see it if you're in a background tab that's been 
throttled really low.

   2. Sometimes the first render takes a long time because there is some 
overhead in setting up the animation meaning you skip several of the 
first few frames. e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=790592

Straw man proposal:

   * Element.animate(), AnimationTimeline.play() etc. create a player 
with a *pending* start time. Querying the computed timing at this point 
will just give you back mostly null/dummy times for properties like 
"localTime" much like you'd get if the player wasn't attached to a timeline.
   * When the UA has rendered the first frame, it resolves the start 
time allowing all the other computed timings to be resolved.
   * AnimationPlayer has a 'ready' attribute that is a Promise that is 
resolved with the start time once the player starts.

Question: How do you synchronize stuff while the player has a pending 
start time?

Answers:
(1) Stick the stuff in an animation group/sequence
(2) Use AnimationPlayer.ready to setup dependent actions that can't be 
expressed in a group

Possible additional answer: We *could* also say that, all players that 
were made pending at the same sample time, are resolved with the same 
start time. However, I'm not sure if that would impose unnecessary 
architectural restraints (e.g. if one animation is to be run in a 
different process but there is overhead in doing so, should we require 
UAs to delay all other pending animations from that sample moment until 
it is set up?)

Supposing we *did* do that, then you'd have another means of 
synchronizing. Just call play()/animate() within the same execution 
context/task and the independent animations will start in sync. (If you 
need them to be offset, use the source content's delay.)

Best regards,

Brian

[1] http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0082.html

Received on Wednesday, 7 May 2014 02:48:32 UTC