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

[whatwg] Timing API proposal for measuring intervals

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 8 Jul 2011 14:36:49 +1200
Message-ID: <CAOp6jLbcPhM+2Jcs5R=xx4eHKsJ+LojGSB_g+TTSrGWyPbkhOA@mail.gmail.com>
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.

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?

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.

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:36:49 UTC

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