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

Re: Specifying window.performance.now()

From: Jan Linnebank <jan@linnebank.nl>
Date: Wed, 29 Feb 2012 12:25:23 +0100
Message-ID: <4F4E0B23.6030104@linnebank.nl>
To: public-web-perf@w3.org
A note from me as an outsider (with interest):
I think sub-millisecond resolution for FPS detection would be nice, but 
for this goal is strictly not necessary. If the end-programmer samples 
the time-period of multiple frames, the average can still have enough 
precision. (E.g. Sample 10 frames and you have an average which is 
accurate to 0.1 ms.)



On 29-2-2012 11:39, Sigbjørn Vik wrote:
> On Tue, 28 Feb 2012 20:47:00 +0100, Jatinder Mann 
> <jmann@microsoft.com> wrote:
>> I have uploaded a draft of the High Resolution Time spec here: 
>> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html. 
>> Please review the spec and provide feedback.
> "Without sub-millisecond resolution, a developer can only determine if 
> an animation is drawing at 58.8 FPS or 62.5 FPS."
> A technically correct way of saying this would be e.g. "a developer 
> can only determine such a framerate to within 3.5 FPS". Technically, 
> with a reading of 17, the FPS is determined to be in the range 57-61.
> "the number of milliseconds from the start of the navigation of the 
> root document"
> Is the "start of the navigation" well enough defined? Should we link 
> it to one of the other performance specs to tie it down absolutely?
> This also allows a cross-origin iframe to tell how long the parent has 
> been alive, which I believe is not possible now. This is a slight 
> privacy leak, which can easily be avoided. For instance remove "root" 
> from the statement, or change it to "the topmost same-origin 
> document", with a suitable definition of same-origin. I believe the 
> second is better, it is useful for same-origin documents to have the 
> same timestamps. For cross-origin documents this should normally not 
> be required. This should also be recorded in the privacy section.
Received on Wednesday, 29 February 2012 11:25:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:32 UTC