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

Re: [Public WebGL] A replacement or changing for setInterval?

On Feb 13, 2010, at 6:40 PM, Gregg Tavares wrote:

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

The proposals you made are not WebGL specific. But you're right that WebGL will make this issue stand out. So maybe a WebGL specific solution would be in order. We could add:

	context.setRenderFunction(renderFunction, targetFramerate);

The first call would be made to setup the callback function and the target framerate. Whenever you want to render a frame you would call scheduleRender() and the callback would be called in the near future. For things like a spinning cube you would call scheduleRender() in your renderFunction. 

This mechanism would do several things that would be hard or impossible with the existing interval timer:

1) It would fire only once regardless of the number of times scheduleRender() was called.

2) Calls would be throttled to keep framerate at or below targetFramerate.

3) Call frequency can be adjusted to keep intervals consistent. This includes both setting a shorter interval to keep up with targetFramerate and moderating the rate when rendering overhead requires a slower interval than targetFramerate.

4) Call frequency can be reduced on a browser specific basis to keep WebGL from taking up too much CPU.

5) Calls can be stopped when the page is not visible.

These rendering specific calls give us a lot of opportunity for managing WebGL rendering and I think it would be worth the extra API. 


You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: