Adding TileSprite kills game FPS in Chrome on iPad - Phaser 2.0.5

[Dev Monster]

I have a game that is almost complete and I have been testing on a number of different devices. There is a TileSprite in the game for the background to give it a parallax effect and its working on all devices and all browsers except Chrome on iPad.

 

Here is a list of browsers and devices we tested on:

• Firefox Mac and PC
• Chrome Mac, PC, iPhone 4, iPhone 5, iPad 2 and iPad 3 (not working on iPad)
• Safari on Mac, iPhone 4, iPhone 5, iPad 2 and iPad 3
• IE 9, 10, 11

Safari on iPhone 4/5 and iPad 2/3 works perfectly. Chrome on Mac and PC and all other browsers are working perfectly.

 

I have narrowed down MOST of the problem to the TileSprite after removing all animations and adding them back in one by one. The problem in Chrome occurs even if we do not animate the TileSprite at all.

I have also found that the size of the TileSprite doesnt matter at all. Even if we add a super small TileSprite to the screen (no animation or anything), the game drops to under 10 FPS sometimes even 5 FPS. If we dont add the TileSprite to the screen the performance on Chrome is still super slow but at least the game is playable.

 

I have optimized all images and spritesheets using TinyPNG, minified the JSON files and a ton of other things to optimize the game but it just wont work on Chrome on iPad.

 

This TileSprite we are using in the game is 512x512 and only 46kb:

 

 

Does anyone have any ideas how to fix this issue?

 

Thanks!

[lewster32]

While I can't provide a specific answer for why the TileSprite in particular is causing issue, I can provide some comments that may help shed some light on performance issues:

• The file size of assets has no direct bearing on performance - optimising pngs only makes them download faster. The same thing goes for minifying json and JavaScript files. All of the assets are decompressed when actually used by the browser and then it's purely about the dimensions of the assets and how you use them.
• While this will probably not be cause for slowdown on iPads (which use canvas) Phaser apps that use WebGL benefit greatly from using texture atlases. If you can reduce the number of separate images being used to render the scene you improve performance noticeably - ideally having everything onscreen represented by a single texture atlas. With canvas this isn't really a concern.
• What is a concern for canvas is fill rate - relatively large sprites taking up much of the screen will take time to draw pixel by pixel onto the canvas, and as your game includes many large sprites, you can start to see how this may begin impacting performance.
• If your device is already struggling then every little addition will make an increasingly large impact on performance. If your game is running at 30fps, it's already running at half the rate it should be, so the hardware is under a lot of load. Even relatively minor things added at this stage will take you down into unplayable framerates.

I would suggest trying as an experiment to half the dimensions of all of your assets (which means there's a 4x reduction in the amount of pixels being pushed around) and see how that affects performance. I'd also suggest for future projects that you use texture atlases rather than individual images and sprite sheets, as these will at the least make your games much faster in webGL environments (which iOS 8 will support) without impacting the games when they fall back to canvas.

[Dev Monster]

@Lewster32

 

We are using texture atlases for almost all of our on screen animations. I dont think that has anything to do with the Chrome iPad issue.

 

We completely removed every item on stage and only added a TileSprite. The performance hit is exactly the same...the game drops to under 10 FPS. I think there is some type of problem with TileSprite and Chrome on iPad.

 

We dont experience the issue with any other browsers/platforms. It works completely fine on Chrome on PC and Mac and all other browsers. The only effected browser is Chrome on iPad.

[lewster32]

From what I could see it looked like each animation had its own sprite sheet (which is to be expected, animations currently need to share a single texture) however what I'm referring to is specifically a single texture atlas for all of your onscreen sprites, or at least trying to minimise the amount of separate image files used to render your scene. This is obviously not the culprit here, but it will certainly help increase performance in any game running on webGL.

 

I don't have access to an iPad running Chrome at the moment to be able to test this myself but it does seem odd that it's very specific to this platform and browser. Chrome's rendering engine on iOS is actually exactly the same as Safari's, as this was the way to guarantee speed on iOS given Apple's restrictions. Both currently use canvas, and TileSprite on canvas is much slower than on WebGL which has native support for panning the texture, but from games I've made in the past and tested on iOS, I didn't notice any problems such as yours.

 

I guess the best course of action is to keep experimenting and find out under what conditions TileSprite is causing slowdown (size, speed, are you using autoScroll or manually changing the tilePosition etc etc). Sorry that I can't be of any more help than that!

[Dev Monster]

We did combine most of the sprites into single spritesheets in the smaller versions for web and mobile, but the ipad version, since its HD, has very huge images. We tried combining but exceeded the spritesheet limit size and generated errors.

 

We attempted removing the background animation completely and putting it in HTML/JS. We scrolled the background using JS outside of the canvas but still experienced the terrible slow down. We only had the bird and characters moving on screen and no TileSprite in that scenario. So I think its more than just a TileSprite problem.

 

The game works well on the menu and instructions pages in Chrome for iPad and there are alot of transition animations for those pages. But it seems that having a scrolling background is killing the game no matter what we try. We tried the TileSprite which is the easiest, we tried TimelineLite in Phaser, we tried extracting the code and doing it outside of the canvas but we still cant make it work.

 

If anyone has any ideas or has run into this same issue on Chrome for iPad, please let me know how you fixed it.

 

We will keep trying to find a solution and post anything we find. =)

 

Thanks again for the feedback and help as always!

[Dev Monster]

From what I could see it looked like each animation had its own sprite sheet (which is to be expected, animations currently need to share a single texture) however what I'm referring to is specifically a single texture atlas for all of your onscreen sprites, or at least trying to minimise the amount of separate image files used to render your scene. This is obviously not the culprit here, but it will certainly help increase performance in any game running on webGL.

 

I don't have access to an iPad running Chrome at the moment to be able to test this myself but it does seem odd that it's very specific to this platform and browser. Chrome's rendering engine on iOS is actually exactly the same as Safari's, as this was the way to guarantee speed on iOS given Apple's restrictions. Both currently use canvas, and TileSprite on canvas is much slower than on WebGL which has native support for panning the texture, but from games I've made in the past and tested on iOS, I didn't notice any problems such as yours.

 

I guess the best course of action is to keep experimenting and find out under what conditions TileSprite is causing slowdown (size, speed, are you using autoScroll or manually changing the tilePosition etc etc). Sorry that I can't be of any more help than that!

 

We fixed the issue and the problem was exclusively with the TileSprite.

 

TileSprite works great on most browsers...but for some reason, iPad Chrome gets killed when a lot of animations are running at the same time. Lewster32, you were absolutely correct when you said Chrome's rendering engine is exactly the same as Safari. One thing I discovered was that its the same engine, but Safari is actually using a different JS library for performance.

 

"When iOS 7 launched, developers discovered that their apps with built-in web browsers were unable to achieve the same level of JavaScript performance as the stock Safari app. This was because Apple restricted use of its improved Nitro JavaScript engine to its own app, leaving third-parties with a slower version." http://9to5mac.com/2014/06/03/ios-8-webkit-changes-finally-allow-all-apps-to-have-the-same-performance-as-safari/

 

We wont  have to worry about this performance hit as of iOS8 because Apple released their restrictions so other browsers can use the Nitro JavaScript engine. Im sure Chrome will benefit greatly from this.

 

Instead of using a TileSprite in the game, we opted to use a sprite instead.

this.gameBg = this.add.sprite(0, 500, 'playing-game-bg');// and then in the update function we did this:// for ipad, we use the 2048 width as a modulus to move the backgroundthis.gameBg.x = (this.gameBg.x - 10])%2048;

This simple code above changed the entire game play in Chrome. Performance jumped from <10 FPS to over 30. The game is playable now on Chrome on ipad 2/3 and on iphone 4/5.

 

I hope this helps somebody else that is experiencing the same issues.

[lewster32]

You'll have even less to worry about because iOS8 enables webGL, so TileSprite will use native texture panning