Techniques to Optimize Memory Use in CocoonJS Canvas+ Environment

Memory is a critical resource in HTML5/JavaScript game development, especially on mobile devices. In a desktop environment you can load tons of textures but on some low-end mobile devices you can reach the maximum RAM limit quickly. Although JavaScript encourages automatic memory management by using a garbage collection mechanism, you shouldn’t ignore effective memory management techniques. HTML5/JavaScript applications can suffer the same memory related problems as native applications, such as memory leaks, out of memory issues and they must also deal with garbage collection pauses. 

This post will give you some general advice on memory optimization for HTML5 games and some CocoonJS Canvas+ specific tips.

Effective asset loading

Preloading all the assets at the start is the easiest and quickest way to manage the memory but it only works for small games where all the assets fit into the available memory. You shouldn’t preload everything on a heavy game, only the assets that you need each time, and dispose of the unneeded assets as soon as possible. Your game memory usage depends highly on your game engine (some of them do a better job than others). Don’t expect that the browser or the garbage collector will fix all your problems and that you can stop worrying about effective memory management.

Texture packer

Javascript images and canvas objects are backed into OpenGL textures and FBOs, usually using RGBA format, 32 bits per pixel. Think about it, for example a 2048×2048 image eats 16MB of memory!  Some GPUs require POT (Power Of Two) textures for the best performance, so keep in mind that some images could use more memory than their real size and use 2^n size textures whenever you can.

We recommend that you pack all your textures using one of the Sprite Packer tools out there. That way you’ll waste less memory and improve performance (by avoiding the number of context switchings) and loading times. Some HTML5 engines are able to pack all your textures at runtime, others don’t, so please check your engine features first.

Garbage Collection

JavaScript automatically frees objects when it detects that they are not used anymore, this process is called garbage collection. During a collection the execution on your page can be suspended for a moment. If your game creates too many JavaScript objects in each frame it can lead to noticeable pause issues. This is another example that proves that it is a mistake to forget about memory management on JavaScript. You should reuse javascript objects whenever possible.

The dispose method

Image and Canvas objects are disposed when the garbage collector detects that they are not reachable in the JS code. The disposal is not immediate, it may take some seconds depending on the heuristic rules of the JavaScript virtual machine. Using a WebGL context the developer has more precise control over the WebGL texture and buffers disposal but that’s not the case when using a 2d context or when dealing with Image and Canvas objects.

CocoonJS’ Canvas+ environment exposes a method called “dispose” on canvas, image and audio objects. This method immediately frees the associated texture or internal buffer, which is very useful for games with heavy textures or for games that need a greater control over the memory.

Using this CocoonJS Canvas+ exclusive feature is very easy. Imagine we have an image object represented by the “myImage” variable.
[code lang=”javascript”]
myImage.dispose && myImage.dispose(); // The same for canvas and audio objects.
[/code]

The memory warning event

iOS and Android native applications are able to receive a memory warning notification from the system. The default implementation in Canvas+ and WebView+ environments is to perform a garbage collection and free as many internal cached data objects as possible.

From CocoonJS Canvas +2.1, the environment exposes the “memorywarning“ notification as a window listener. It is strongly recommended that you implement this method and free up as much memory as possible by disposing of cached data objects, images on canvases that can be recreated.
[code lang=”javascript”]
Cocoon.on(“memorywarning”, function() {
// dispose of cached images and canvases that can be recreated
});
[/code]

Texture reducer

Texture reducer is a CocoonJS Canvas+ exclusive feature. When your game targets all resolutions you need huge textures for iPad retina like devices and small textures for small mobile devices. A game developer has many ways to handle this:

  1. Create different asset packages, HD and normal. Good solution but bigger app size.
  2. Scale down HD resources. Excessive memory usage and performance impact on small devices.
  3. Create smaller asset packages on runtime rendering to a canvas/texture. Good solution but some JavaScript engines don’t support this.

