1427918 - Event-timestamp-high-resolution.html is almost permafail since the resolution of performance.now() was changed to 20us

Status: RESOLVED DUPLICATE of bug 1387894

(Core :: DOM: Events, enhancement, P3)

Description

[(Out Sep 17-23) Ryan VanderMeulen]

In bug 1427870, we had to change the resolution of performance.now() from 5us to 20us. This is causing Event-timestamp-high-resolution.html permafails now as a result. I'm going to annotate my way to victory for the time-being since this is time-sensitive, but given that this change is being shipped across all vendors, the test will probably need some sort of longer-term fix as well.

https://treeherder.mozilla.org/logviewer.html#?job_id=153979112&repo=mozilla-release

Comment 1

[(Out Sep 17-23) Ryan VanderMeulen]

Not that this test was very reliable to begin with. See bug 1387894.

Comment 2

[(Out Sep 17-23) Ryan VanderMeulen]

I pushed the annotation update to m-c and will soon do the same for Beta & Release:
https://hg.mozilla.org/mozilla-central/rev/25d2937fa7dd7f7a697c4ba053959f4cf4416af6

However, I fully expect to also file a new intermittent-failure bug for unexpected passes since this isn't 100% permafailing. But I think it'll still be more manageable than the current failures.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/7d81f423c7ff
Disable Event-timestamp-high-resolution.html for frequent failures. r+a=bustage

Comment 4

[(Out Sep 17-23) Ryan VanderMeulen]

The change in comment 2 didn't work because wpt treats global annotations as separate from subtest annotations :(. Since the failures happen unpredictably in various subtests, I don't see any other option besides disabling the test on opt builds for now, which is what the commit in comment 3 does.

Comment 5

[(Out Sep 17-23) Ryan VanderMeulen]

Disabled on Beta & Release:
https://hg.mozilla.org/releases/mozilla-beta/rev/e9d14df9e8a06acb176ff9f502da8866f479cc90
https://hg.mozilla.org/releases/mozilla-release/rev/4d3497f26bc179ce5632719a808e32335e8cec4d

Comment 6

[Andrew Overholt [:overholt]]

baku, can you take a look here? Maybe Andreas can help you.

bkelly brought up the good question of whether or not we should raise a spec issue about changing the resolution to be 20 μs.

Comment 7

[Tom Ritter [:tjr]]

(In reply to Andrew Overholt [:overholt] from comment #6)
> bkelly brought up the good question of whether or not we should raise a spec
> issue about changing the resolution to be 20 μs.

20ms is a stopgap. I think any spec changes would be considerably more expansive of that, and would aim to frustrate or prevent high resolution timers from being constructed from any browser feature.

*Alternately* we could consider the notion that providing high resolution timing information (either in javascript or to user-mode code via rtdsc) is a perfectly acceptable thing to do. It sounds quite reasonable right? The implication of such a declaration is that *any* software or hardware mechanism that allows privilege boundary bypasses is a bug, from microcode in SPECTRE to non-constant time animation rendering to non-cache neutral crypto algorithms to...

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

FYI, Spectre and Meltdown should be discussed tomorrow during webperf wg conf call
 https://lists.w3.org/Archives/Public/public-web-perf/2018Jan/0001.html

Comment 9

[mark]

I am an Invited Expert in W3C Web Platform Working Group with one commit;

I have read with dismay that precision is going to reduced even further to 2 milliseconds:

Even at sub-refresh-cycles, animations should still use sub-millisecond accuracy to prevent jank, when calculating time-based animations (e.g. calculating object positions based on time) -- that's what 3D graphics often do compensating for fluctuating frame rates, they calculate object world positions based on gametime.   

That means 1000 inch per second moving balls (60mph) can be wrongly mispositioned by 2 inches if the gametime is off by 2 millisecond.  That can mean goal/nogoal.  Fastballs, baseballs, hockey pucks can go much faster than this.  Low-precision gametimes will RUIN HTML5 game programming, full stop.

Gametimes need sub-millisecond accuracy, especially full-screen WebGL games, because they calculate real-world 3D object positions based on gametime.  That way everything looks correct regardless of framerate, because 3D object positions are calculated based on gametime.  Wrong gametime means everything janks like crazy in full screen WebGL games.

Again, this is for 60 Hz.  Things even janks crazily with 5ms and 8ms gametime errors on a 60Hz display.  You're in the driver's seat of a 300mph car, in a racing game -- a 2ms gametime error becomes large even on a 60 Hz display.   Jank/jerkiness/stutter can get huge even at sub-refresh-cycle levels even on a 60 Hz display, even with sub-refresh-cycle errors.

Also, incidentially, there are advantages to frame rates above refresh rates in reducing latency: https://www.blurbusters.com/faq/benefits-of-frame-rate-above-refresh-rate/

My prediction is you will get a tsunami wave of huge complaints from game designers suddenly hit by major precision reductions in ability to calculate gameworld positions.  

WebVR also becomes useless too, as it's fully dependant on this premise.

The website www.testufo.com heavily relies on timer precision for scientific motion tests.  If timer precision is reduced to FireFox levels, it becomes difficult to detect dropped frames for invalidating display motion tests.

Many scientific tests such as www.testufo.com/ghosting and www.testufo.com/frameskipping (display overclocking) is heavily dependant on perfect frame rate synchronization, and the site is able to detect whenever Chrome misses a frame.   Peer reviewed papers have already been written based on this (including www.blurbusters.com/motion-tests/pursuit-camera-paper ...) thanks to browser's ability to achieve perfect refresh rate synchronization

In Direct3D/OpenGL video games, especially on a variable refresh rate display (or VSYNC OFF), I can see microstutters caused by 1ms frame pacing errors.   A 1ms error in gametime creates a 1/1000th screen width microstutter (2 pixel stutter on a 1920x1080 display).   Stutterwidth at 4K and up becomes even more visible with gametime errors.  Also, since WebGL is capable of running in full screen mode.   Ruined precision clocks (e.g. FireFox 60's use of 2ms precision) is extremely bad for WebGL video games as a result.

Out of sheer mother of necessity, some game developers will do this:
Useragents (at HTML5 game sites) will likely detect reduced precision and automatically prompt users to modify their configuration/preferences (which is permanent for all sites), reducing security further.  This is a less preferable outcome.

Recommended browser vendor fix: Permissions-based API during duration of security study.

"In an absolute emergency: Personally if there's a duress to reduce timer precision, then a temporary permissions API (cameras and fullscreen have more security/privacy fears) to prompt the user for permission to stay at 5us precision.  At least during the duration of security studying, until being reverted to maximized precision."

Comment 10

[Andreas Farre [:farre]]

Is this issue relevant any longer since we're doing Fission?

Comment 11

[Tom Ritter [:tjr]]

Fixing Bug 1387894 should resolve it.