W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] Timing API proposal for measuring intervals

From: James Robinson <jamesr@google.com>
Date: Thu, 7 Jul 2011 19:54:11 -0700
Message-ID: <CAD73mdLvJWVnNOYdCJn10ptMPfU=1TvNhEWoo3qKTaHAhNwj8g@mail.gmail.com>
On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> I like it so far, module bikeshedding. (I might call it
> window.currentTime.)
>
> One question is whether you allow the value to change while a script runs.
> When using the value to schedule animations, it would be helpful for the
> value to only change between stable states.
>

True.  It's also useful to be able to query the "now" time multiple times
from script when trying to time some action.   I think that animation APIs
(or anything else providing a timestamp) should provide a fixed value but
this attribute should always be up to date.  That said, maybe it should be a
function rather than an attribute to make that point clearer.


> If you refer to this value during requestAnimationFrame, does it give you
> the current time, or the predicted time at which the frame will render?
>

I think we'll want to use the same mechanism for requestAnimationFrame, but
I'm not yet sure whether we want to provide the current time, predicted
frame time, or both. (CVDisplayLink provides both, for example
http://developer.apple.com/library/mac/#qa/qa1385/_index.html).   There's a
thread on this topic on public-web-perf currently, I think we can hash out
the details there.


> Using this value as a clock for media synchronization sounds appealing but
> is complicated by audio clock drift. When you play N seconds of audio, it
> might take slightly more or less time to actually play, so it's hard to keep
> media times perfectly in sync with another timing source. Just something to
> keep in mind.
>

True.  On OS X, however, the CoreVideo and CoreAudio APIs are specified to
use a unified time base (see
http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html)
so if we do end up with APIs saying "play this sound at time X", like Chris
Roger's proposed Web Audio API provides, it'll be really handy if we have a
unified timescale for everyone to refer to.

- James


> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
> in us. If we confess our sins, he is faithful and just and will forgive us
> our sins and purify us from all unrighteousness. If we claim we have not
> sinned, we make him out to be a liar and his word is not in us." [1 John
> 1:8-10]
>
Received on Thursday, 7 July 2011 19:54:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:34 UTC