W3C home > Mailing lists > Public > www-style@w3.org > September 2012

Re: [css3-transitions] Frame Rate

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 29 Sep 2012 14:46:35 -0400
Message-ID: <5067420B.5050605@mit.edu>
To: Rik Cabanier <cabanier@gmail.com>
CC: www-style@w3.org
On 9/29/12 1:47 PM, Rik Cabanier wrote:
>     Why, exactly?  That's certainly not the case in Gecko, as long as
>     the sum of the times for those two callbacks is less than 16ms.
> ah, so gecko actually measures the time?
> I wonder how it could do that though since it can't predict how long a
> callback is going to take.

I'm not sure I follow.  What Gecko does is that it has a single 
heartbeat timer per tab that requestAnimationFrame runs from.  When the 
timer fires, any animation callback requests for that tab are run.  No 
prediction of any sort involved.

> I was told that webkit does a render pass after every event to keep the
> page responsive.

Could be, but nothing in the spec requires any sort of behavior like that,

>     I'm not sure I follow your distinction between "the movie" and "the
>     callback" here.  Can you please explain?
> Render passes are being skipped but not actionscript code.

So the point of requestAnimationFrame is that you _can_ skip code as 
needed.  If you have to run it at 30Hz instead of 60, the animation will 
move just as fast, but less smoothly.  Assuming the person doing the 
coding did it right, of course.

Note that requestAnimationFrame is meant for smooth-interpolation 
animations, not frame-based ones.  There is no good solution in the web 
platform right now for true frame-based animations.

Received on Saturday, 29 September 2012 18:47:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:21 UTC