Hacker News Reader

Comment by TheCoreh | Hacker News Reader

Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the resolution again? Can we get a Developer menu or Web Inspector option to temporarily enable the old resolution again?

View on HN

It's surprising to me that there are such various levels of coarseness each browser vendor chose:

Gecko [0]: accurate to 20us

Edge [1]: accurate to 20us, with an additional 20us of noise

Chrome [2]: accurate to 100us (thanks mkeblx for finding this)

Safari [OP]: accurate to 1000us

[0] https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

[1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...

[2] https://chromium-review.googlesource.com/c/chromium/src/+/85...

Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/85...

In the same article, they describe their intent to, yes, restore timing resolution, once alternative mitigations mature.

1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games to break :/

We are looking at ways to make it more precise but with random jitter. 1ms is a stopgap.

Can't the timing (in)accuracies be worked around by javascript? There must be countless numbers of timer-triggered events in JS, not just the high-res timers but simple second-by-second counters, frame sync events, or even external I/O. Every possible time-based event needs to be made imprecise, otherwise programmers can derive a higher precision timer from them.

e.g. if you have a tight loop that just increments a counter, couldn't you just run that for a second (interrupted by a lower frequency timer source), then find out how many counts/second the JIT can perform, presumably millions or billions. To time operation 'X', you then just perform X and run the tight loop again, and compare how many fewer tight loops you completed.

What's an example scenario where you need an ultra-high-resolution timer?

For WebGL, don't you just rely on requestAnimationFrame to call you at the right times, and draw your frame as quickly as possible? What's the benefit of being able to measure the frame time to the nearest microsecond, rather than the nearest millisecond?

Timing behavior in literally any game.

Does the timer need to be much higher resolution than the frame rate? If so, why?

Maybe you want to measure the frame rate precisely? That is certainly something you can do, but not usually something you need to do.

Reply on news.ycombinator.com