Who decides what the framerate is?

I'm having an issue where I'm getting a 40fps locked framerate even though my CPU and GPU work is well within 60fps limits. The app will start out at 60fps, but sometimes something as simple as a device rotation will cause it to drop down to 40fps permanently.


The GPU Report stats are:


Frames Per Second (40)


Utilization

- Tiler 11%

- Renderer 10%

- Device 12%


Frame Time

- CPU 0.6ms

- GPU 3.0ms


Does the framerate get decided behind the scenes? Why does it drop down by itself?

For anyone else who runs into this: a hard reboot of the iPad and it looks like it's back to normal. 😕

Glad to hear you were able to work around the bug. Have you filed a bug report explaining your situation?

No, not sure what to put in the bug report. "Hey the framerate dropped to 40 by itself. Just wanted you to know."

Same issue here.My app works fine sometimes and the frame rate sticks up to 60 fps,but it doesn't otherwise. The frame rate drops to 40 fps exactly.never goes down lower than 40 fps.That's werid. I don't know why.

I believe this is a known issue, but it would be great to get your app and repro steps just to make sure.

We also seeing this issue on iOS 9 GM with one of our games that is in development. 75% of the times it is stuck at 40FPS. It seems to be triggered by a change in the view hierarchy (we add/remove UIViews from the view hierarchy that contains the Metal view). Generally, either adding or removing the view seems to trigger this problem. Note that it does not always happen, then it just runs perfectly at the expected 60 FPS.


We have seen a similar problem like this before where the frame rate seems stuck on 40 FPS, but that seemed to involve a Core Animation animation in the hierarchy. This problem seems to trigger without animation.


Interesting, restarting the device seems to fix i for nowt, I at least cannot reproduce it again. Will update once I do.


Device used: iPhone 5S, iOS 9 GM

Please do get a bug report filed. Two useful piece of information to collect would be:

- an Instruments file with data from the new GPU System Trace tool in instruments, which will show the overall timeline.

- using the CoreAnimation tool in instruments to 'color OpenGL fast path blue', and report if that highlights the layer or not

Ok, I think I just had this happen right now on one of our games that is on the App Store. Bringing up the pause menu and removing it (this overlays a UIView and then removes it) got us in this 'low fps' mode. Toggling the pause menu a few times and I got rid of it, but also sometimes triggered it again. This is on an iPhone 6+, iOS 9 and using Metal as rendering.


I will try to reproduce this using Instruments and file a bug report.

Well that didn't take long to reproduce. I filed a bug with the traces: #22737162 . I do not understand how you can move a track with this new Instruments, but by just zooming you can see the dropped frames clearly in the Metal Trace. The Core Animation tool happily reports 60 FPS all the time, and the screen also stays blue all the time, but the FPS were absolutely being dropped. Seems like 40 FPS.


We also had this just happen on another one of our iOS 9 devices, so it feels rather common.

Any progress on this issue? Causes and potential workarounds? I get it quite often now, and restarting a device seems to fix for about half a day then it starts happening again. We are also getting emails from our players and it will be a matter of time before the reviews will start getting worse.

This also happens in Scene Kit, with very simple projects, just particles, nothing else.


The Renderer component of the onscreen stats seem to add time to the frame activity to force it to lock at 40fps. So if other activities take less time in a frame, it bumps up the time in Renderer to maintain a stable 40fps.


I think this is a throttling similar to what happens with KernelTask on Macs when they get hot.


I'm not sure what the reason for it is. Turning on Quicktime on the Mac, and setting to do a screen record can jolt the device out of this state, or push it into it if it's not otherwise doing it.


This happens using both OpenGL and Metal on the device, which makes me think this is an OS function, pre-emptively featured as a result of impending 120Hz screen availability wherein 40fps is a reasonable compromise if an app can't maintain a stable 60fps.


Perhaps the new Apple TV will support 120Hz screens, or the iPad Pro has a 120Hz refresh within its variable frame rate technology.

So my bug report has just been marked duplicate, and the original is marked as 'closed'. Annoyingly, I cannot see what the resolution of the original bug is. This problem is still present in iOS 9.0.1, I just had occur again.

I'm also seeing this issue happen with my OpenGL ES 2.0 app. Strangely, it seems to only happen on my iPhone 6S Plus and not my iPhone 6 Plus or iPhone 5. When it gets locked into 40fps, sometimes double tapping home to open the multitasker and then going back into the app puts it at 60fps again. Bringing up a UIView can lock it into 40fps again but it's not consistent. On app launch it can either start locked at 40fps or 60fps. Very confusing & frustrating.

Just want to follow up I resolved my particular issue by making sure to set the opengl view contentScaleFactor to be the same as the main UIScreen nativeScale. On the iPhone 6 Plus the nativeScale will enable the fast path (as noted in Core Animation instruments when 'Color Compositing Fast-Path Blue' is checked). I was using UIScreen.scale instead, which is 3x for the iPhone 6 plus and the scaling that happened impacted the frame rate.

That is strange. The contentScale should not affect the fast path as far as I know. Anyway, we have this problem when fast path is perfectly blue (and Core Animation reports 60 FPS), but the actual frame rate is certainly *not* 60 FPS. And we also have it occur on OpenGL. Still no word from anyone at Apple. I just opened a DTS ticket about this, as we have it constantly and makes development really annoying.

Who decides what the framerate is?
 
 
Q