[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 <email@example.com> wrote:
> On Sun, Apr 18, 2010 at 8:38 AM, Thatcher Ulrich <firstname.lastname@example.org> 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
> 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 email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: