In the first installment of the technical series, we talked about the main disadvantage of the HTML5 technology, that is its performance can be poor compared to a native app.
When testing Frank the Dillo a Kindle Fire HD it was so slow that it was unplayable.
Should Frank the Dillo be rewritten in Haxe, or is there a solution to make HTML5 games run faster?
It turns out that on mobile devices the 2 slower parts of an HTML5 game are the browser's DOM handling and the lack of hardware acceleration on some browser implementations, so if those 2 bottlenecks can be removed, there is some hope to achieve a playable frame rate.
As performance is a common problem of mobile HTML5 games, there are already a few solutions to this problem, but only 2 of them are viable for Frank the Dillo, that are:
Both address the mobile performance bottlenecks by implementing only a Javascript interpreter, a native hardware-accelerated Canvas API, and very few other Javascript APIs, instead of a full browser implementation.
The main advantage of Ejecta is that it is Open Source, so you have full control on what your app does, its cost is and will always be free, and there are no limitations in its usage.
Ejecta however has also its disadvantages: it is iOS only, and it implements fewer APIs than CocoonJS, but, being Open Source, both disadvantages can be addressed, in fact, there already exists an Android port called Ejecta-X, and the missing APIs can be implemented by anyone willing to.
CocoonJS, on the other hand, is a service provided by the company named Ludei, so its main disadvantage is that its usage is constrained by any limitation that Ludei wants to impose, and if Ludei wants to stop supporting CocoonJS, the service will not be available anymore.
That being said, CocoonJS is really easy to use, it works both on iOS and Android, and it implements a very complete set of APIs.
In conclusion, both solutions can make an HTML5 game run at playable frame rates on mobile devices, but there are 2 main disadvantages to this approach:
- In order to be fast, neither of these solutions implements the DOM, so the game menus have to be rendered using the Canvas, and libraries such as jQuery and Modernizr cannot be used, as they manipulate the DOM in their initialization, which also means that input events must be handled differently.
- Neither implements the Web Audio API, but, at least for Frank the Dillo, this isn't a huge problem, as friGame can use HTML5 Audio as a fallback.
In the past months we have been busy porting the menus of Frank the Dillo from HTML/CSS to the Canvas, and porting the event handling out of jQuery. After that, using CocoonJS, the game was playable on a Kindle Fire HD.
Comments !