Mobile performance, game resolution and scaling

[BaseTen]

I'm investigating what resolution and scaling methods to use to get the best performance out of games on mobile devices and how people deal with retina devices.

 

I'm currently building a game which needs to work relatively well on mobile. It's been specced as in browser and not packaged as native, so using something like Ember or CocoonJS to get a performance boost is not an option, at least at the moment. I've also been provided assets at 1024 x 690, which seems way too big to get decent performance on anything but desktop.

 

I'm planning on forking the build based on devices and using hi and lo res assets. While this will help with bandwidth and memory, I wouldn't expect to get a performance boost unless the canvas element itself is also shrunk? Currently I'm tempted to do this and then upscale in css, either with standard width and height or a scale transform. I noticed this post regarding getting this to work without the browser triggering antialiasing (at this stage it seems to be not fully supported):

 

http://stackoverflow.com/questions/7615009/disable-interpolation-when-scaling-a-canvas

 

Has anyone used this technique successfully, or are there any other scaling methods which can be used to boost performance?

 

I've recently also seen this article on using the canvas backingStoreValue for working with retina screens:

 

http://www.html5rocks.com/en/tutorials/canvas/hidpi/

 

However if anything this is increasing the number of pixels in canvas, so isn't performance likely to suffer? Or will working at 1:1 pixels improve performance by reducing scaling operations?

 

Any tips would be greatly appreciated!

[rich]

What sort of game is it? That makes the biggest difference of all imho. If you are making a 'match 3' game then I wouldn't care about the asset sizes too much, as not a great deal will be moving on-screen at once. If you're making a platform game / side-scroller, then yes I'd go for a shrunken canvas expanded via CSS (hopefully the graphics will let you get away with this). Scaling totally does impact performance, but then so does drawing more pixels than the device can cope with So it's not an easy balance, it's very game specific.

[Pixels Commander]

It works good. 

 

Try to launch this demo in very small window and then scale browser to full screen. You`ll see that small size assets are loaded and canvas is very small. Then refresh page and canvas will become larger, assets will have higher resolutions.

 

In fact if you use 480*320 instead of 960*640 - you reduce the number of pixels to four times! Seems that it`s most effective optimization technique - to decrease number of pixels to draw and to store in memory.

 

FlashJS supports this scaling feature + multi resolution assets and this boosts perfomance a lot for mobiles.  Also there is AssetsManager to resize assets automatically for 4 different sizes, it can be used separately from FlashJS. Ad time =)))

[BaseTen]

@rich - It's a side scrolling road game (I'd say racer, but it's not really a racer!) - a lot of moving objects and a lot of parallax. So pretty much the whole canvas is redrawn each frame, I'd imagine that's the performance bottleneck really, especially at 1024 x 690 on iPad. But I'm looking to profile and confirm this as I continue the build.

 

@Pixels Commander - That's good to hear. What method are you using to scale up the canvas to the full browser window on mobile? Have you had any success with the nearest neighbour css scaling rules?

 

I'd imagine the scaling method also has an impact on performance, do CSS transforms significantly outperform width and height for example? 

[rich]

Yeah at 1024 x 672 you're already pushing a lot of pixels if those refresh every frame (which they would need to for a side-scroller). On iPad1 for example you'll be pushing it close to its limits just doing that, never mind adding sprites on the top. So I would strongly consider using a lower resolution and scaling with css width/height. I wouldn't expect there to be any significant speed difference between width/height and a css transform when scaling a GPU bound canvas. By all means do some perf tests to check, but if the canvas is fully contained on the GPU it should be irrelevant how that is actually scaled up.

[Pixels Commander]

@BaseTen - I use CSS to scale canvas and some JS code to keep aspect ratio. Did not tried nearest neighbour, but it`s very interesting. Please, post smth if you`ll have luck. Yes, @rich is absolutely right - CSS scaling is just hardware powered operation and it`s really cheap in this case. Also it`s good to have small canvas with small assets because of limited memory and weak internet connection on mobiles.

[BaseTen]

This method is working perfectly now across a range of devices (even touching 60fps on iPad1). I'm using EaselJS so there's no coordinate scaling out of the box, but I've set up my own virtual coordinate system and no problems so far. The nearest neighbour css as described in the above Stack Overflow post is working well, as the post states it's least supported on Chrome and on the desktop this is obvious (but not so relevant), Android is ok (or at least antialiasing artifacts aren't visible at that screen size) and for iOS (particularly iPad) it's working really nicely. I've not got a windows phone or tablet to test on. To summarise the post the relevant rules are:

 

 

image-rendering: optimizeSpeed;             /* Older versions of FF */

image-rendering: -moz-crisp-edges;          /* FF 6.0+ */

image-rendering: -webkit-optimize-contrast; /* Webkit (Safari now, Chrome soon) */

image-rendering: optimize-contrast;         /* Possible future browsers. */

-ms-interpolation-mode: nearest-neighbor;   /* IE */

 

Interestingly, for this game at least, using transform scale for upsizing the canvas is less performant than scaling with normal width and height styles (tested on iPhone 4, iPad1, iPad3, Samsung Galaxy Nexus and Nexus 4). The difference is more noticeable slower on iOS than Android.