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

Re: [Public WebGL] Resurrecting Update Scheduling



I'd like to see some clean way to accomplish vsync-locked rendering.
Of course that won't always be possible depending on the platform and
how much per-frame processing the app needs to do, but when it is
possible, it's a noticeable jump in quality.

In the Google Earth API we accomplish this by providing a "frameend"
event to the page.  An app can do its per-frame processing in response
to that event, and the results are naturally sync'ed.  If everything
is fast enough, the app runs at the native display refresh rate.  It's
a "best effort" kind of thing -- it doesn't guarantee any particular
frame rate and so it doesn't relieve the app author from the
responsibility of frame-rate scaling.  But it's dead simple so app
authors can get ideal behavior without any special effort.

-T

On Fri, Apr 16, 2010 at 7:17 PM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
>
> (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);
>>        context.scheduleUpdate();
>>        context.isContextVisible();
>
> Suggestion: What about
>
> canvas.setUpdateFunction(updateFunction, targetFramerate);
> canvas.scheduleUpdate();
> canvas.isVisible();
>
> 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.
>
> http://www.effectgames.com/effect/games/crystalgalaxy/
>
> 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.
>
>

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