[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] A replacement or changing for setInterval?



I thought I'd bring this up here. It's been brought up in the webapps list before but it doesn't seem like there is any momentum. Given that all the major browser vendors seem to be implementing WebGL (with one notable exception) maybe we can come to a consensus here and together propose it to the webapps group.

The issue is unlike Flash, animated WebGL apps will use CPU even when not visible.

This is because window.setInterval(), the function used to enable animation, doesn't care if the webpage or the canvas element is off screen. There is no info that they are offscreen and so minimizing, putting the page on a back tab, etc will not stop the app from doing all of it's calculations and all of it's rendering. Only the final compositing step is avoided.

You can see this problem with 2D canvas animation

Click this link
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.

Or this one
http://www.ambiera.at/copperlicht/demos/demo_quakelevel_external.html

Conversely, look at this flash page.
http://www.alissadean.com/

It may not look like it's doing a lot of work but given that it is software composited there is actually a lot of CPU usage. Notice that unlike the canvas demos, when you minimize that window or put it on a back tab the CPU usage drops to zero.

It seems like we need a way to accomplish the same thing else WebGL apps may kill performance even when not visible.

A few proposals.

#1 Add a window.setIntervalWhenVisible or an option to window.setInterval that lets you specific, call only when visible.

#2 Add a element.setIntervalWhenVisible

This has the advantage over #1 which is that if the element is down the page it won't use any CPU.

#3 Change window.setInterval to have a bool (call only when visible) that defaults to TRUE.

This is the same as #1. It has the disadvantage that it will break some existing apps.

But, it has the advantage that by default your app will not use CPU offscreen unless you specifically request it.  The issue is there's a million _javascript_ programmers out there that are unlikely to discover methods #1 or #2 so if we want people to do the right thing for users it seems like breaking old behavior might be better than having people dislike WebGL apps and Canvas apps because most of them slow their machines to a crawl.

There's a couple of other proposals in the original thread
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0223.html

You could argue that this is not a WebGL issue but I think WebGL is the tech most likely to bring this issue to the forefront.