iOS Performance (any tips or tricks?)

[Jonny Shaw]

Hi all, on with another slot game at the moment, the last one we did had issues performance wise with iOS and looks like this one is going to be the same.  Android & desktop were fine, hitting between 30fps - 60fps depending on the hardware. iOS though CPU load was massive, we were using spines for the icons (the slot was a 6x5 grid) and in the end had to drop the majority of them to simple sprites.  We had tried rendering to texture off canvas, and whilst it had performance gains on android and desktop, minimal on iOS.

There were quite a lot of spines being used in the previous game as the repeating reel strips were in bunches of 5's so dropped that system this time around, and have something a lot more similar to the pixi slot demo, with just one extra icon per reel masked out on a loop.  Still spines but only one instance of each icon being rendered on the app ticker to a sprite textures.

Again performance on desktop and android more than acceptable even with some more filters applied (50-60fps on a Galaxy S7) and 60fps solid on a Note8.  iPhone 6 15fps. 

Tried many things yesterday, removing all filters & masks, stopping the spine animations, rendering only a single frame (not on the ticker) and could only still get it to 25fps.  Really seems to be an issue with iOS and wondered if there were any tips (renderer settings?) to make it more on par with android/desktop.

The game wouldn't even load on my ipad3 either, no way to see why (with no access to a mac at present) though that thing is so damn slow, even the pixi slot demo runs at around 20fps max.

Any advice greatly appreciated!

 

[ivan.popelyshev]

Turn off Antialias if you use it. However slots demo doesnt have antialias option...

Curse you all, wealthy people with apple gadgets!

[Exca]

What kind of viewport you use for apple devices on the page?

[yigitozdemir]

Last week i was having an issue with Apple's Mobile devices like you.

- Setting Viewport 

- Using spritesheets despite of single sprites 

were boosted my project's performance. Single sprites will make lot's of draw calls, which gives poor performance on iOS.

[Jonny Shaw]

19 hours ago, ivan.popelyshev said:

Turn off Antialias if you use it. However slots demo doesnt have antialias option...

Curse you all, wealthy people with apple gadgets!

Already have unfortunately... 

18 hours ago, Exca said:

What kind of viewport you use for apple devices on the page?

this.viewport = {
            orientation: window.innerWidth < window.innerHeight ? 'vertical' : 'horizontal',
            width: 720,
            height: 1280
};

this.renderer = PIXI.autoDetectRenderer(this.viewport.width, this.viewport.height, { backgroundColor:0x0F0805, transparent: false, antialias: false });

720p with an orientation switch that activates only when the browser reaches 1:1 dimensions.  Basically just repositions elements of the hud and some other parameters.
 

[Jonny Shaw]

17 hours ago, yigitozdemir said:

Last week i was having an issue with Apple's Mobile devices like you.

- Setting Viewport 

- Using spritesheets despite of single sprites 

were boosted my project's performance. Single sprites will make lot's of draw calls, which gives poor performance on iOS.

sorry - with this do you mean having multiple sprites will cause the draw calls, in our previous slot rather than having the actual slot container on the stage we rendered the whole thing to a single sprite via rendertexture - would this still be a better option do you think?

[Exca]

26 minutes ago, sHAYM4N said:

Already have unfortunately... 

this.viewport = {
            orientation: window.innerWidth < window.innerHeight ? 'vertical' : 'horizontal',
            width: 720,
            height: 1280
};

this.renderer = PIXI.autoDetectRenderer(this.viewport.width, this.viewport.height, { backgroundColor:0x0F0805, transparent: false, antialias: false });

720p with an orientation switch that activates only when the browser reaches 1:1 dimensions.  Basically just repositions elements of the hud and some other parameters.
 

Sorry, I didnt mean the viewport of the webgl renderer. But the meta viewport tag in the page.

[Jonny Shaw]

29 minutes ago, Exca said:

Sorry, I didnt mean the viewport of the webgl renderer. But the meta viewport tag in the page.

<meta name="mobile-web-app-capable" content="yes">

<meta name="viewport" content="width=device-width, user-scalable=no">

<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no, minimal-ui">

[Exca]

That looks ok. The spritesheet post means that are you using a spritesheet for the images your are drawing or are they in single files? So one (or many) composite image or just lots of images with single asset in them. Having spritesheet allows the renderer to batch renders more efficiently as it doesn't need to swap the texture in use between draw calls.

[Jonny Shaw]

11 minutes ago, Exca said:

That looks ok. The spritesheet post means that are you using a spritesheet for the images your are drawing or are they in single files? So one (or many) composite image or just lots of images with single asset in them. Having spritesheet allows the renderer to batch renders more efficiently as it doesn't need to swap the texture in use between draw calls.

good point, thanks at the moment the only seperate images are the background (which is pretty big at 2560*1800 its set to this size for a bonus mode where we zoom out, so will still be native at 720p if that makes sense). There is one spine also used in the background for a controlbox, has no mesh and is duplicated - it just has lights that turn on and off.   I have an atlas for a gun turret, one for the reels themselves (which were planned to be animated) a singular png sprite for a background effect (which would be put into an atlas) but the main collection of images would be the spine icons which themselves all have an atlas, but we currently have 10 of them, with 2 more planned.  Presume they cant be combined into a singular atlas in anyway unless it was one singular spine for all the icons with different skeletons?

Oh and a singular bubble png sprite that is used in a particle container on each reel.

I did try removing everything but the slot but performance gain was only around 10 frames I am told  15fps to 25fps

[Exca]

The amount of stuff should render much quicker than that. If you try just an empty render what fps you get?

[yigitozdemir]

2560 * 1800 is really big image. You can also try separating it to 512x360 images and put them in an atlas (note: It's always better to use images with power of two dimensions), just render required ones.

You can control drawcalls using canvas renderer and firefox's canvas tool. 

[rines]

Have you tried isolating the problem by e.g. disabling components and enabling them one by one?

Starting with an empty stage and adding more to that.

Have you looked at the performance on other slot games using your iOS devices?

I haven't tried the PIXI slot demo, but other slots and our own slots work fine on our iOS devices, ranging from IPhone 5 to iPhone X, iPads etc.

[ShrewdPixel]

Not sure if you're still working on this problem or not, but I've recently switched to pixi.js from just writing my own vanilla Javascript for canvas games and did some preliminary testing on iOS devices. I've found that there are a few specific areas of functionality that will absolutely tank performance on iOS specifically, like blur.

If you disable blur on the pixi slot demo by commenting out that part of the code, the performance difference on iOS is quite massive. An older iPad that basically renders it as a slideshow will run at full speed after the blur is commented out. And pretty much the same visual effect can be gained by just having a second copy of the icons that are pre-blurred swapped out when needed.

So for example, if you have your code detect whether it's running on an iOS device, you can use the pre-blurred images to fake the effect and still keep your frame rate. This can allow you to have the best of both worlds: no change in functionality on desktop and Android, and only a slight visual difference on iOS but still running at full speed.

Another thing that can help quickly isolate these performance killers for iOS is to find the oldest/slowest iOS device you can find (I use the Xcode emulator on Mac to test several  older hardware models) and go through function demos for pixi.js one-by-one. When you find one that runs like a slideshow, you know you'll either have to disable some part or create your own workaround for it.

Hope that helps.