[css-animationworklet] Allow animators to specify their desired frame rate

[majido]

From @majido on August 29, 2017 18:10

(Note: Issue was created based on feedback from Houdini Paris F2F - irc logs)

At the moment, the specification does not declare how frequent animation should be pumped and it is left up to the user agents with a recommendation to pump as fast as possible.

However, not all effects needs to be pumped as fast as possible and running them faster than necessary will lead to unnecessary power usage. Mechanisms to better optimize the frame pump rate per animation is useful.

Idea 1 - Explicit frame-rate declared

Have animators request a particular pump rate (e.g., at least once every 4ms). Browser then tries to pump the desired rate with option to slow down if animation is missing the deadlines. Perhaps notifying the animation of rate change.

Idea 2 - Speculative pump rate

Browsers can pump as fast as possible but if no change was produced then reduce frame rate. This can be problematic for effects similar to position-sticky where they don't produce update in many frames but want to be pumped every frame.

Copied from original issue: WICG/animation-worklet#88

[majido]

Here is the relevant discussion from IRC log:

dino: Also would like a flag specifying how fast timeline should pump. rAF is kinda 60Hz, but we now have variable-rate screens coming out, etc.
dino: So question is how to specify that from a worklet - message to the timeline saying "i wanna get called back more frequently/in at least 4ms"? And some feedback saying you're not meeting that goal, so you're getting scaled back.
flackr: Would you ever not want to run that fast?
dino: Yes, if your animation doesn't need to be 120hz, it's better to run at 60hz for power reasons.
astearns appreciates the verb tenses I might have used in those imaginable states where I would have been smart enough to talk about speculative threads
TabAtkins: This kinda sounds like various stream APIs, which let you attach to timelines at various coarseness.
brucel +1 to what tab said "if your animation doesn't need to be 120hz, it's better to run at 60hz for power reasons." - Opera desktop, for example, has power saving mode in which frame rate for video and animations is deliberately reduced
dino: and figuring out how fast a timeline can be pumped, asking for a particular pump rate, and getting updates that you're missing the deadlines and will be slowed from your requested rate.
dino: We tried running rAF at 120hz, but some animations assume it runs at 60hz and don't actually check the time delta, so they just run double-speed and break.
dino: We also determined that 120hz animations do use a ton more power.
astearns brucel that was actually dino
brucel This baffling new "IRC" technology is hard, apologies dino
dino: And there's some intermediate stuff - if you run at 120hz, but determine there was no change, don't repaint the screen.
flackr: Maybe speculate that it doesn't change, and throttle down?
dino: We see today's code, where people just run a rAF at all times...
Rossen: Speculating throttling based on update is tricky - position sticky needs fast updates, but does nothing until the element sticks...

[majido]

@flackr @bfgeek Do you have any ideas on potential API for option #1.

Also, I think we should perhaps look into how offscreen canvas is going to solves a similar issue.