Bug 267054 – Running the WebView with unlimited FPS results in perceived lagginess (though FPS are high), until it freezes and then runs smoothly afterwards

• Component: WebGL
• Status: NEW

[Paul Rhomberg]

Created attachment 469279 [details]
Xcode project

I've been experimenting with the "Unlimited FPS" option in a test game made in Construct 3 (which runs inside the Webview) and it seems that Safari has issues with web games / applications that try to achieve maximum FPS values.

Although the reported FPS values are extremely high at first (around 4000+ on my 15 Pro), the actual experience is terrible as the perceived FPS are approx. in the twenties. 
This goes on for around 10-20 seconds, sometimes even one or two minutes and then gets dramatically worse as the FPS drop down to zero (the FPS counter also reports that) but go up quickly after that to around 2000 and then it feels smooth as it should. 

In summary, it takes a significant amount of time and a short freeze to make the game playable with unlimited FPS. As this option is working properly on Google Chrome (PC/Android), this likely is a WebKit bug. The xcode project is attached

[Paul Rhomberg]

For reference, this is the Construct 3 Bug report with an attached video in case that helps to resolve this issue. https://github.com/Scirra/Construct-bugs/issues/7702

[Kimmo Kinnunen]

Thank you for the report.

The iOS app would not show 4000 individual frames per second, only 60 or 120 of those. Rest of the work is discarded. As such, it's not really a high priority to investigate the issue. You could help us prioritize by mentioning what is the usecase for 4000 FPS.

If the use-case is recording the game run to a video as quickly as possible and then playing back the video 60 fps or such, maybe you could explain the capture mechanism and the mechanism  used to speed up the rendering. 

If you can export a web browser compatible version of the test case that would reproduce some part of the slowdown, that would be useful.


Likely related to bug 259756, where the slowdown would be explained by the unmapping of many destroyed iosurfaces.

[Ashley Gullen]

(Construct developer here) Construct has an unlimited framerate mode for performance testing. It is much easier to identify performance differences in unlimited mode as the varying FPS rate can be used as a measurement, whereas normal rendering is locked at V-sync and so cannot be used for this.

In Construct's unlimited framerate mode we essential schedule frames by posting a task rather than with requestAnimationFrame(), which basically means it runs as fast as possible while still responding to user input. However it appears there's a bug with Safari's frame scheduler in this case which causes it to respond strangely, and limits the ability to use this mode for performance testing.

[Paul Rhomberg]

Sorry for the late response, here is a web build: https://bug-267054.netlify.app/

[Paul Rhomberg]

However, it works fine in the browser on my iPhone. No weird slowdowns, or uneven fps values. Just like with bug 261685, I don't know why it's behaving differently inside of the export's webview

[Radar WebKit Bug Importer]

<rdar://problem/120798659>