I am making some html canvas files, and when I run them in Chrome they work fine but the fan starts whooshing up and if I check in Activity Monitor on my Mac it says Google Chrome Helper is using massive amounts of CPU. To test, I removed all actions, tweens etc, but even with just the graphics sitting there, unanimated, it still used lots of CPU. So I gradually removed the graphic elements, one by one, and the amount of CPU used gradually reduced. So it looks like it is simply the graphics themselves that are the problem. They are, of necessity, quite large graphics - there's nothing I can do about that as it is a requirement of the brief. But I am wondering what I can do to at least minimise the problem. I have looked around online and haven't found any clear info on this apart from the obvious, so I'd be v grateful if anyone could point me at any resources/documentation about this issue.
Yeah. You figured it out yourself: your graphical structure may be too complex.
Here are some personal tips for performnace improvements:
- Consider turning off the advanced layers mode (Ctrl/Cmd + J) if you don't need advanced features like camera or parenting because this mode has some impact on performance;
- Avoid complex containers with lots of children;
- Avoid complex shapes;
- Make sure you're not using color effects/filters;
- Use cache whenever possible;
- Avoid using large bitmaps. This is specially true for mobile devices;
- Try to balance wisely when an asset should be made of a vector shape or of a bitmap;
- Avoid using too many static text fields because they are exported as raw vector shapes;
- Avoid adding too many listeners;
- Add mouse events to a container and use the event.target property instead of adding a separate mouse event to dozens or hundreds of children;
- If possible set a container.tickChildren to false so the tick will not be propagated to children of a container;
- If using a tick event it may be a good idea to change the Ticker.timingMode and see which one works best for your case;
- Avoid using motion tweens because they are exported as frame by frame animation;
- Avoid having a huge main timeline with lots of tweens;
- Avoing very large shape tween spans.
If even with these tips you still can't get your output running with lower CPU and RAM resources, would you mind letting us taking a look at your FLA?