- From: Nat Duca <nduca@chromium.org>
- Date: Wed, 9 May 2012 10:22:53 -0700
- 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 form 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