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.
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?
(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.
<rdar://problem/87465488>
> (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.
Still reproduces easily in iOS 15.4 beta 3, iPhone 12 Pro.
Still with us on 15.4 beta 4 (verified on iPod touch 7th gen).
RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback() returns false because there is no m_drawingArea. As a result RenderingUpdateScheduler::scheduleRenderingUpdate() falls back to using a timer.
This regressed with r275792, the fix for bug 224395.
Pull request: https://github.com/WebKit/WebKit/pull/2113
Committed 252188@main (0842b6a96626): <https://commits.webkit.org/252188@main> Reviewed commits have been landed. Closing PR #2113 and removing active labels.
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?
It's possible, but if you can figure out steps to reproduce this reliably I can test it.
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.