Is requestAnimationFrame called at the right point? #2569
Comments
|
This seems vaguely related to the discussion in #512 (which got off topic pretty quickly) |
|
It seems like both Edge & Safari treat Replies to https://twitter.com/jaffathecake/status/912601447442927617 suggest developers are very confused about this. Feels like we should do something to make this kind of scheduling more explicit, but I'm not sure how, yet. |
|
If the use cases of
…then the spec makes the most sense, and Safari and Edge are needlessly delaying the callbacks. I guess I'll file bugs with them and see if they disagree. |
|
Is this covered by any existing WPT cases? |
|
This takes me back to thinking we need something like |
|
@wanderview I can't find one at a glance |
Or maybe, |
|
@smaug---- also occasionally asks for an "after animation frame callback". @rocallahan and @heycam might recall some of the original motivation for the timing used by the specification. |
|
@wanderview that works, although it might encourage GC? I think that's why raf uses a callback rather than a promise. |
|
|
|
The current spec and Firefox/Chrome behavior let you use |
|
I'm pretty sure that was the original motivation, though I can't be sure. |
|
I filed https://bugs.webkit.org/show_bug.cgi?id=177484 for Safari, and https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15469349/ for Edge. |
|
Yeah, the current behavior feels reasonable. I'm very surprised people think that is confusing. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28644 is separate thing. Quite often one wants to do something right after rendering. Something which isn't possibly about rendering but something else. |
|
I think WebKit's behavior falls out of our "it's like a timer" thinking. In fact, we fall back to a timer in the implementation in some cases. I agree that the Safari behavior seems wrong in the case where you really want to have changes show up before the up-coming paint. |
|
|
|
I believe WebKit is switching to match other browsers here. |
|
This issue still persists on Safari. |
Please clarify, with Safari version, more details and a testcase filed at bugs.webkit.org |
|
Safari Version 14.0.3 (16610.4.3.1.7) https://safari-raf-bug.glitch.me/ Chrome: left to right |
|
Thanks for the testcase; I filed https://bugs.webkit.org/show_bug.cgi?id=225871. It's not clear to me that this is about rAF timing; it may be a style resolve or animation bug. |
|
@smfr I wondered if this was related to "click" timing. It isn't, but I noticed another bug at the same time https://bugs.webkit.org/show_bug.cgi?id=225866 |
|
Mac OS Big Sur 11.4 |
|
Hi there, I made a test but I can't explain it.
Right to left on both chrome and safari. document.querySelector('button').addEventListener('click', () => {
const test = document.querySelector('.test')
test.style.transform = 'translate(400px, 0)'
requestAnimationFrame(() => {
test.style.transition = 'transform 3s linear'
test.style.transform = 'translate(200px, 0)'
})
})Left to right on both chrome and safari. document.querySelector('button').addEventListener('click', () => {
const test = document.querySelector('.test')
test.style.transform = 'translate(400px, 0)'
test.style.transition = 'transform 3s linear'
requestAnimationFrame(() => {
test.style.transform = 'translate(200px, 0)'
})
})Why does the position of |
|
Live test: https://codepen.io/smfr/pen/jOwedOW On click, the translate is set to 400px, instantaneously. On the next rAF, the 200px translate and transition make it animate from 400px to 200px. On click, the 400px translate and transition make it animate from 0 to 400px. In the rAF callback the target is now set to 200px, so the transition retargets to 200px. |
|
Goes left to right on Firefox 111.0 (64-bit), Mac 13.2.1 https://safari-raf-bug.glitch.me/. It's odd, cuz sometimes it goes right to left on first time page load then is consistently is left to right even after refreshing page/clearing cache, I can't reproduce it. |
|
Still goes left to right on Firefox 124.0 (64-bit), Mac 14.4 |
|
I tested it on Linux with Chrome 131, and the element moves from right to left, not from left to right as @jakearchibald mentioned. |
|
I've checked the demo page on Windows 11 machine, with Chrome 134, Firefox 136, Edge 134, (also on Safari on an iPhone), and the Firefox is the only one where the box goes from left to right. |
|
It's not really clear why people keep leaving comments on this closed bug with the results of a 2017 demo on their machines. But, those comments are not useful to email to the 706 watchers of this repository. So, I will lock this issue to prevent further such comments. |
I'm repurposing this slightly.
Currently the spec says that
requestAnimationFramecallbacks should come before the very next render, unlessrequestAnimationFrameis called after the browser has started processing the raf callback queue, in which case the callbacks happen before the following render.Chrome & Firefox do this, but Edge and Safari don't. They run
requestAnimationFramecallbacks before the following render.In Edge and Safari, the box will move to the left. In Chrome and Firefox (spec compliant) it'll move to the right. Demo.
Developers are pretty confused about this, with currently 60% expecting the Edge/Safari behaviour.
Should we do something about this?
Here's the original issue text:
It's currently impossible to request a callback for the next animation frame.
requestAnimationFrame(cb)will callcbbefore the next visual update in most cases, unless it's called during "run the animation frame callbacks", in which case it'll be called after the next visual update.Sometimes you want to wait until after a natural layout/render to perform particular steps, to avoid a synchronous layout.
The above guarantees
cbwill be called after a natural layout/render, but if called during "run the animation frame callbacks" you end up waiting an additional frame.Another way to solve this problem would be to provide insight into the current position within the event loop, so a user-land implementation of
requestNextAnimationFramecould avoid calling raf twice if it's already in that phase of the loop.The text was updated successfully, but these errors were encountered: