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.
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).
I'd even be tempted to risk breaking existing applications a little bit and make the *default* behavior for HTML5 pages be that "time stops" when a page is not visible. If a programmer has a good reason to run javascript on an invisible page then they should have to pass an option to make it clear that they know what they are doing.
One challenge with this approach is that there's no good way at present to make time stop for a plugin. I suspect more generally that this approach would cause compatibility bugs.
Regards, Maciej
