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

Re: [Public WebGL] Resurrecting Update Scheduling

(Catching up from emergency out of town trip, apologies!)

I like the functionality, but I really strongly feel that it shouldn't be in WebGL.  I believe roc proposed something similar to this in whatwg, since it's useful beyond WebGL -- though unlike typed arrays, it doesn't really block any WebGL functionality... the same problem exists for anyone doing animation or interactive rendering on the web in general.  I don't think WebGL should have any dependency on this, but should certainly work well with whatever the functionality is when it's available.

    - Vlad

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