- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Fri, 11 Aug 2023 13:57:52 +0000
- To: public-css-archive@w3.org
> * Fade animations (opacity, color, some filters) where lower frame rates are less noticeable > * Animated content that uses a steps() timing function > > It would be trivial to automatically bump at least these last two into a lower frame rate. IMO rather than exposing an API for this, which so far is pretty poorly defined, it would be better to spec out values/easings that should run at a lower frame rate via CSS/WAAPI and limit those to 60fps. Steps is in fact already optimizable, and there are some optimizations in place in blink for this. A couple challenges we ran into working with developers to lower the framerate of some animations using steps: * Developers need to calculate the number of steps themselves, this was hard in some cases * The CSS animations api can't combine steps + non-linear easing. With web animations you can apply a steps animations-wide easing and have a other per-keyframe easings to do this. * Technically, if you don't coordinate the start times of multiple animations running using steps the browser is still supposed to tick them independently which means they aren't technically optimizable. I do worry about degrading experiences automatically without some developer control -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7196#issuecomment-1674839491 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 11 August 2023 13:57:54 UTC