Inprecise high precision performance.now Timer
Reported by
helmut.e...@gmail.com,
Mar 17 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Steps to reproduce the problem: 1.Run the test program http://www.taccgl.org/issues/timer.html containing the following code var t,i=0,p=0,s=""; while (i<100) { t=window.performance.now(); if (p!=t) {s+="\n "+(t); i++} p=t; }; console.log(s); 2.Look at the console output in developer tools 3. What is the expected behavior? The printed timer values (in ms) should have a precision of 5us. So some of the values should not be integers or close by. In Firefox for example values roughly increase in incements of 0.005. What went wrong? Sample test output is 77.995 79 79.995 81 81.99500000000002 82.99500000000002 84 84.995 86 86.995 87.995 89.995 91.00000000000001 91.995 92.995 93.995 94.995 ... All numbers are either integers or nearby (differ at most 5us from an integer) Did this work before? N/A Chrome version: 49.0.2623.87 Channel: stable OS Version: 6.3 Flash Version: Shockwave Flash 21.0 r0 According to Issue 506723 the timer resolution should have been reduced to 5us. However, it seems that the resolution is now as bad as 1ms.
,
Apr 1 2016
On windows machines where high-resolution time is not efficient/reliable, Chrome falls back to low-resolution clock API (timeGetTime(), which is 1ms resolution). See the change description of this commit: https://chromium.googlesource.com/chromium/src/+/5990719bcd1403b5a5b45874ce808727c033e7ec In my Chrome 49.0.2623.110 m / Windows 7, console output of the test page looks like this: 2197.61 2197.6150000000002 2197.6200000000003 2197.6250000000005 2197.63 2197.635 Clamped to 5us, as expected. |
||
►
Sign in to add a comment |
||
Comment 1 by tkent@chromium.org
, Mar 23 2016