Performance Tips

Measuring performance

There are two system expressions that are important for determining performance:

fps - returns the current frames per second rate. Usually the top speed is 60 frames per second, but it can change depending on the system.

renderer - returns either canvas2d or webgl depending on the renderer in use. The WebGL renderer is several times faster than Canvas2D, but isn't always supported. For more information see the Technology section.

You can display both of these in a Text object to keep an eye on performance while testing your game, using an action like:

Set text to fps & " FPS (" & renderer & ")"

This will display a string like 60 FPS (webgl) indicating both the framerate and renderer.

Mobile devices

It's more difficult to get good performance on mobile devices for a number of reasons:

- They have weaker hardware: slower CPUs, slower graphics cards and less memory.
- They have slower javascript engines.
- Most devices do not currently support WebGL at all.
- Most devices currently do not use hardware acceleration at all even for the 2D canvas; they will only use slow software renderers.

There are two important tweaks to make specifically for mobiles to ensure the best performance. These only apply to mobiles which tend to use software rendering:

1) Set 'Pixel rounding' to 'On' in Project Properties. This avoids drawing objects in between pixels which does a more expensive interpolation.

2) If your game's background is obscured by objects like Tiled Backgrounds, set 'Clear background' to 'No' in Project Properties and also make sure every layer has 'Transparent' set to 'Yes'. This only works if objects are totally covering up your background, but it can save two full-screen clears every frame which helps make the game more efficient. If your background is not totally covered with objects use only one opaque layer at the bottom - you can still set Clear Background to No for a small speed-up.

Mobile performance should improve with time, and Scirra are also actively researching ways to improve it, but it is a work in progress. When targeting mobile devices, you should aim to design significantly simpler games to ensure a good experience. Test on mobiles from the very start of your project to avoid any surprises and have lower expectations of framerate (30 FPS is a good target for mobile).

WebGL

WebGL is currently the best way to optimise games for desktop computers. WebGL is several times faster than the Canvas 2D renderer, so for best performance you should make sure it is enabled in project properties. However, WebGL is not always supported, so enabling it does not guarantee that the game is rendering with WebGL. If WebGL is not supported it will fall back to the Canvas 2D renderer instead. This is why it's important to display the renderer in use when investigating your project's performance.

There are several reasons WebGL may not be supported. These are listed below:

- The browser may not support WebGL. For example, Internet Explorer currently does not support WebGL. It will always use the slower Canvas 2D renderer. To improve performance, try switching to a browser which supports WebGL, like Firefox or Chrome. You should also always stay up to date with the latest version of your browser for best support.

- Your graphics card driver may be out of date. To guarantee a stable browsing experience, browsers sometimes disable WebGL if the graphics card driver is known to be buggy. Updating your graphics card driver may fix this problem.

- Your computer may simply be too old or have unsupported hardware. Very old graphics hardware may not be able to support WebGL at all. If possible, upgrading your graphics card to a new one may fix this problem. However, don't forget your game is probably still playable with the Canvas 2D renderer - it will just be slower.

Common causes of poor performance

Some of the most common things causing slowdowns are listed below. This list is not exhaustive. There may be other reasons your game is running slowly not listed here.

Too many objects using Physics
The Physics behavior is very CPU intensive. Using more than 50 objects with the Physics behavior can cause considerable slowdown. You should design your games to use a few large Physics objects rather than many small Physics objects.

Creating too many objects
While modern computers are very fast, they still have a limited processing capacity. Creating over 1000 objects will probably cause your game to slow down. Try to design your game to use fewer objects. The system expression objectcount can tell you how many objects you are using.

Using too many particles
The Particles object can easily create hundreds of particles. Each particle is like a sprite, so it can rapidly use up available processing power. Avoid using more than a couple of hundred particles on desktop. It is recommended to avoid using particles at all on mobile if possible; if you still use them, try to keep less than 50 particles. Use the ParticleCount expression to help count how many particles you have created.

Using Sprites instead of Tiled Backgrounds
Creating too many objects can cause slowdowns, and a common mistake is to use grids of Sprite objects instead of Tiled Background objects. For example, a 20x20 grid of sprites has 400 objects, which is a significant impact on the object count. A single tiled background can replace the grid of sprites and it only counts as a single object. Tiled backgrounds are specially optimised for repeating their texture so in this case it is literally 400 times more efficient than the grid of sprites. Always use Tiled Backgrounds instead of repeating Sprites wherever possible.

Using a slow browser
Browsers do not all perform the same. You may find better performing browser by testing across a range of browsers.

No hardware acceleration
Usually even the slower Canvas 2D renderer is still hardware accelerated by the computer's graphics card. However, sometimes even the Canvas 2D is not hardware accelerated and uses a very slow software renderer. There is no easy way to tell this, but it is usually indicated by significantly worse performance on one system. Test on several computers to see if poor performance is a one-off, and make sure the graphics card drivers are up-to-date.

Using too many loops
This is rarer, but using too many loops like For, For Each and Repeat can cause the game to slow down. Nested loops are especially likely to cause this. To test if this is the problem, try temporarily disabling the looping events.

Common misconceptions

The following things are often accused of affecting performance (as in, the framerate at runtime), but probably have little or no effect:

Image formats (e.g. JPEG, PNG-8, PNG-32) affect the download size but have no effect on runtime performance (they are all decompressed to 32-bit bitmap on startup).

Audio formats also only affect the download size but have no effect on runtime performance.

Number of layers usually has no effect, unless most of the layers have changed their opacity or use 'force own texture'. However typically there is no performance difference compared to having everything on one layer.

Number of layouts also is unlikely to have any effect other than the download size.

Size, angle or opacity of sprites/tiled backgrounds has no effect when hardware acceleration is in use. This may be a little surprising or counter-intuitive, but modern graphics cards can usually render a sprite at the same speed regardless of whether it is tiny or huge (fullscreen or even bigger) and regardless of its angle or opacity. However, if the game is software rendered, these can have a serious impact on performance; be sure to test on a range of systems.

Floating-point positions (e.g. positioning a sprite at X = 10.5) similarly has no effect when hardware acceleration is in use. You may observe performance improvement on software-rendered systems by setting Pixel rounding to On, which forces all objects to render at integer co-ordinates. This is a good idea for mobile devices.

Measure and test

From the start of your project you should use a framerate indicator and keep an eye on performance. This allows you to notice if a particular change you have made has seriously affected performance.

Test your project on as many systems and browsers as possible.

If you think something is causing performance problems in your project, it is usually easy to test the theory: back up your project, delete the thing in question, and see if the framerate has improved. If it improves, the thing you deleted was the cause; if not, it must be something else.

Always measure performance. Computer systems are highly complex, and there are many unexpected or counter-intuitive results in performance. The only way to know what effect something has on performance is to measure it. If you cannot measure a difference, it probably has no serious effect on performance.