- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Aug 2023 15:46:26 +0000
- To: public-css-archive@w3.org
> However, playback rate already has a very specific definition of how it affects animation timing which is heavily used in many of the calculations Right, so effectively when calculating [current time for ScrollTimeline](https://www.w3.org/TR/scroll-animations-1/#scroll-timeline-progress): ``` current time = scroll offset ÷ (scrollable overflow size − scroll container size) ``` You get: ``` current time = = last current time × (1 - playback rate) + scroll offset ÷ (scrollable overflow size − scroll container size) × playback rate ``` Where `last current time` is the last cached value for current time. And of course it follows that: > A negative playback rate is also used to reverse animations That still holds true. > This would make playback rate have special behavior for non-time based animations Yes, but not something we don't already have. > and it would be really hard to avoid unexpected issues when other timing related properties change at the same time - as the proposed behavior is based on the previous state. I tried to see how, I think the we can infer the rest of the properties from the above formula. > E.g. what happens if you change the start time of the animation, or the duration, does it slowly progress towards the new time value? Yes. After reflow the next frame should calculate the new progress, according to the cached value and new layout, and produce the next frame. So you'll get an interpolation towards the new progress value. > Naively, this would make the speed of the adjustment depend on the frame rate the browser is able to render or particular device framerates. I would think that if we have a mechanism for doing this it should be framerate independent, i.e. based on the time that had passed. Yes, for sure. I think one way to make it framerate independent could be normalizing the frame rate to 60fps (or the timeline's frame rate according to #7196), but I think this requires something that's not a trivial division. Otherwise, yes, we'd need to base that on timestamp deltas. > Also while the progress per frame is a linear interpolation, the progress over time will be non-linear, e.g. it'll make 0.5, then 0.75, then 0.875 progress never technically getting to the current time value. Exactly. The result creates a nice some-sort-of-bezier curve movement. This is expected. But I think using linear interpolation for the core calculation is pretty straight forward to reason with, and the result is quite nice (: It's also a quite common method in games dev/graphic tools/etc. > I do feel like this is the same high level feature as issue https://github.com/w3c/csswg-drafts/issues/7059, just approaching it from a different direction. Yes, the result is quite similar, but different. Some libraries use that transition method, like [GSAP's scrub option](https://greensock.com/docs/v3/Plugins/ScrollTrigger), while other use lerping like [locomotive scroll's lerp](https://github.com/locomotivemtl/locomotive-scroll). -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8816#issuecomment-1679169991 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 August 2023 15:46:28 UTC