Re: [timingobject] Timestamps and reference clocks

+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