Major iOS9 performance issues with Sprite Kit

Question

I am experiencing HUGE performance issues with iOS9 and I just can\'t figure out what to do. I\'ve read many posts - here, and here for example, but their suggested solution

Answer 1

It seems the majority of iOS9 issues are addressed in the latest iOS9.2 beta & Xcode 7.2 beta.

Thank you Apple for finally addressing the problem. Too bad I spent 2 months working on work-arounds.

I've been posting on Apple's forums, submitting bugs and communicating with a support technician. It's a shame that at no point did Apple offer any clarity over what issues they were aware of, and what the Sprite Kit team were addressing.

Still, at least it seems the majority of Sprite Kit issues are now resolved, and a career change is no longer necessary :]

Answer 2

Are you using SKLightNode? If so try removing all light node's from your code. I did this and my game is running back at 60fps like it did in iOS8.

Source:SKLightNode performance issues

Answer 3

There are two main issues.

One is a radical drop in performance of Sprite Kit from iOS 8 to iOS 9 for all manner of reasons, some of which you've linked to, but there are others. It seems many aspects of rendering, sorting and storing/dealing with nodes is either broken or doubling or tripling their previous loads on CPU/GPU.

However there's another issue that further compounds efforts to resolve any of the possible performance problems. It's a pervasive and seemingly arbitrary frame rate capping mechanism that's most frequently noticeable when it operates at 40fps. But it also operates at other frequencies.

For many years this capping has been (rarely) noticed when folks manually use CADisplayLink to create game loops or other timing based mechanisms on a frame per frame basis.

With iOS 9 this seemingly automated capping has become a terribly unwanted "feature" of Sprite Kit, SceneKit, Metal and OpenGL ES based applications.

In the case of SceneKit this is most telling because the capping occurs regardless of rendering choice - Metal or OpenGL - and seemingly on all devices, including things like the new 6S phones and the iPad Air 2, even with very simple, default template projects.

"Renderer" is a line item in the detailed statistics of SceneKit, onscreen, on the device. It's the most telling indication of a capping process. It's not there when a game runs stably at 60fps.

When capped at 40fps, no matter the amount of time required to do other activities onscreen and in logic, this component will absorb all remaining time in the game loop needed to maintain a solid 40fps capping. It varies according to the time required for other actives, always forcing an apparent goal of the underlying OS to hold the frame-rate at 40fps.

This problem in conjunction with the issues regarding iOS 9 Sprite Kit performance mean that it may not currently be possible to resolve all your issues. It will be extremely difficult to ascertain when you're hitting one of these (seemingly) arbitrary fps caps versus having caused an actual problem.

Just as an aside, these caps are not limited to 40fps. I've noticed them at 30fps, 24fps, 20fps, 15fps, 12fps and 8fps.

Of course Apple has never conceded nor admitted to this capping mechanism within the OS, nor commented on when/how/why it's so heavily impacting game and rendering processes.

My theory, as expressed in this post ( Inconsistent SceneKit framerate ), is that it's part of iOS designed to facilitate the use of variable frame rate technology soon to come in the iPad Pro, and possibly in other devices.

It would make sense that 120Hz become a base rate for future devices, particularly given the focus on performance advantages of iOS, the new Apple TV and 240Hz sampling of the screen touches/pen within the iPad Pro... and the considerable number of 120Hz televisions in the market.

Even without variable frame rate technology (say... your TV), 120Hz display rates means 24fps movies can be played back at a stable 5:5:5 pattern of frame display -- this massively increases the joy/immersion when watching films, just about all of which are shot at and truly exploit the advantages of a true 24fps for blur and motion effects.

120Hz with either variable frame rate technology or 5:5:5 frame display will also save Apple enormous effort in terms of compression and decompression of films when compared to the pulldown methods currently used on all devices with a maximum frame rate of 60fps.

All speculation, but I'd guess the use of these frame rate cappings in game engine technologies are there to help make games use less power, too, and give (in the future) developers an option to framerate lock their games in a variable frame rate device world. It's very unfortunate that (if this is the case) they have done such a poor job or sorting out the capping issues in the OS and the nature of Sprite Kit, leading to a scenario where you're fighting blindly to get good, high, consistent frame rates.

Apple silence and seemingly uncaring attitude towards the problems these two sets of issues are causing is (quite possibly) a very strong indication of how they feel about "their game development community".

And it's the greatest single problem of dealing with the kinds of cutting edge and performance critical development problems inherent to game making within a closed source framework from a needlessly secretive and uncommunicative (almost belligerent) organisation.

Answer 4

Lots of draws... Have you tried this?

skView.ignoresSiblingOrder = YES;

Answer 5

In the example you provided I can see one way to improve the draw count and to validate that the crop node isn't the problem. I don't know how practical this is in your actual game, but this drastically limits your draw calls.

#import "GameScene.h"

@interface GameScene ()

@property(nonatomic, strong)SKTexture *spaceshipTexture;
@end

@implementation GameScene

-(void)didMoveToView:(SKView *)view {
    /* Setup your scene here */
    SKLabelNode *myLabel = [SKLabelNode labelNodeWithFontNamed:@"Chalkduster"];

    myLabel.text = @"Hello, World!";
    myLabel.fontSize = 45;
    myLabel.position = CGPointMake(CGRectGetMidX(self.frame),
                                   CGRectGetMidY(self.frame));

    [self addChild:myLabel];

    //Create one texture to be used over an over
    SKSpriteNode *sprite = [SKSpriteNode spriteNodeWithImageNamed:@"Spaceship"];
    sprite.xScale = 0.5;
    sprite.yScale = 0.5;

    SKCropNode *cropNode = [[SKCropNode alloc] init];
    SKSpriteNode *mask = [SKSpriteNode spriteNodeWithColor:[UIColor blackColor] size:CGSizeMake(100, 100)];
    mask.position = sprite.position;
    [cropNode setMaskNode:mask];
    [cropNode addChild:sprite];
    [self addChild:cropNode];

    //temp add to scene to create the texture than remove
    //keep pointer to texture so it can be reused
    self.spaceshipTexture = [self.view textureFromNode:cropNode];
    [cropNode removeFromParent];

}

-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    /* Called when a touch begins */

    for (UITouch *touch in touches) {
        CGPoint location = [touch locationInNode:self];

        //re use texture
        SKSpriteNode *sprite = [SKSpriteNode spriteNodeWithTexture:self.spaceshipTexture];
        sprite.position = location;
        [self addChild:sprite];
    }
}

@end

The downside is that the issue remains when you get up to 120+ ish nodes on screen.

Also note I created a fresh SpriteKit app using the default template and removed the SKAction. Unfortunately even the default Apple template suffers huge fps drops when you get up to 120+ nodes. So I don't know if there will be an answer and your best course of action is to file a bug report because I believe it should (and use to be able to) handle that many on screen without a drop in fps.

Also something worth noting this error comes up on the default project which could be related...

2015-10-20 10:46:50.640 Test[2218:658384] <CAMetalLayer: 0x15fe987c0>: calling -display has no effect.

Update Doing a little more research I ran into this...

https://forums.developer.apple.com/thread/14487

Looks like others are filing bugs for this...