[Webkit-unassigned] [Bug 234923] New: rAF on iOS 15.2 sometimes seems to lose connection to v-sync signal and runs at < 60 fps

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jan 6 07:31:39 PST 2022


https://bugs.webkit.org/show_bug.cgi?id=234923

            Bug ID: 234923
           Summary: rAF on iOS 15.2 sometimes seems to lose connection to
                    v-sync signal and runs at < 60 fps
           Product: WebKit
           Version: Safari 15
          Hardware: iPhone / iPad
                OS: iOS 15
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Canvas
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: simontaylor1 at ntlworld.com
                CC: dino at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220106/93b1b6a6/attachment.htm>


More information about the webkit-unassigned mailing list