[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.
On Fri, Apr 16, 2010 at 7:17 PM, Vladimir Vukicevic
> (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" <firstname.lastname@example.org> wrote:
> On Apr 14, 2010, at 10:48 PM, Gregg Tavares wrote:
> On Thu, Apr 15, 2010 at 2:16 AM, Chris Marrin <email@example.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
>> 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.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: