You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UPDATE: Change committed on #785. Please see #375 instead (rewritten/newer) for further standardization efforts on this.
PROBLEM
requestAnimationFrame() is not sufficiently rigidly enough defined.
The older W3C "Animation Timing" spec had a better definition (https://www.w3.org/TR/animation-timing/) Section 5 says "The expectation is that the user agent will run tasks from the animation task source at at a regular interval matching the display's refresh rate. Running tasks at a lower rate can result in animations not appearing smooth. Running tasks at a higher rate can cause extra computation to occur without a user-visible benefit."
-- However the newer W3C HTML 5.1 no longer correctly describes the desire to match requestAnimationFrame() exactly to the refresh rate.
High-refresh-rate monitors (120Hz+ monitors, often found in GSYNC / FreeSync gaming monitors)
Animations, motion tests, etc.
Virtual reality. Note that Oculus/Rift is 90Hz
EASY SOLUTIONS
Discourage hardcoding of numbers such as "60Hz" or arbitrary maximum framerates such as "105". This does a disservice to high-refresh-rate monitors and future HFR displays (including future 4K120Hz and 8K120Hz standards)
Strengthen specification to make synchronization to display refresh rate a "MUST" instead of a "RECOMMENDED"
Strengthen specification to make it return exact vsync time rather than now(). Chrome is the only one that does it correctly.
[This lineitem has been moved to VSYNC API: Support for VSYNC OFF / 120Hz+ / variable refresh displays / etc #375] Strengthen specification to reduce allowable jitter, to permit smoother animations, given the increasingly real-time nature of websites, games, VR, etc. Things should be able to be stutter/jank-free all the way to ~50%-75% CPU used up inside requestAnimationFrame()
UPDATE: Change committed on #785. Please see #375 instead (rewritten/newer) for further standardization efforts on this.
PROBLEM
The older W3C "Animation Timing" spec had a better definition (https://www.w3.org/TR/animation-timing/) Section 5 says "The expectation is that the user agent will run tasks from the animation task source at at a regular interval matching the display's refresh rate. Running tasks at a lower rate can result in animations not appearing smooth. Running tasks at a higher rate can cause extra computation to occur without a user-visible benefit."
-- However the newer W3C HTML 5.1 no longer correctly describes the desire to match requestAnimationFrame() exactly to the refresh rate.
DETAIL
http://www.testufo.com/browser.html
https://connect.microsoft.com/IE/feedback/details/794072/internet-explorer-animations-fails-on-120hz-computer-monitors-works-at-60hz-75hz-100hz?siteID=rGMTN56tf_w-1PqoBW8wrx7DKpzuXQ.Wbg
http://www.vsynctester.com/howtocomputevsync.html and at http://www.testufo.com/browser.html
http://www.vsynctester.com/firefoxisbroken.html
http://www.blurbusters.com/blur-busters-120hz-web-browser-tests/
Stutter began to occur in some browsers even at 10% CPU, while Chrome remained stutter-resistant all the way to 75% CPU used up (e.g. 12ms inside requestAnimationFrame() during a 1/60sec period). This disparity is unreasonable.
WHY IT IS IMPORTANT
EASY SOLUTIONS
COMPLIANCE TESTING WEBSITES FOR requestAnimationFrame()
SUPERSEDES (IN PART): #422, #375, #159