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

Re: [Public WebGL] Resurrecting Update Scheduling

On Thu, Apr 15, 2010 at 9:07 AM, Chris Marrin <cmarrin@apple.com> wrote:

On Apr 14, 2010, at 10:48 PM, Gregg Tavares wrote:

On Thu, Apr 15, 2010 at 2:16 AM, Chris Marrin <cmarrin@apple.com> wrote:
I've been thinking about WebGL on embedded processors lately. These devices have a couple of constraints that make me want to revive my 'setRenderFunction' proposal from a while back.

The problem is that (at least some of) these devices have constraints on how the rendering engine works that makes them stall more often than desktop OpenGL implementations. For a platform that refreshes at 60Hz, setting a 100Hz timer (which is common in the demos I've seen) means you can stall a lot. That's especially painful for an embedded processor which needs to waste as little time as possible.

Setting a fast timer has other issues for embedded processors. It makes it impossible for the system to throttle back the framerate to conserve battery power or to stop rendering entirely when you switch away from the browser window.

A while back I proposed a update scheduler for WebGL. I think it's especially important for embedded browsers. The issue was actually raised by Gregg who was concerned about useless spinning when the browser is not visible. An update scheduler would solve that problem. I've also included a suggestion from Cedric about being able to know whether or not the context is visible. Here is a revised version of that scheduler proposal:

       context.setUpdateFunction(updateFunction, targetFramerate);

Suggestion: What about

canvas.setUpdateFunction(updateFunction, targetFramerate);

This has been brought up before but this issue is not unique to WebGL.  Apps using the 2d context as well as apps that use just plain HTML both have this issue as well. The example I posted before to show the issue is real was a 2d canvas example and this one is pure HTML.


They are moving stuff around just by repositioning floating DIVs and it has the same problem, it hogs the CPU even when not visible.

This is the WebGL group, not the HTML5 group but it still seems like an opportunity to try to solve this more generally.

So then maybe we could treat this like we do Typed Arrays? We could make a RenderUpdate object which has the API above. That keeps it separate from WebGL, but can still be used by it.

On a somewhat related note, I wonder what the CSS animation spec says about that.  Is there any way to pause them while a tab isn't visible?  Chris?