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

-Ken

On Sat, Apr 17, 2010 at 10:38 AM, Thatcher Ulrich <tu@tulrich.com> 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.
>
> -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:
>
>

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