- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 02 May 2011 21:29:08 -0400
- To: public-web-perf@w3.org
On 5/2/11 9:16 PM, Jatinder Mann wrote: > “When the requestAnimationFrame method is called in a tight loop, the > number of callbacks should match the refresh rate of the display. For > example, on a 60Hz display a callback should be returned every 16.7ms. > If the page is not visible, as defined by Navigator.visible attribute > being false in the Page Visibility specification, the > requestAnimationFrame method will not return a callback.“ For what it's worth, that may not match what declarative animations (e.g. SMIL) do. In particular, declarative animations make promises about events firing "eventually" with no allowances for hidden pages. What Gecko does is to throttle declarative animations and requestAnimationFrame callbacks to 1Hz in Fx4. In Fx5 we switched to an exponential backoff approach instead. I think something like that may be better than simply not calling the callbacks. In particular, it allows the animations to actually finish in the background; it's not clear to me whether just not calling the callbacks would do that. > 2.To increase adoption of the requestFrameAnimation(), it should be > syntactically similar to window.setInterval() or window.setTimeout(). > This means that in addition to taking a FrameRequestCallback, we should > also allow inline script and additional arguments. I actually disagree on this. Additional arguments add a lot of bookkeeping for a very rarely used edge case; authors who need that edge case can use a closure explicitly. Also, note that allowing pass-through arguments here would preclude later adding an optional element argument unless we bake that optional element argument into the very first spec version. Similarly, I don't think we should allow string arguments: they're a security antipattern and we shouldn't add more such. -Boris
Received on Tuesday, 3 May 2011 01:29:38 UTC