Steps to reproduce
- Get a display capable of something other than 60Hz
(e.g. 75Hz, 85Hz, 100Hz, 120Hz, 144Hz, GSYNC, FreeSync, several models of DLP projector, Oculus/HTC Vive virtual reality goggles (90Hz), or other display).
- Open http://www.testufo.com or http://www.testufo.com/photo
- Observe EDGE is very stuttery and jumpy, while FireFox, Chrome, Opera, Safari, are all perfectly smooth at the same refresh rate.
- EDGE is hard-coded to 60Hz, in violation of W3C Animation Timing spec (end of section 5) … https://www.w3.org/TR/animation-timing/
IE10/IE11 sychronizes smoothly at more refresh rates.
For more info, see http://www.testufo.com/browser.html
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Rico M.”
Changed Assigned To from “Rico M.” to “Josh P.”
Changed Status to “Confirmed”
Changed Assigned To from “Josh P.” to “Todd R.”
Any news? I have a 144Hz monitor and this problem is the only thing that prevents me from using Edge.
Update – Edge has somewhat synchronized to IE11 but still artificially implements a 105 frames-per-second cap, preventing EDGE from running at 120fps or 144fps on 144Hz monitors.
Recently, both FireFox and Chrome successfully worked at 480fps @ 480Hz on an experimental 480 Hz monitor test (google “480Hz monitor test”) – running TestUFO without frame skipping.
Also, W3C HTML 5.2 recommendations now discourages an arbitrary frame rate cap when there are no performance or power-saver constraints (e.g. AC powered desktop computer):
W3C HTML 5.2, Section 188.8.131.52, Animation Frames, Processing Model
There are many factors that affect the ideal update frequency for the top-level browsing context including performance, power, background operation, quality of user experience, refresh rate of display(s), etc. When in foreground and not constrained by resources (i.e. performance, battery versus mains power, other resource limits), the user agent normally prioritizes for maximum quality of user experience for that set of Documents by matching update frequency and animation frame callback rate to the current refresh rate of the current display (usually 60Hz, but refresh rate may be higher or lower). When accommodating constraints on resources, the update frequency might automatically run at a lower rate. Also, if a top-level browsing context is in the background, the user agent might decide to drop that page to a much slower 4Hz, or even less.
Another example of why a browser might skip updating the rendering is to ensure certain tasks are executed immediately after each other, with only microtask checkpoints interleaved (and without, e.g., animation frame callbacks interleaved). For example, a user agent might wish to coalesce callbacks together, with no intermediate rendering updates. However, when are no constraints on resources, there MUST NOT be an arbitrary permanent user agent limit on the update rate and animation frame callback rate (i.e., high refresh rate displays and/or low latency applications).