[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Resurrecting Update Scheduling
Browsers supporting hardware compositing should automatically support
vsynced rendering. WebGL never renders directly to the screen; it
can't according to the HTML compositing model. If the browser uses a
GPU-based API to put the rendering results on the screen, and enables
vsync, then the WebGL output will be vsynced. Otherwise it's basically
impossible to get it to be.
On Sat, Apr 17, 2010 at 10:38 AM, Thatcher Ulrich <firstname.lastname@example.org> wrote:
> 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
> <email@example.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" <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:
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: