Re: [csswg-drafts] [web-animations-2] controlling animation frame rate (#7196)

Thanks for this. I read through the explainer but I was bit unsure about exactly where in the rendering pipeline the change in frame rate is realized. Particularly this note:

> **Note:** there may be some nuances here around the timing of transition and animation events; for example, if the end of an animation iteration for a 30fps animation falls close to a 4ms boundary, when is the `animationiteration` events fired?

I think this applies equally to things like resolving the `finished` Promise, or updating `ResizeObserver` observers too. 

My understanding of the proposal is that we are suggesting modifying the [update animations and send events](https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events) procedure to partition the set of animations into separate buckets such that only a subset of animations might be updated each time? Is that right?

If so, I think it would require a shift in the way time values flow down the timing hierarchy. Potentially some animations are taking their current time value directly from the timeline whilst others are using a cached value? If so, perhaps the values returned by the API could look inconsistent?

Or would we always update all animations at the local maximum frame rate for a given timeline (i.e. the maximum frame rate for all animations attached to it) but only dirty style for those that need an update in this particular frame? That way at least all the values seems consistent from the API?

Incidentally, if we made the timeline the point where the frame rate was controlled I think we would avoid a lot of these issues. It's more clumsy, since you'd need to create a new `DocumentTimeline` instance (and the mapping to CSS might get a bit more awkward too) but at least the API would always be consistent and easy to understand.

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7196#issuecomment-1088167228 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 5 April 2022 01:00:47 UTC