Re: [css3-transitions] Frame Rate

On 9/29/12 3:21 PM, Rik Cabanier wrote:
>     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.
>
> Cool!
> What happens if a callback (or series of them) takes longer than 1/60 of
> a second?

Then at the moment the next one get scheduled as soon as possible after 
the previous one completes.

Though there are some who argue what it should be scheduled for 1/30 of 
a second after the previous callback start, if the callback is not 
fitting in 1/60 second.

>     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.
>
> Code will be skipped by the browser. I as a developer have no control
> over this and would have to figure out if there are missing callbacks.

Given that the point of requestAnimationFrame is that you take the time 
passed to your callback, compute how your stuff should look at that 
time, and then make it look like that, you don't have to do any figuring 
out of anything.  Assuming you're using it as designed, and not as an 
actual frame driver for frame-based animation.

> For games and synchronized media, perfect syncing is desired

Perfect syncing between video (happening on a background thread) and 
anything dependent on JS (happening on the "main page" thread, and 
subject to the vagaries of whatever goop runs as part of the page) is 
... hard.  :(

> but as we witnessed, content that worked fine on powerful desktop might not
> perforrm as well on low powered devices.

Indeed.

-Boris

Received on Sunday, 30 September 2012 00:48:11 UTC