Bug 211624
| Summary: | requestAnimationFrame slow performance vs. setInterval / setTimeout | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Dustin Kerstein <dustin.kerstein> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Major | CC: | dustin.kerstein, Hironori.Fujii, sabouhallawa, simon.fraser, thorton, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 13 | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
Dustin Kerstein
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/63038888>
Dustin Kerstein
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
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
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