3

In my app, I have several simple scenes (a single 80 segment sphere with a 500px by 1000px texture, rotating once a minute) displaying at once. When I open the app, everything goes smoothly. I get constant 120fps with less than 50mb of memory usage and around 30% cpu usage.

However, if I minimize the app and come back to it a minute later, or just stop interacting with the app for a while, the scenes all lag terribly and get around 4 fps, despite Xcode reporting 30fps, normal memory usage, and super low (~3%) cpu usage.

I get this behavior when testing on a real iPhone 7 iOS 10.3.1, and I'm not sure if this behavior exists on other devices or the emulator. Here is a sample project I pulled together to demonstrate this issue. (link here) Am I doing something wrong here? How can I make the scenes wake up and resume using as much cpu as they need to maintain good fps?

Brandon Slaght
  • 1,025
  • 1
  • 12
  • 34

2 Answers2

3

I won't probably answer the question you've asked directly, but can give you some points to think about.

  1. I launched you demo app on my iPod 6-th gen (64-bit), iOS 10.3.1 and it lags from the very beginning up to about a minute with FPS 2-3. Then after some time it starts to spin smoothly. The same after going background-foreground. It can be explained with some caching of textures.

  2. I resized one of the SCNView's so that it fits the screen, other views stayed behind. Set v4.showsStatistics = true And here what I got enter image description here

as you can see Metal flush takes about 18.3 ms for one frame and its only for one SCNView. According to this answer on Stackoverflow

So, if my interpretation is correct, that would mean that "Metal flush" measures the time the CPU spends waiting on video memory to free up so it can push more data and request operations to the GPU.

So we might suspect that problem is in 4 different SCNViews working with GPU simultaneously.

  1. Let's check it. Comparing to the 2-nd point, I've deleted 3 SCNViews behind and put 3 planets from those views to the front one. So that one SCNView has 4 planets at once. And here is the screenshot

enter image description here

and as you can see Metal flush takes up to 5 ms and its from the beginning and everything goes smoothly. Also you may notice that amount of triangles (top right icon) is four times as many as what we can see on the first screenshot.

To sum up, just try to combine all SCNNodes on one SCNView and possibly you'll get a speed up.

Community
  • 1
  • 1
Sander
  • 1,325
  • 1
  • 11
  • 30
  • While this answer is pretty in depth, unfortunately I do need to have multiple SCNViews: The things I am displaying are cells in a UITableView. If I maintained a single global scene object and added all the planets in as nodes in different locations with individual cameras, and in each SCNview displaying from a different camera in the scene, would this improve performance over maintaining many scenes? I guess it all comes down to how Metal handles refreshing a scene: If its once per camera or just once per Scene object. – Brandon Slaght Apr 26 '17 at 01:17
  • @Timestretch unfortunately I don't think having one SCNView for case you have to show several UITableViewCells is appropriate. Probably you might decrease performance overhead by reducing size of the image. Another way although quite resource intensive is to make one SCNView and make inside such design that use need, e.g. something similar to UITableView. I remember Apple made whole WWDC presentation about Scene Kit using nothing but SCNKit. – Sander Apr 26 '17 at 07:19
  • Awarding you the bounty because I'm fairly sure your answer led me to the right solution. Hopefully I'll have an answer up in a few days – Brandon Slaght Apr 27 '17 at 04:46
  • @Timestretch Glad to hear that. However, it would be fascinating to hear the way to go you've chosen and how it ended up performance-wise. – Sander Apr 27 '17 at 05:57
  • yeah, I plan on posting it! – Brandon Slaght Apr 27 '17 at 15:11
0

So, I finally figured out a partially functional solution, even though its not what I thought it would be.

The first thing I tried was to keep all the nodes in a single global scene as suggested by Sander's answer and set the delegate on one of the SCNViews as suggested in the second answer to this question. Maybe this used to work or it worked in a different context, but it didn't work for me.

How Sander ended up helping me was the use of the performance statistics, which I didn't know existed. I enabled them for one of my scenes, and something stood out to me about performance: In the first few seconds of running, before the app gets dramatic frame drops, the performance display read 240fps. "Why was this?", I thought. Who would need 240 fps on a mobile phone with a 60hz display, especially when the SceneKit default is 60. Then it hit me: 60 * 4 = 240.

What I guess was happening is that each update in a single scene triggered a "metal flush", meaning that each scene was being flushed 240 times per second. I would guess that this fills the gpu buffer (or memory? I have no idea) slowly, and eventually SceneKit needs to start clearing it out, and 240 fps across 4 views is simply too much for it to keep up with. (which explains why it initially gets good performance before dropping completely.).

My solution (and this is why I said "partial solution"), was to set the preferedFramesPerSecond for each SceneView to 15, for a total of 60 (I can also get away with 30 on my phone, but I'm not sure if this holds up on weaker devices). Unfortunately 15fps is noticeably choppy, but way better than the terrible performance I was getting originally.

Maybe in the future Apple will enable unique refreshes per SceneView.

TL;DR: set preferredFramesPerSecond to sum to 60 over all of your SceneViews.

Community
  • 1
  • 1
Brandon Slaght
  • 1,025
  • 1
  • 12
  • 34
  • Additionally, the way I am solving this for an unbounded number of scenes in a table view is to set the prefferedFramesPerSecond to 0 on cells that are not visible, and 15 when they are visible. – Brandon Slaght Apr 27 '17 at 17:02