Memory Management with CocoonJS
We have created a general blogpost about memory management that we highly recommend you to read (http://blog.ludei.com/techniques-to-optimize-memory-use-in-ludeis-canvas-environment/). However, we want to clarify some Construct2 specific topics regarding memory management and our relationship with Scirra in this post.
First of all, we understand that CocoonJS Canvas+ might not have worked as expected in some situations. You need to understand that the Canvas+ environment is a homemade subset of a browser created from scratch, which is a big challenge for a startup company. We dared to create a multiplatform (iOS and Android) canvas 2D and webgl implementation and compete in performance against browsers/webviews like safari and chrome, which have thousands of contributors including companies like Apple and Google with unlimited resources and money. CocoonJS' Canvas+ environment have been with no doubt the best performing cross-platform HTML5 execution environment for years and we are really proud of it.
It’s true that Canvas+ is not and will never be a complete web browser and that it does not render any DOM elements apart from canvas, but a complete browser was never our goal. Canvas+ was the first and is still the only platform to date that allows WebGL native app deployment in both iOS 5.0+ Android 2.3+. It is still the only platform to date compatible with wearable devices (we have talked with Chrome WebGL engineers about Canvas+ on Android Wear, and they are amazed about its results on those devices, soon to be announced!). It also supports some extensions like accelerated box2d implementation, multiplayer, social and others that are not supported by other HTML5 gaming wrappers. More than 4000 games have been published using Canvas+, and big companies like Disney, Nickelodeon and others have used Canvas+ to accelerate and publish their games. And if your game doesn’t fit into the Canvas+ runtime, remember that CocoonJS has evolved and it now supports other runtimes like the system Webview and Webview+ (for both iOS using the WKWebView and Android using Chromium), which are full browsers and your game will work in a plug and play way.
Ludei has been providing great tools and a cloud compiler for HTML5 developers for the last couple of years. And it has been a totally free product. Construct2 requires a paid licence to export to CocoonJS but we have never got one cent of the money from them nor have we asked for it. Other users using engines like Phaser or Pixi have successfully published their games for free using CocoonJS. On the other hand, we have benefited from many new users and published a lot of games thanks to Construct2 and we are glad about this mutual benefit and we hope that both Construct2 and CocoonJS will keep growing and becoming more successful. We recognize that the user support and the documentation have not been the best, but we are making an effort to improve it. We have released support for new runtimes, new plugin APIs and new documentation. As stated before we are a startup working on a technologically complex project competing against companies with unlimited resources and giving a free product and support, so please try to appreciate the challenges we face and know that we are doing the best we can with the resources we have.
That being said, it’s time to clarify the memory management issues. Ashley and some users have blamed us for loading all the assets at startup, for the lack of memory management support in CocoonJS and even for ignoring cooperation with Scirra. It’s true that Ashley and us had different opinions on the matter and we want to publicly explain our stance.
First of all, it’s false that Canvas+ lacks memory management. As explained in the above mentioned blogpost, we offer many APIs which give developers even more precise memory control than standard browsers (like the immediate "dispose" method). We might not have a perfect implementation but big companies like Nickelodeon, Disney, Non Stop Games (acquired by King.com) and others have published resource demanding games using a lot of high resolution images and audio files and are really happy to have these memory management features. For example the Nickelodeon app allows for loading more than 50 games in the same app execution, and if you check the app using a profiler, CocoonJS keeps the memory usage stable. Some heavy games even work on devices like the iPad 1, which doesn’t support more than two 2048x2048 textures at the same time in memory. This would be impossible if CocoonJS lacked memory management support.
The main issue between the CocoonJS Canvas+ and Construct2 marriage has been the assets loading at startup issue. We have explained in the blogpost that for a game engine implementation loading everything at start, relying on the browser/garbage-collector internal implementation (which may be different in each browser or JavaScript virtual machine) and forgetting about effective memory management is the easiest implementation possible. It works for small games that fit into the available memory but it’s not the best option for heavier games.
Construct2 loads all the assets at startup, and even though this approach may seem to work on desktop browsers due to unlimited memory and browser magic tricks, CocoonJS Canvas+ is not responsible for making the initial image load decisions. Canvas+ just loads an image when the "src" property is set from JavaScript, which is the responsibility of the game engine. The paramount disagreement between Ashley and CocoonJS is about how browsers handle image loading. He states that a browser doesn’t load the image into GPU memory when the "src" property is set but only when it’s rendered for the first time, and Construct2 relies on that expected behaviour to handle the memory usage.
Clearly we have different philosophical views on the matter. The CocoonJS core team has a proven track record developing successful videogames with millions of downloads (check Slide Soccer, iBasket, etc) and they have proven strong C++/OpenGL skills. The entire team agrees that preloaded OpenGL textures make HTML5 games feel more native-like. Reading an image from disk and uploading a texture to the GPU is an expensive operation, which may lead to noticeable glitches or pauses if the process is carried out in the middle of a render animation. That’s why we are going to keep this approach as the default in Canvas+. Do you prefer the other approach? We have added the "cocoonLazyLoad" property to enable it. Just use the one that works better for you.
Finally, we have performed some tests with a heavy Construct2 project provided by 
ArcadEd (thanks!). We are going to share a comparison between Canvas+ and the system WebView on iOS to demonstrate that the blame for the lack of memory management on Canvas+ are unfounded. All the tests have been done using CocoonJS Launcher v2.1, iPhone 5 using iOS 8.0.2 and XCode profiler (which measures memory usage in a reliable way).
Test using WebGL Context
The test is performed using default settings in both Canvas+ and Webview.
Surprise, Construct2 running with WebGL eats almost twice the memory on WebView than on Canvas+. Good thing that Canvas+ has no support for memory management!
Test using Canvas2D context (WebGL disabled in the code)
As explained in the blogpost CocoonJS uses POT textures by default in Canvas2D contexts for performance reasons, while system WebView uses NPOT textures. The Construct2 engine or the provided test .capx doesn’t pack textures, so to make the comparison reliable we have enabled NPOT textures calling to the the "CocoonJS.Util.setNPOTAllowed(true)" method.
The memory peak is similar in both environments. It seems that Images are not properly released specially on Canvas+ even if the capx uses layout by layout. Inspecting the code with Google Chrome profiler we have found that Image references are strongly retained in the Construct2 engine and are not disposed of (when using canvas2D context). This is bad for the garbage collector. Here is an image of the google profiler, which detects 52 retained image objects:
Let’s enable the new Canvas+ "setMaxMemory" feature and see the results again:
With "setMaxMemory" set to around 100MB Canvas+ uses a lot less memory than the WebView!
Next Steps
We have released CocoonJS 2.1. Running a Construct2 game with WebGL mode has a good memory usage using default settings.
Running a Construct2 game with WebGL disabled (using Canvas2D) has the retained images problem. We have released the demanded "cocoonLazyLoad" feature, but the retained images on Construct2 are never released. So the problem is not fixed, it just happens later. We recommend that Ashley adds the "image.dispose && image.dispose();" method call in the layout by layout code. With this minimal change, the memory improvements would be amazing. Otherwise you can use the "setMaxMemory" utility.
We have added this code to CocoonJS Construct2 plugin initialization:
CocoonJS.App.setNPOTEnabled(false); //change to true to reduce memory usage. It might reduce performance on old GPUs.
//CocoonJS.App.setMaxMemory(70); //Uncomment this line to set the maxMemory threshold in Megabytes.[/code:33qxzywh]
You can set the values that work better for your game.
[h2][b]Conclusion[/b][/h2]
We have shown that Canvas+ is able to manage memory efficiently with a heavy capx. It even has a better memory usage than the system webview in some scenarios with both webgl and canvas2d contexts. We have improved and added new tools in CocoonJS 2.1, and we’ll keep improving it. We hope that this post clarifies the misunderstandings about the lack of memory management support in Canvas+. As we have improved CocoonJS we also think that Ashley can still improve some things in the Construct2 engine that could benefit not only Canvas+ but any other platform/runtime. Things like avoiding retained images, disposing them on Canvas 2D, packaging textures or using texture compression on WebGL would be very helpful for everyone.
We are always open to your suggestions. Remember that if you have any problem with memory usage in Canvas+ and you think that the problem is on our side you can send us a testcase and we’ll be glad to help you.