The CocoonJS Canvas+ texture reducer feature can transparently do the job for you. It uses the third approach and it is highly customizable (for example, you can only apply it to certain resources). Check out the complete API documentation to see how to set it up.

As the texture reduction lowers the quality of the final images to be displayed, an interesting approach that we have recommended to some customers is to apply it only for certain device models, leaving higher resolution for some others (you can use the “navigator.userAgent” property to identify the device model). This, of course, it is not an easy task on Android due to the big number of device types, but on iOS is definitively an interesting option, specially for older devices such as the iPhone4 or the iPad Mini 1st generation.

Max Memory Threshold

This new CocoonJS Canvas+ exclusive feature available from version 2.1 and higher, exposes the “setMaxMemory” utility method. When the max memory threshold is set, CocoonJS checks the total amount of texture sizes (images and canvases). When the runtime memory size reaches the max memory threshold, CocoonJS disposes of the least recently used textures until the memory fits the threshold. It disposes of textures used for JS Image objects (which can be reloaded later if needed or are drawn again). It doesn’t dispose of canvas objects because they cannot be reconstructed if they are used again in a render operation. This extension is designed to be used in 2D contexts, because in WebGL contexts the developer is the one responsible for memory disposal.

Check out the API documentation.

Lazy Loading

Another CocoonJS Canvas+ exclusive feature available on version 2.1 and higher we have added the “cocoonLazyLoad” boolean property to Image objects (we have also added a duplicate called “idtkLoadDisposed” for retro compatibility with Construct2). When the property is set to true, the image is not loaded until it’s used in a render operation. Engines that load all the assets at startup can benefit from this property. But do not forget to purge the textures when they are not needed again, for example, using the dispose mechanism described earlier!

NPOT Textures

Canvas+ uses POT (Power Of Two) textures by default in 2d contexts. This is very useful for performance improvements, especially on mobiles with old GPUs. But it can waste memory on games that don’t use packed or 2^n textures. In CocoonJS Canvas+ version 2.1 you can allow NPOT textures in Canvas2D contexts (they were already supported in WebGL).

Check out the API documentation.

Conclusion

We have covered some basics of memory management in HTML5 games and exposed Canvas+ specific tips and tools.  We are always open to your suggestions. Remember that if you have some 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.

Additional Notes about Ludei’s Canvas+ Environment

CocoonJS’ Canvas+ is not a full browser, but a highly optimized JavaScript Virtual Machine for Canvas 2D and WebGL environments. Comparing it to a full fetched browser is not recommended as browsers include “a lot of magic tricks” (and that is why sometimes they are big and slow). For example, a browser might be able to handle a 5000 by 5000 pixels image but that does not mean that the underlying device is able to do it, just that the browser is handling some things internally for you either lowering the quality of the image (downscaling it) or subdividing it. Very few native technologies (C++ game engines) allow this kind of features as the developers should know how to handle this situations correctly (do not use 5000×5000 textures in the first place). Here at Ludei we never intended to create a new browser, but provide a highly specialized runtime environment so HTML5 developers can be closer to the native side without ever leaving JavaScript and the great HTML5 APIs.

CocoonJS Enables Android Wear HTML5 App Development

Google announced Android Wear this year, a new Android OS version suitable for wearable devices (Google Glass and smartwatches for now). Of course, Ludei right away started to wonder what kind of HTML5 execution capabilities will be available in such interesting devices. A couple of weeks ago, we purchased several Android Wear watches and begin to perform some tests over them. The first thing that we noticed was that at least this initial version of Android Wear does not come with a system WebView. It kind of makes sense as it is a very constrained environment and webviews are very resource demanding. Every attempt to execute a full fetched web environment on Android Wear Smartwatches has shown really low performance. Still, we wanted to see HTML5 running on a Smartwatch and how a good of a fit our highly optimized Canvas+ technology could be for Android wear. Our results were really encouraging as Canvas+ works amazingly well on these devices. Check out the following video that shows some HTML5 canvas apps and games running on Android Wear!

