W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 19 Oct 2009 14:04:01 -0700
Message-ID: <5dd9e5c50910191404i77cd76fcyedc0c018d842f4c4@mail.gmail.com>
To: Gregg Tavares <gman@google.com>
Cc: public-webapps@w3.org
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
>
>
>
>
Received on Monday, 19 October 2009 21:04:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT