W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2012

Re: Semantics of the time argument on rAF's FrameRequestCallback

From: Nat Duca <nduca@chromium.org>
Date: Wed, 9 May 2012 10:22:53 -0700
Message-ID: <CAAMsTOv0HtUJ7GBDrdWa0FSEa_PMPnjjYrWN+fi3PoerRLNOsw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-web-perf@w3.org
In a future rev of rAF, if we ever need to provide *both* begin and
present time, as CVDisplayLink does, we're going to be in a world of
pain if we leave time undefined. The only portable way to do such a
thing would be to accept a definition of the callback that is of the

callback FrameRequestCallback = void (DOMTimeStamp
beginOrPresentWhoKnows, DOMHighResTimeStamp beginTime,
DOMHighResTimeStamp presentTime);

Maybe that's okay?

As a matter of education, what do other browsers provide for "time"?
Safari gives present time
All other webkit ports give begin time
What about FF/IE/Opera?

- N

On Wed, May 9, 2012 at 10:07 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/9/12 12:58 PM, Nat Duca wrote:
>> Hi folks -
>> The current rAF spec defines FrameRequestCallback in the following way:
>>    callback FrameRequestCallback = void (DOMTimeStamp time);
>> However, we don't define the semantic meaning of the time argument.
> See section 5 step 1:
>  1. Let t be the result of getting the next sample time of the
>     top-level browsing context.
>    Editorial note
>    ISSUE-2 Getting the next sample time is currently undefined.
>    This time should be the same as the time that contemporaneous
>    native animations have been sampled at.
> Note that the above definition, if adopted, would allow either of your two
> options to be conformant; the key is that it match all other animations so
> that the timeline is consistent.
> -Boris
Received on Wednesday, 9 May 2012 17:23:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:32 UTC