Of course, some minor modifications had to be done both to the technology and our cloud compiler, but we are more than happy to announce that we have enabled a new compilation target inside the CocoonJS Cloud Compilation System so any developer inside our community can test it. As far as we know, CocoonJS is the only technology that allows to deploy hybrid HTML5 applications for Android Wear even supporting WebGL! This is just an initial testing environment that allows you to build Android Wear applications but there are some initial limitations:

  • Do not add ad services. These services use the system webview to show ads and as we mentioned, Android Wear does not have a system webview.
  • Although you will be able to install the resulting APK on your smartwatch, we need to work on ways to better integrate the Android and Android Wear experiences. Please, use this initial builds for testing purposes.

If you want to test it, you need to make sure your app works on our Canvas+ environment. You can test it using the CocoonJS Launcher for iOS on iTunes, GooglePlay or Amazon. Then, just go to the CocoonJS cloud compiler, create or select an existing project, go to “Compile Project” and you should see the new target “Android Wear”.

Screen Shot 2014-10-23 at 12.44.03

Once you select the target, as it happens with any other CocoonJS compilation, a simple APK will be built in our cloud service, similar to the GooglePlay, OUYA or Amazon APKs, and it will be sent to your email account, but this one completely prepared to be executed on a Android Wear device. Connecting to Android Wear devices is similar to any other Android device as you will need to activate the developer options in the device and allow USB debugging. 

Enjoy testing your games and apps on an Android Smartwatch!

The End Of The Wrappers? I Don’t Think So!

It’s official: HTML5 is hot once again. For the past year, many of the wishes that all HTML5 developers have been waiting for have finally come true. All major browsing technologies support the main HTML5 features that make this technology a great option to develop beautiful desktop sites and compelling mobile apps. The latest addition to the list of iOS 8 with its official support for WebGL and improved webview called WKWebView with Nitro JIT acceleration, has been widely applauded by the community. And there are plenty of other reasons to be happy if you are an HTML5 developer, as the runtime environment that will run your app or game is a major issue that has been holding back the widespreading of the web as a major development platform (specially on mobile) for the last years.

There are many articles out there around performance benchmarks of the current browsers. Chromium based solutions for Android, Internet Explorer supporting the main HTML5 specifications (and auto updating itself quite regularly), plenty of great app development frameworks, … the list of good news is long. And here at Ludei, we are glad that, finally, all the pieces are starting to come together. But (there is always a but ;)), we have been reading much about a concept we do not agree with, and is the apocaliptic calling to “the end of the wrapping technologies” for mobile web applications. Ludei has been providing great tools and technology for HTML5 developers for the last couple of years.

Ludei’s developer community has grown strong to 50,000 developers and more than 4,500 apps published on mobile markets. We are going to continue to provide a great development experience and the best tools and runtimes as long as they continue to come out to the market. But there is a reality we still know about: building compelling mobile web apps is not simple. And we are not just talking about developing the app itself. Some frameworks are getting mature, some are starting to show their potential, but there is a detail worth mentioning: the mobile space is not the same as desktop web app development.

  1. First of all, mobile users are used to and feel comfortable with app stores, so they want apps. Building an app is not a major issue, but still, lots of web developers do not want to face all the hassle of installing native SDKs, compile applications and moreover, update multiple tools to be able to create their final mobile apps.
  2. But not only this, successful apps need access to native SDKs and mobile features that may vary from one platform to the other, or even from one store to the other. We are talking about in-app payments, ad networks, push notifications, social network SDK integrations, etc.
  3. Additionally (and sadly), there is still not one runtime environment solution that fits all and not plenty of good tools to test and debug apps on mobile. At Ludei, we have developed our own HTML5 runtime environments (Canvas+ and WebView+) and we also provide access to use the system web browsing technologies. This way, developers can choose what works best for them depending on their app. Even our canvas only technology, Canvas+, has plenty of advantages that some other technologies do not have for some type of apps (mainly games): low footprint, advanced memory management, extensions, accelerated physics, full control over the runtime (crucial for some customers), etc.

