Re: solving the CPU usage issue for non-visible pages

FYI, the original WhatWG thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/thread.html#23625
On Mon, Oct 19, 2009 at 1:51 PM, Gregg Tavares <gman@google.com> wrote:

> 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
>
>
>
>