NEW 211624
requestAnimationFrame slow performance vs. setInterval / setTimeout
https://bugs.webkit.org/show_bug.cgi?id=211624
Summary requestAnimationFrame slow performance vs. setInterval / setTimeout
Dustin Kerstein
Reported 2020-05-08 08:02:49 PDT
I'm sure this can be replicated in other ways but here is an example using Three.js and video seeking using a file with 100% I-Frames - https://jsfiddle.net/wxe5pk8c - You can switch between requestAnimationFrame, Three.js's setAnimationLoop (which uses rAF internally), and setInterval by setting animationStrategy to 1,2,3, respectively. *Note* that as this JSFiddle uses iFrames, you'll need to click into the result iFrame to get Safari to avoid using its low power mode (meant for ads) which limits rendering to 30fps. Below are average framerates from various devices I have tested: 1st Gen iPad Pro requestAnimationFrame: 55fps setAnimationLoop: 55fps setInterval: 60fps 2011 Macbook Pro requestAnimationFrame: 3fps setAnimationLoop: 3fps setInterval: 60fps 2019 Macbook Pro requestAnimationFrame: 60fps setAnimationLoop: 60fps setInterval: 60fps Also, note that this JSFiddle example is susceptible to this issue - https://bugs.webkit.org/show_bug.cgi?id=211295 but I believe it should still be a valid test for comparison between requestAnimationFrame and setInterval / setTimeout performance testing.
Attachments
Radar WebKit Bug Importer
Comment 1 2020-05-08 15:32:01 PDT
Dustin Kerstein
Comment 2 2020-05-09 09:01:04 PDT
Quick update - This can be replicated on many of the Three.js examples (not just the somewhat esoteric video seeking example above). Try https://threejs.org/examples/#webgl_interactive_cubes_gpu and switch from requestAnimationFrame to setInterval - I see around a 10-15fps difference on both my iPad Pro and older Macbook Pro.
Dustin Kerstein
Comment 3 2020-05-11 05:56:40 PDT
And a potentially unrelated but interesting behavior - On the above video seeking JSFiddle, when tested on an iOS device, sometimes the textures stop updating for a small period of time (independent from rendered rAF FPS) but can somehow be *fixed* immediately by touching the screen. I doubt that's directly related to the core rAF performance differences with setInterval, but I figured I'd mention it in case it helps diagnose things.
Dustin Kerstein
Comment 4 2020-05-11 15:30:53 PDT
Regarding the issue noted in my most recent comment, I opened a new issue specifically about video-based textures not updating - https://bugs.webkit.org/show_bug.cgi?id=211750
Note You need to log in before you can comment on or make changes to this bug.