All these features are what wrapping technologies like Ludei’s CocoonJS or Apache Cordova provide: A productive way of testing, creating and monetizing HTML5 mobile apps. The bottom line is, that we are far from a mobile browser only app and game market. App stores on mobile will continue to exist, and actually, that’s the beauty of HTML5, your product can exist in both environments (as a browser based discoverable app and a mobile app store app). Mobile web app development is here to stay and grow and wrapping technologies are far from being at their end, moreover, in our opinion, they are at their infancy.

CocoonJS Updates For Construct 2 Developers

Ludei has been for several years now serving as a game native hybrid HTML5 app building system for many Construct 2 (and other frameworks) users. A big number from our more than 42,000 developer community have used CocoonJS successfully to release final products to the stores, hundreds of them made with Construct 2. We have provided a good platform for many, but we also understand CocoonJS might not have worked as expected in some situations. We would like to clarify this and help the Construct 2 and other game and app development platform communities to grow and be successful.

First of all, CocoonJS has evolved in the last months. We started focusing just on HTML5 games, where we saw the biggest needs, about 3 years ago. The HTML5 Canvas component was available in mobile browsers and native hybrid technologies (WebViews), but it was slow, fragmented and lacking many advanced features (and still does). We developed Canvas+, a cross-platform technology for iOS and Android that solved many of these problems. But this technology has been built from the ground up by Ludei (yeah, we built a subset of a browser from scratch!) and it wanted to fulfill only one purpose: render HTML5 Canvas 2D and WebGL applications on mobile. It did and does not render any DOM elements apart from Canvas. It lacks many features. We have added some over time (basic HTML parsing, XHR, WebSockets, gamepad, …) but still, it is not a complete HTML5 execution environment. We understand that it can be a hard environment to work with (specially at the beginning) as it limits the HTML5 APIs that can be used. But despite these limitations, it has been used by all our games and by thousands of projects from our developer community that have been successfully published to the Apple AppStore, GooglePlay, Amazon, Tizen, OUYA, etc. Big companies like Disney, Nickelodeon and others have used it too to accelerate and publish their games.

About a year ago we realized that a new trend of HTML5 execution environments were about to be launched. The iOS WebView was getting better in every aspect, even on the Canvas execution (still lacking WebGL until iOS 8, released last week). Google released the source code for the Chromium Project for Android and was announcing a possible inclusion of the runtime inside every new Android. The Cordova community also grew and it has become the de facto standard for native hybrid app compilation. We went back to the roots and tried to include these technologies and as a result, WebView+, the System WebView execution environments and the CocoonJS Cordova Command Line Interface were added to CocoonJS.

Now CocoonJS is not just Canvas+, a HTML5 Canvas 2D and WebGL execution environment, it is a complete set of technologies that developers can test and use in order to select the one that best fits their needs. We have also contributed the WebView+ (Chrome based) to the Cordova community with the CocoonJS Cordova Command Line Interface so anyone can build their Android and iOS (WebView based) projects on their own. Our Cloud Compilation System also provides the option to compile the Cordova project for you, so you do not need to install nor update any SDKs locally.

Additionally, we made all of our CocoonJS Extensions available in any of these new environments (WebView+, WebView) too and of course, if you choose to use Cordova compilations, you can use any Cordova plugins.

Regarding the Construct 2 community specifically, as Scirra has hidden the CocoonJS export option from the latest release, and as we know there is a big part of the Construct 2 community that might still want to use our service, we are providing different solutions:

  1. The latest versions of Construct 2 hides anything related to CocoonJS by default. If you want to still get access to these features, you can do so by specifying to “show deprecated exports/plugins” by right clicking in both the Construct 2 export options and the Construct 2 plugins respectively.

image_02

image_00

  1. A couple of months ago we announced that CocoonJS Canvas+ was compatible with the regular Construct 2 HTML5 Web export option. This means that if you export to the HTML5 Web and still be able to test and deploy Canvas+ based projects. There might no be fullscreen mode when WebGL is enabled in this type of export but if you disable WebGL in Canvas+ and use it’s fast Canvas 2D acceleration, your game should be correctly adapt to the whole screen. Although we recommend option 1, we are also mentioning this possibility for all those developers that do not have the export to CocoonJS option.

image_03

image_01

  1. Remember that CocoonJS is a platform that provides different runtime environments. If you want a phonegap like experience, but still use an improved WebView on Android, you can use our WebView and WebView+ options and compile your Construct 2 HTML5 Web export using both the CocoonJS Cordova Command Line or the CocoonJS Cordova Cloud compiler.

All these runtime environments are available to be tested using the CocoonJS Launcher application for iOS, GooglePlay and Amazon, a great testing tool for your projects.

And we are still working on improving our platform and these are some of the features that will soon be available.

  • We are working hard to be even more Cordova compliant and provide a seamless integration of all our runtime environments in a simple to use cloud compilation service.
  • The cloud compiler will be exposed through a REST API so third party development frameworks can easily access it and provide a unified experience for their developers.
  • A new version of the Construct 2 plugin will be available soon with a new plugin id.
  • A new iOS runtime environment option will be available: WebView+, based on the new WKWebView iOS 8 component. We are experimenting with it right now.

We fully respect Scirra’s decision to hide the CocoonJS related options. Still, we think we need to remember and correctly communicate that CocoonJS is no longer just a Canvas+ execution environment and that still can provide a great final product native hybrid app compilation for many developers (even using Canvas+, used by many!) from Construct 2 or any other HTML5 development framework. We hope to see more and more WebView and WebView+ projects being compiled using CocoonJS!

The future of the CocoonJS Cordova Command Line Interface (CLI)

A couple of months ago we published our CocoonJS Command Line Interface (CLI) that let’s you compile Cordova based projects, which benefit from the Webview+ runtime. Today we want to share with you an approximation of what’s coming to the CocoonJS CLI in the following months.

One of the main tasks we are currently developing is the integration of the command line with our cloud. This will allow you to download projects locally and upload them back to Ludei’s cloud compiler, so the compilations you make with the CLI use all the project data you already have stored in the cloud compiler (e.g., your Facebook tokens, MoPub ad units…).

Another exciting change coming to the command line is the possibility of using Crosswalk as an alternative runtime environment. Crosswalk will join the current Webview+ and Canvas+ as another execution environment for applications made with Cordova/CocoonJS. The main benefit of using Crosswalk is that it has Android binaries for x86, so Android devices running Android 4.x x86 enjoy all the features of a modern browser specifically suited for the underlying CPU.

We will also update the HelloWorldApp/DeviceReady demo that is created when you make a project using “$ CocoonJS create”, so that this new sample app will use different features of the Webview+/Crosswalk to demonstrate the potential of these runtimes.

But remember that you can already benefit from the following features with the current version of CocoonJS CLI.

Already available features of the CocoonJS Cordova CLI

  • The CocoonJS-CLI is agnostic to a specific cordova 3.x version.
  • The Webview+ provides a chromium-based environment for your HTML5 hybrid apps. It will deliver all the power of Chrome and the same look and feel across every Android device on the market. As we promised, Android fragmentation is over!
  • Remote debugging

At this point, these are the tasks that are already in development and you’ll be able to use in the following months.

Roadmap for the upcoming months

  1. Integration with the Ludei’s file system API. (which let’s the user upload it’s local project and compile it in the cloud). No more hassle of setting up and updating the Cordova environment locally.
  2. Different execution environments support (either Canvas+, WebView+, Crosswalk or whatever environment may come in the future) thanks to the compilation in the cloud.
  3. Cloud project management from the command line.
  4. Live reload. This is a great feature that will allow that by just saving a source code file on the server, let the CocoonJS client be aware of the change and update itself “automagically”,  saving tons of time during development.

It seems that the CocoonJS Cordova Command Line Interface will bring many brand new features to our platform, what do you think?

CocoonJS 2.0.2 is live!

The new version 2.0.2 of CocoonJS is live! You can read the full changelog here but take a look to the highlights.

75d29906-c26e-4e89-9077-847c99fb632f

Canvas+

  • Fixed the crash on Tegra-based Android devices like the Samsung Galaxy Tab 10.
  • Fixed texture corruption bug that affects Phaser based games using WebGL.
  • Other improvements in audio, DOM node management, camera speed, computeStyle, etc.
  • More

WebView+

  • Updated the WebView+ to the latest stable Chromium version. Fixes some crashes, improves WebGL support, etc.
  • Other stability bugs fixed.
  • More

CocoonJS Launcher

  • Fixed the support for Android 2.3.
  • Settings are more homogeneous both on iOS and Android and are correctly stored between sessions.
  • Improved URL handling. The final slash is no longer necessary for URLs to a folder (a more browser-like behaviour).
  • The URL history button on Android shows all your URLs.
  • More

Extensions

  • Added a new native share functionality. CocoonJS.App.share() inside CocoonJS_App.js.
  • The CocoonJS Extension repository now provides branches for previous CocoonJS versions.
  • Fixed several bugs and updated the SDKs in the ad extension for MoPub and AdMob.
  • Fixed bugs on social, notification and multiplayer extensions.
  • More

Download the launcher from App Store, Google Play and Amazon App Store. The version with 2.0.2 has been submited to Google Play and Amazon and are waiting for review. Enjoy!

Web starter kit running on webview+

Last week Google released their last creation to improve the web development: the web starter kit. This project is a set of tools, good practices and tutorials to create good web experiences. You can get more info about the web starter kit here.

At Ludei we love every project that helps the community of developers to create awesome HTML5 apps. We’ve tested internally, and we’re passionate on this set of tools. Unfortunately, they’re not supporting older version of Android’s webview.

Ludei’s mission is to help HTML5 community to create awesome apps and games. Fortunately, some time ago, we released the webview+, a custom webview based on the chromium project. Webview+ is available from our cloud compiler for any android  device running version 4 and higher.

We have already tested it in our devices using CocoonJS launcher with the webview+. The result can’t be better.

web

As you see, the web starter kit is fully supported on webview+. Yay! ^_^

We encourage every web app lover to use it, and adopt it for their HTML5 apps, since we fully support this new toolset.

CocoonJS In App Purchases are easier than ever in Kiwi JS

WE  apple-touch-icon-144-precomposed  KiwiJS

KiwiJS is a game development framework that uses JavaScript and HTML5. Ludei and the team behind it have been working to make it compatible with Canvas+ in CocoonJS. Their feedback has been invaluable and CocoonJS has improved much thanks to this collaboration, as we do with any other game engine out there.

 

Both platforms have been compatible for a while now but today we are pleased to announce that our friends over at Gamelab have just launched version 1.0 of their HTML5 game framework Kiwi.js and a much needed In-App purchasing Plugin for CocoonJS! What we found is that this new version of Kiwi is easy for developers to use, comes with a ton of documentation, runs fast and offers a lot of useful features. The In-App Purchasing Plugin (which comes with an example store fashioned off the Kingdom Rush store) allows users to sell their consumable game items to players and to create virtual currencies within their game. Also available for purchase is a Cartoon Particle Effects Pack that promises to make your HTML5 games pop! 

 

Kiwi.js founder, Dan Milward, says that while the ‘indies’ are a well catered for community, his company has identified a need for professional services that provide a higher level of customer support to the industry as a whole. “What we want to see is the HTML5 space taken more seriously and used to create serious games. Our pro add-ons, customer support model and IP partners will all go towards helping make this happen.”

 

For more information head over to the kiwi website.

CocoonJS 2.0.1.

Good news! The new version of CocoonJS is live! This time the version number is 2.0.1 and it comes with some very important bug fixes and improvements.

Improvements on Canvas+

  • Canvas+ now correctly handles HTML5/Web export from Construct 2. Get more info here.
  • Makes “text/plain;charset=UTF-8” the default content-type
  • Allows XHR responses to be saved to disk a new cocoonSetOutputFile extension
  • Page pageLoaded / pageFailed are correctly called now.
  • Fixed Audio System deadlock when alcOpenDevice fails.
  • Correct font-face CSS style handling in Canvas+. Font file download is now possible. Get more info here.
  • … and more!

Improvements on WebView+

  • Added check to avoid null pointer exceptions when destroying the webview
  • Implemented webView setNetworkAvailable method, which triggers ‘online’ event on the JavaScript side
  • Fixed viewport size problem which happened in some devices
  • Fixed some missing resources bugs

Cloud Compiler

  • Added support for Cordova 3.3 and 3.4.

Check out the full changelog for the CocoonJS 2.0.1 release. Remember your feedback is valuable to us so we can find bugs and determine what other improvements need to be made. Enjoy CocoonJS 2.0.1! 😉

CocoonJS and Construct2’s “Great HTML5 Gaming Performance Test: 2014 edition”

Scirra, the company behind Construct2, a great HTML5 game authoring framework, released “The Great HTML5 Gaming Performance Test: 2014 edition” weeks ago. In this test, they used a Construct2 based game demo and executed it in numerous environments. Surprisingly (and we want to think that by mistake), they did not include CocoonJS’ Canvas+ in the comparison, but to help Scirra provide as much information as possible, and to be fair to the Construct2 developer community that has been actively using CocoonJS, we have used the same demo in almost all of the same devices (and some interesting additional one like an iPad1 with iOS 5!). These are the results:

Device Canvas+ canvas2d Canvas+ webgl Chrome34 webgl Firefox webgl Safari 7 canvas2d Ejecta webgl
Nexus 4 58 60  59 58 N/A N/A
Nexus 7 52 60 59 51 N/A N/A
SGS3 58 59 58 58 N/A N/A
iPad 2 53 55 N/A N/A 46 55
iPad 1 20 35 N/A N/A N/A N/A
iPhone 4S 32 51  N/A N/A 40 51
iPhone 5 60 60 N/A N/A 60 N/A
Kindle 44 58  N/A N/A N/A N/A

As you can see Canvas+ is really efficient for both 2d and webgl contexts in all of the devices that were tested (even on an iPad1!!!).

It is also important to remember that Chrome, Firefox and Safari are not technologies to create native apps for iOS or Android. If someone wants to run a game on a mobile browser, this list gives a good glimps of what to expect, but not all of the final users/players have these browsers and their latest versions installed (specially on Android) and most of these technologies won’t be an option to create native apps for existing mobile markets. Moreover, Safari has Nitro JIT so the comparison is also biased. Bottom line is that CocoonJS is still the only technology that allows webgl native app deployment for both iOS and Android using the same execution environment, with no fragmentation and with an easy one click final deployment.

The good news is that the new CocoonJS release 2.0.1 is soon to be out and with it anyone will be able test these results on his/her own easily by installing the CocoonJS Launcher App for iOS and/or Android. This new version of CocoonJS will execute any Construct2 project exported for the web out of the box, so this perf test will also work just by pointing to the following URL (either typing it or using the provided QRCode for your convenience):

http://www.scirra.com/demos/c2/sbperftest/

ScirraPerfTestURL

Happy perf-testing! 😉