-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Elaborate on "deprecating" requestAnimationFrame() #85
Comments
First, I think it's important to consider that we're not suggesting the deprecation of This proposal is about controlling the frame rate of animations. While A frame rate makes sense for something that is, by nature, progressing, whereas Separately to this explainer, we're advocating the support for custom effects to offer support for callback-based animations, which would tie in nicely with this proposal since this would allow authors to write such animations while specifying a frame rate. |
All true (though I don't personally equate deprecating with removal), but assuming custom effects come to pass, what use cases would remain for |
I'm not sure I can fully answer this question, because I certainly don't know of all the uses for The naming of that function is really unfortunate :) |
Right, so the idea is that you'd continue to use |
Related: #89 -- This applies to both requestAnimationFrame() as well as Web Animations API. Permission Prompt API for power-hungry animations including TestUFO |
We did more work on trying to port TestUFO to Web Animation API, and we've hit a blocker. While TestUFO is also used as a "120Hz advertising" tool, different subpages / subtests within it are used by peer reviewed researchers, as well as many content creators (including LinucTechTips and RTINGS), and this is where we run into a science-quality blocker issue: To Replace rAF() We Need An Equally Accurate Frame Presentation Callback Event added to Web Animation APIPurpose: Measure frame presentation times accurately, and detect frame drops (e.g. missed refresh cycles, e.g. 59fps at 60Hz, or 119fps at 120Hz, etc).I have done some research why we continue to be able to port the 30+ motion tests at TestUFO.com (>2M uniq's per month in CloudFlare analytics, ~700K/mo recorded in Analytics, difference is from tracker/country blocking) away from requestAnimationFrame(), towards the new Web Animation API (still lower scientific quality for our needs, explained at #89 (comment) Over 500 content creators (with a combined subscribership/viewership of >100M) use TestUFO for testing the motion quality of displays, and TestUFO is "motion education in a single link" as well as "120Hz advertising in a single link" on top of research -- so we're trying to find ways to support 120Hz apple devices better. Web Animation API (that Apple prefers) is an adequate solution but there's one major scientific-mandatory feature missing: TestUFO is in several peer-reviewed papers (including one co-authored by NIST.gov) because I've successfully used requestAnimationFrame() as a single-framedrop detector. Via analyzing the now() timing of requestAnimationFrame callbacks, I can detect single missed refresh cycles (tiny microstutters, sometimes only visible to a camera). I know when I'm only running 59fps at 60Hz, or 239fps at 240Hz, and can instantly invalidate a scientific test on time. To replace requestAnimationFrame() I need a modification to the Web Animation API to add a callback purely for framedrop analysis purpose. I also will settle for a callback upon missed frames (at a speed of within 1/Hz, so I can render a color-coded error message as quickly as possible at the bottom of TestUFO, to help all researchers and content creators accept/invalidate photographic tests of TestUFO animations). More info why I need a frame presentation time callback:
Also relevant (for those wondering why TestUFO has been accepted by high-Hz gaming display testers as being superior to other motion tests): Apple wants to advertise 120Hz more and I want to help Apple sell 120Hz displays -- so working in finding ways to help me gain access to newer web standards (& framerate=Hz animations in browsers). So it's in Apple's economic interests to find ways to improve Web Animation API to be a superior replacement to requestAnimationFrame() in all the necessary checkboxes for TestUFO needs.... no? |
Also: Another reason is we automatically use multiple divisors of Hz for many educational tests. So on a 165 Hz monitor, some animations will play at exactly half 165Hz (87.5fps) or exactly third of 165 Hz (55fps), to compare against full frame rate, e.g. https://www.testufo.com/blackframes#count=3&bonusufo=1&equalizer=1&background=000000&multistrobe=1&pps=960 Remember, TestUFO has over 30 tests (selectable at upper right corner) with millions of customizable parameters for each (totalled). So to cherrypick one example (more education-related rather than researcher-related): Web Animation API has no easy method to port this specific test -- www.testufo.com/blackframes (or a fancy configured version like testufo.com/blackframes#count=3&bonusufo=1&equalizer=1&background=000000&multistrobe=1&pps=960 -- every combination is fully bookmarkable and shareable, which is a neat feature of TestUFO for education's sake) -- and accurate framedrop-free detection, since the BFI animation erratically flickers if there's even just 1 framedrop, so some motion algorithms need perfect framerate=Hz to be properly educational. By utilizing my framedrop detector I use for requestAnimationFrame() I can tell whether the frame rate deviates from perfect framerate=Hz, I can instantly tell the user to close apps/tabs until the animation runs again at full frame rate -- try it and try forcing stutters. You will see the bottom message change into orange or red, telling users. Also, we have held off the mobile-compatible version of TestUFO because of Apple's lack of ability to provide an acceptable route for TestUFO. The lack of a frame-presented callback event in Web Animation API is highly problematic for a lot of needs of TestUFO, and eventually popup messages at TestUFO will soon display a globally blacklisted-warning for all Safari browsers (never shows a green "READY"), once 120Hz Apple devices are more popular than 60Hz Apple devices (in the next 5 years or so). We urgently need to fix the Web Animation API limitation of a lack of a reliable at-least-millisecond-accurate frame-presentation callback event (microsecond like Chrome is preferred, but we will settle for millisecond accuracy). Of some of the 30 TestUFO tests, has some interesting requirements (for science, for research, etc):
Since TestUFO educates people on display motion physics (including VRR simulation, stutter simulation, software-simulation of a CRT tube, etc), requires perfect single-frame control and self-monitoring. Auto-self-animating APIs (e.g. CSS animations) are unsuitable for more than half of the selectable TestUFO tests because of their scientific/education opaqueness. If Web Animation API adds a frame callback, we are able to do the rest. Because of the above, it is still not yet possible to deprecate requestAnimationFrame() for our needs.Minor revision to Web Animations API is needed; what would be the best Apple-sanctioned channel to submit the necessary changes to Web Animations API in order to be able to deprecate requestAnimationFrame()? (120fps 120Hz Apple device support + realtime on-the-fly per-frame timestamp callbacks for use for framedrop detection algorithms) |
I'd love to understand better as to why extensions to
requestAnimationFrame()
are not the way forward.Re: https://github.com/WebKit/explainers/tree/main/animation-frame-rate.
The text was updated successfully, but these errors were encountered: