On Wed, Oct 21, 2009 at 3:41 PM, Maciej Stachowiak <m...@apple.com> wrote:

> On Oct 20, 2009, at 7:13 PM, Ennals, Robert wrote:
> One thing I like about the "requestAnimationFrame" approach is that it
> makes it easy to do the right thing. If the simplest approach burns CPU
> cycles, and programmers have to think a bit harder to avoid doing this, then
> I suspect the likely outcome would be that many programmers will take the
> shortest path, and not check whether their page is visible.
> It's nice if you are able to re-engineer your animations enough to make use
> of it. The other approaches discussed seem easier to bolt on to existing
> code.

I'd hoped it would be easy to retrofit. Given

var timer = setInterval(doStuff, /*some inappropriately chosen frame

you can just change it to

var cancelled = false;
  function() { doStuff(); if (!cancelled) window.requestAnimationFrame(); },
cancelled = true;

Note: if you really want to optimize CPU use, then the best thing IMO is to
> use CSS Transitions or CSS Animations, that way the browser is fully in
> control of the frame rate and in many cases can do most of the work on the
> GPU, with no need to execute any script as the animation goes. I think this
> has the potential to be more CPU-friendly than the requestAnimationFrame
> approach, though obviously it's not applicable in some cases (e.g. canvas
> drawing).

That is absolutely true, but there will always be lots of situations where
declarative animation is insufficiently flexible --- games, physics
simulations, etc. And of course the ease of retrofitting existing
script-based animations is an issue.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah

Reply via email to