This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28644 - Add an optional parameter to requestAnimationFrame to indicate when the callback should be called
Summary: Add an optional parameter to requestAnimationFrame to indicate when the callb...
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-15 14:02 UTC by Olli Pettay
Modified: 2019-03-29 19:13 UTC (History)
6 users (show)

See Also:

Attachments

Description Olli Pettay 2015-05-15 14:02:05 UTC 
I've seen rather often in various tests that one wants to actually get a callback
called right after the normal animation frame stuff, usually even async.
So something like
requestAnimationFrame(function(now) {}, { async: true }); might work pretty well.
Not sure what the /now/ passed to the callback should be in that case.
I guess it shouldn't be the /now/ defined in 
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9:run-the-animation-frame-callbacks, but the value should be updated just before calling such async callbacks.
Comment 1 Anne 2015-10-06 06:53:16 UTC 
Do you mean this would be invoked as part of a new substep 11 of the overall rendering update step? In that case { postRendering: true } might be more appropriate.

Rick, Ilya, any thoughts on this?
Comment 2 Olli Pettay 2015-10-06 16:47:33 UTC 
Either step 11 could call them
or step 9 would have a substep to take the current "late-callbacks" and queue a task to call them.
Comment 3 Ilya Grigorik 2015-10-06 16:53:59 UTC 
Isn't requestIdleCallback already filling in this gap, and in a better and more flexible way? See: https://w3c.github.io/requestidlecallback/

p.s. available in Chrome Canary and shipping in M48.
Comment 4 Olli Pettay 2015-10-06 17:16:06 UTC 
This has very little to do with requestIdleCallback.
The issue is that we currently put too much pressure to animation frame tick time, yet there are things which could run right after the tick.
Comment 5 Rick Byers 2015-10-06 17:20:45 UTC 
How does this relate to setImmediate (https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html)?

I don't fully understand the use cases here, /cc ojan@ who is probably a better blink contact.
Comment 6 Domenic Denicola 2016-01-24 05:45:21 UTC 
(In reply to Rick Byers from comment #5)
> How does this relate to setImmediate
> (https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.
> html)?

setImmediate is unaware of the animation lifecycle and just queues a task as soon as possible (but on the task queue, so it might happen after other tasks, input, even rendering if you manage to catch it on the 16 ms boundary). So, also pretty unrelated.
Comment 7 Anne 2017-07-24 13:26:54 UTC 
Olli, is this still something you want?
Comment 8 Olli Pettay 2017-07-24 15:06:49 UTC 
I'm pretty sure yes. I've seen this often at least in tests doing something like
requestAnimationFrame(function() { setTimeout(function() { /* do something*/}); })
Comment 9 Anne 2017-07-24 15:09:59 UTC 
But there's no guarantee there's no other animation frame in between in that case, right? If there's already some tasks queued, you won't run directly after the frame.
Comment 10 Olli Pettay 2017-07-24 15:18:23 UTC 
Sure. I don't have strong opinion whether it should be right after next tick, or async task after next tick.