I posted something about this in the whatwg list and was told to bring it here.
Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. To see an example run this sample in any browser http://mrdoob.com/projects/chromeexperiments/depth_of_field/ Minimize the window or switch to another tab and notice that it's still taking up a bunch of CPU time. Conversely, look at this flash page. http://www.alissadean.com/ While it might look simple there is actually a lot of CPU based pixel work required to composite the buttons with alpha over the scrolling clouds with alpha over the background. Minimize that window or switch to another tab and unlike HTML5 + JavaScript, flash has no problem knowning that it no longer needs to render. There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. It seems like this will be come an issue as more and more HMTL5 pages start using canvas to do stuff they would have been doing in flash like ads or games. Without a solution those ads and games will continue to eat CPU even when not visible which will make the user experience very poor. There may be other solutions. The advantage to this solution is it requires almost no changes to logic of current animating applications. Some have suggested the UA can solve this but I don't see how a UA can know when JavaScript should and should not run. For example chat and mail applications run using setInterval even when not visible so just stopping non-visible pages from running at all is not an option. Another suggested solution is for pages to default to only be processed when visible and requiring the page to somehow notify the UA it needs processing even when not-visible. This could break some existing apps but they would likely be updated immediately. This solution might lessen the probability of resource hogging pages in the future as HTML5+JavaScript+canvas ads, games and other apps become more common since the default would be for them not to hog the CPU when not visible. -gregg
