- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Aug 2015 10:31:30 +0000
- To: public-webtiming@w3.org
+1 for being completely right and covering my back. my bad - please ignore paragraph about removing .now() function of timing provider. I thought for a moment that the now() function was equal to performance.now() - which it isn't looking a bit into the details of the spec - I would like to suggest an alternative approach from what is currently described here's my thinking: to process a query on the timing object we essentially need two timestamps - ts_now - ts_init - from initial vector as we are going to subtract them it does not really matter what clock these values are sampled from (as long as it is the same clock). however - the query method will return ts_now to the application - so this should be a value sampled from performance.now(). It follows that what we need from the timing provider is a fresh evaluation of ts_init - translated onto to timeline of HR-time/performance.now(). Therefore - the query method of the timing object will use vector.position, vector.velocity and vector.acceleration from the timing provider initial vector vector.timestamp should not be used (should not even be exposed to the timing object) instead the timing provider provides a method .timestamp() that should be used instead in order to fetch the t_init. .timestamp() then represents the current estimate for t_init (when the initial vector was defined) - translated onto the timeline of performance.now() - (this is typically a negative number) - but it should be quite stable - change only a few milliseconds back and forth (during periods short enough for clock drift to be negligible). Furthermore, I also suggest that all timestamps used throughout timing provider and timing object are given in milliseconds - not seconds. -- GitHub Notif of comment by ingararntzen See https://github.com/webtiming/timingobject/issues/16#issuecomment-134139529
Received on Monday, 24 August 2015 10:31:31 UTC