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

Re: [Public WebGL] Resurrecting Update Scheduling

On Sat, Apr 17, 2010 at 5:37 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Sun, Apr 18, 2010 at 8:38 AM, Thatcher Ulrich <tu@tulrich.com> wrote:
>> Without a JS update scheduler that is vsync aware, the app won't be able
>> to update the scene in sync with the display.
> Can you explain why in more detail? I don't understand the issue. If the
> application script is updating its content at 60 FPS (where "updating the
> content" includes drawing into a WebGL buffer), and the browser composites
> the content to the screen during the vsync interval, why would it matter
> whether the script actually runs during the vsync interval?

The two issues I see:

1. the app doesn't know what delay argument to give to setInterval or
setTimeout, because it doesn't have a way to query for the vsync

2. if it does happen to know the interval (or just guesses 60Hz), even
a very accurate timer based callback will still sometimes do 0 or 2
frames in one vsync interval due to skew.

> I agree with Vlad that we need a mechanism for JS animation that gives frame
> rate control to the browser, and this mechanism should not be specific to
> WebGL or canvas. My specific proposal for such a mechanism was mentioned in
> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0226.html
> See the associated thread.

I like this proposal.  It looks like it would allow vsyncing (browser
sends beforePaint based on vsync).

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: