W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2012

Re: [HighResolutionTime] comments on performance.now

From: Simon Pieters <simonp@opera.com>
Date: Wed, 21 Mar 2012 15:13:33 +0100
To: "public-web-perf@w3.org" <public-web-perf@w3.org>, "Jatinder Mann" <jmann@microsoft.com>
Message-ID: <op.wbixsvbsidj3kv@simons-macbook-pro.local>
On Tue, 20 Mar 2012 23:21:47 +0100, Jatinder Mann <jmann@microsoft.com>  

>> I think it's ridiculous to have a spec that defines a single method. It  
>> would make sense to fold this into the spec that defines the Performance
>> interface:   
>> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
> The High Resolution Time spec defines the DOMHighResTimeStamp type and  
> performance.now() method. As other specifications may be interested in  
> using a DOMHighResTimeStamp type (e.g., requestAnimationFrame) but not  
> interested in Navigation Timing, having a separate spec makes sense. In  
> addition, not only is Navigation Timing in CR (waiting to go to PR), it  
> doesn't even use high resolution time.
> We have already defined extensions to the Performance interface in many  
> specifications.


>> The spec says that the timer is accurate to at least a tenth of a  
>> millisecond, there's hardware
>> that doesn't support that accuracy. It should say to be as accurate as  
>> possible, but is not required
>> to be more accurate than a tenth of a millisecond.
> If High Resolution Time doesn't require at least a tenth of a  
> millisecond, it won't be providing any higher resolution than  
> Date.now(), one of the goals of this feature.


> I believe all latest Windows (since '95 I believe), iOS, and Android  
> hardware support sub-millisecond resolution clocks; what hardware were  
> you thinking of?

This might not be a problem in the majority of cases, but I've been told  
that at least a few years ago some cases was no better than 10ms  
resolution (maybe it wasn't a hardware limitation but a limitation  
somewhere else). This is apparently mostly changed today, but I still  
think the spec shouldn't say to do something impossible when facing  
underlying limitations. (For instance, timer resolution might be reduced  
intentionally to not drain the battery.)

> If we think there is enough new hardware that won't be able to support  
> sub-millisecond resolution, I am fine changing the MUST clause to a  
> SHOULD clause.

The spec doesn't have this as a MUST clause currently.

>> The spec should call out whether the clock should be ticking while the  
>> document is not "fully active" (as defined in HTML).
> To be clear, you are bringing this up because you want to know if  
> performance.now() includes the "time of suspension" when a page is in  
> the session history?


> I don't understand why we wouldn't want to include the time of  
> suspension - performance.now() defines the current time since the start  
> of navigation. Let me know if I misunderstood your intention here.

Right, I'd just like it to be called out explicitly.

> Thanks,
> Jatinder

Simon Pieters
Opera Software
Received on Wednesday, 21 March 2012 14:14:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:11 UTC