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

[Public WebGL] Resurrecting Update Scheduling

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);

The first call would be made to setup the callback function and the target framerate. Whenever you want to update a frame you would call scheduleUpdate() and the callback would be called in the near future. For things like a spinning cube you would call scheduleUpdate() in your updateFunction. To avoid rendering when the canvas is not visible, you can use isContextVisible().

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.

This system is opt-in. It doesn't prevent a WebGL app from firing timers like today. But it gives authors a tool to write CPU friendly apps, and because of (3) it can smooth out the animation in some cases as well.


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: