- From: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
- Date: Fri, 12 Jun 2015 13:40:06 +0200
- To: Francois Daoust <fd@w3.org>
- Cc: public-webtiming@w3.org
- Message-ID: <CAOFBLLrbYaPtKPPBWeb2faKfkxyCoupCBZvnrCrrScqT=q2PeQ@mail.gmail.com>
Hi Francois. A monotonic clock is absolutely a reasonable requirement. In the single device setting performance.now() gives this guarantee I believe, and also protects against disturbing adjustments to the system clock. The distributed context implementations of clock sync should ideally provide this guarantee as well. This guarantee is very important in a number of systems whose correctness depend exact time ordering and such. In practice though, in the Web these are likely small effects compared to the imprecision of timeouts and media players and such, and error are either not so consequential or even hard to detect, so I'm not sure if a failure to provide this guarantee is something that anyone would really notice? Anyway, I don't see any reason why we should not mandate this in the spec. It should not be a huge cost, and a few years down the road it could even prove important. Ingar 2015-06-12 12:20 GMT+02:00 Francois Daoust <fd@w3.org>: > Hi all, > > Both Media elements and Web animations seem to rely on monotonically > increasing positions [1] [2], in other words, a clock that is always > increasing. I wonder whether we should mandate something similar in the > Timing Object specification, more precisely for the "local timestamp" > computed for the state vector. > > In the online case, the "local timestamp" is computed from the timestamp > received from the server based on an estimation of the local clock's skew > against that of the server. When that estimation changes, the conversion > can return a local timestamp that lies in the past of the last one, thus > breaking the monotonicity. > > Forcing the local timestamp to be monotonic would entail that the position > of the timing object is also monotonic in the absence of state vector > updates. > > In turn, this could perhaps help integrating the timing object with Web > Animations and Media Elements. > > Note that there are different ways to create a monotonic (I think the > Media State Vector paper references a couple) and I'm not suggesting to > mandate a particular mechanism. > > Is it needed, useful, too early to tell? I confess I do not know whether > using a monotonic clock is a must in most cases, a nice-to-have or > something that is only ever required in specific cases, so apologies if the > idea is essentially dumb... > > Francois. > > [1] http://w3c.github.io/web-animations/#global-clock > [2] > http://www.w3.org/html/wg/drafts/html/master/semantics.html#playing-the-media-resource > >
Received on Friday, 12 June 2015 11:40:34 UTC