W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: requestAnimationFrame

From: Gregg Tavares (wrk) <gman@google.com>
Date: Wed, 17 Nov 2010 10:45:30 -0800
Message-ID: <AANLkTin_tUgP4PFcNrwh6fbaDrvpwRMiAyshS0YikkEV@mail.gmail.com>
To: robert@ocallahan.org
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Nov 16, 2010 at 12:28 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Nov 17, 2010 at 7:52 AM, Gregg Tavares (wrk) <gman@google.com>wrote:
>
>> So if the JS on the beforePaint takes a while to complete what happens to
>> the browser? For example if you are resizing the browser? Is the browser
>> forced not to be able to actually paint until JS returns?
>
>
> Not necessarily. In Firefox 4, yes. In Mobile Firefox, which supports
> compositing in a separate process from the content, no.
>
>
>>
>>
>>> Now, when animation is happening on a separate compositor thread that
>>> guarantee has to be relaxed a bit. But we'll still try to meet it on a
>>> best-effort basis --- i.e. "we'll run the JS animations once per composited
>>> frame, if the JS can keep up".
>>>
>>
>> So you're saying that there's no guarantee that requestAnimationFrame will
>> actually keep things in sync?
>>
>
> Right. A cast-iron guarantee that requestAnimationFrame callbacks will run
> to completion before painting is incompatible with the goal of being able to
> repaint the browser window even if scripts are running too long or
> completely hung.
>
> But we *can* guarantee that a) scripted animations stay in sync with each
> other, and b) if the HTML5 event loop is not too busy (e.g., animation
> scripts take much less time to complete than the interval between composited
> frames and the content process is otherwise idle), scripted animations will
> stay in sync with with declarative animations even if the declarative
> animations are being processed by an off-main-thread compositing framework.
> (OK, this is a bit speculative since we haven't implemented it yet, but the
> approach seems straightforward.)
>

Just blue skying here but .... It seems like if your goal is to keep
animations in sync the trigger should be an animation tick, not a repaint.
In otherwords, you want to give JS a chance to update stuff anytime a CSS
animation updates stuff. That would separate the issue from "painting". So
what about an "onAnimation" type of event?

That would separate this issue of the browser having to wait for JS during a
paint and still keep things in sync.










>
> Rob
> --
> "Now the Bereans were of more noble character than the Thessalonians, for
> they received the message with great eagerness and examined the Scriptures
> every day to see if what Paul said was true." [Acts 17:11]
>
Received on Wednesday, 17 November 2010 18:46:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT