234923 2022-01-06 07:31:39 -0800 REGRESSION (iOS 15 / r275792): rAF sometimes seems to lose connection to v-sync signal and runs at < 60 fps 2022-07-11 03:29:01 -0700 1 1 1 Unclassified WebKit Canvas Safari 15 iPhone / iPad iOS 15 RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=234913 https://bugs.webkit.org/show_bug.cgi?id=235114 https://bugs.webkit.org/show_bug.cgi?id=224395 InRadar P2 Major --- 1 simontaylor1 simon.fraser ap dino graouts kkinnunen mmaxfield sabouhallawa simon.fraser webkit-bug-importer oldest_to_newest 1828607 0 simontaylor1 2022-01-06 07:31:39 -0800 On some navigations the rAF loop on iOS 15.2 runs at less than the v-sync rate. The page below has a rAF callback that doesn't do anything apart from busy-loop for 8ms: https://tango-bravo.net/webkit-bug-234303/raf_busyloop.html This appears to be the behaviour, 100% reproducible from a clean start on iPhone 12 Pro and other iOS 15.2 devices (Safari killed, no tabs open, even cleared all data and rebooted first but this isn't necessary): 1) Visit this bugzilla page 2) Click the link above to the no-op demo page 3) Note rAF loop runs at 60 FPS 4) Back to this page 5) Click the link again (or another one on the same domain, eg https://tango-bravo.net/webkit-bug-234303/clear_color_cycle_busyloop.html ) 6) Note rAF now runs at <60 FPS. <60FPS persists through refresh, background / foreground app switch, history navigation. 7) Kill Safari (still with tab open) and re-open. Back to 60 FPS. It appears that the affected tab is somehow disconnected from the display v-sync signal, and instead waits ~16.6ms from the end of the previous rAF callback before triggering the following one (hence the whole loop running at <60FPS). Could it perhaps have something to do with content process isolation, when switching back to an existing content process from another domain? (I don't even know if WebKit does that but know it's a thing in Chrome) Copying/pasting the URL from a <60FPS tab into a new one also gets 60FPS, so seems something to do with the Tab & Domain combo that is affected. 1829159 1 ap 2022-01-07 17:50:44 -0800 Thank you for the report! Could you please confirm if this issue is new in iOS 15.x, or if it affected earlier versions too? 1830173 2 simontaylor1 2022-01-12 09:36:05 -0800 (In reply to Alexey Proskuryakov from comment #1) > Thank you for the report! Could you please confirm if this issue is new in > iOS 15.x, or if it affected earlier versions too? I think it's a 15.x regression - I can't reproduce on a 14.8.1 iPhone 12 mini. 100% reproducible on iPhone 12 Pro and iPod touch 7th gen, both on 15.2. I don't have any devices on other 15.x releases I'm afraid. In terms of relation to Bug 235114 - they are distinct, but both hinting at issues on tabs becoming foregrounded. If you go back and forth to the demo on that page, you can repro this bug too. Note in "normal" case the rAF loop is < 60 FPS on the Bug 235114 demo page though - that's on purpose to trigger high clocks and keep the CPU busy. So that demo is typically 50 FPS unless this bug is also in play, when it'll drop to 25 FPS. 1830183 3 webkit-bug-importer 2022-01-12 09:56:55 -0800 <rdar://problem/87465488> 1830502 4 simontaylor1 2022-01-13 03:09:24 -0800 > (In reply to Alexey Proskuryakov from comment #1) > > Thank you for the report! Could you please confirm if this issue is new in > > iOS 15.x, or if it affected earlier versions too? > > I think it's a 15.x regression - I can't reproduce on a 14.8.1 iPhone 12 > mini. > > 100% reproducible on iPhone 12 Pro and iPod touch 7th gen, both on 15.2. I > don't have any devices on other 15.x releases I'm afraid. It does also reproduce on the 15.0 Simulator if that helps narrow things down at all. 1842206 5 simontaylor1 2022-02-16 02:53:10 -0800 Still reproduces easily in iOS 15.4 beta 3, iPhone 12 Pro. 1846596 6 simontaylor1 2022-02-28 04:07:17 -0800 Still with us on 15.4 beta 4 (verified on iPod touch 7th gen). 1853177 7 graouts 2022-03-21 07:10:05 -0700 RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback() returns false because there is no m_drawingArea. As a result RenderingUpdateScheduler::scheduleRenderingUpdate() falls back to using a timer. 1853283 8 graouts 2022-03-21 12:09:35 -0700 This regressed with r275792, the fix for bug 224395. 1880904 9 simon.fraser 2022-07-05 22:11:02 -0700 Pull request: https://github.com/WebKit/WebKit/pull/2113 1881122 10 ews-feeder 2022-07-06 14:36:13 -0700 Committed 252188@main (0842b6a96626): <https://commits.webkit.org/252188@main> Reviewed commits have been landed. Closing PR #2113 and removing active labels. 1881605 11 simontaylor1 2022-07-08 02:42:25 -0700 Great, thanks for the fix. Another potential related issue that was much harder to reproduce - occasionally when initially viewing a tab (I commonly access pages via QR scans in the camera, and often from the same domain) I've seen it look like it's being actively throttled with a lower rAF rate - almost as if Webkit considers the tab to be a background one. Looking at the commit message (with a very limited understanding) - is it possible the same underlying bug might have caused this behaviour? 1881689 12 simon.fraser 2022-07-08 10:14:59 -0700 It's possible, but if you can figure out steps to reproduce this reliably I can test it. 1882039 13 simontaylor1 2022-07-11 03:29:01 -0700 I wasn't able to find reproduction steps last time I tried - it might be that Safari needs to have been idle for a while with some particular state of open tabs to trigger it, or it might just be something timing related that makes it not very reproducible anyway. Once this fix ships in an iOS release I'll keep my eye out for it.