Firefox OS review: Burning bright

Performance

Performance is determined by two things - the hardware (obviously) and the software environment. Firefox OS is still a very new platform so cross-platform benchmarking will be difficult so we'll stick to browser benchmarks.

After all, Firefox OS apps are based on web technologies. That isn't to say they are slow - the ZTE Open C we used for this review is based on Qualcomm MSM8210 Snapdragon 200, which managed to move the UI with acceptable fluidity.

The chipset itself is nothing much, two Cortex-A7 cores at 1.2GHz and Adreno 302 with as little as 512MB RAM. The Open C represents sort of the Firefox mid-range. As we mentioned in the intro, Mozilla wants smartphones as cheap as $25 to ensure everyone can afford one.

Those will run on an even less capable hardware - the bottom is set at an 800MHz processor and 256MB RAM.

Anyway, the Sony Xperia E1 and Nokia X2 are powered by the same chipset and represent the kind of phone the ZTE Open C aim to replace.

The Open C performed fairly well in Kraken 1.1, a JavaScript benchmark. It was slightly behind the Motorola Moto E, another low-ender powered by dual Cortex-A7, but it beat the Nokia Lumia 630 hands down.

Kraken 1.1

Lower is better is better

• LG Nexus 5
  7148
• Motorola Moto E
  17213
• ZTE Open C
  19537
• Nokia Lumia 630
  26257

Hardware performance aside, we ran an HTML5 test to see how much coverage Firefox OS has over new web technologies. It's close behind the desktop Firefox 31 browser but lags a bit compared to Chrome 36 on Android (tested on Nexus 5).

HTML5

Higher is better is better

• Chrome 36 (Desktop)
  509
• Chrome 36 (Nexus 5)
  492
• Firefox 31 (desktop)
  477
• Firefox (ZTE Open C)
  463

The base of Firefox OS is founded in web technologies but version 1.3 added two important features - WebGL and asm.js.

WebGL is a wrapper over OpenGL ES 2.0 (the 3D platform used by Android prior to KitKat) so web sites - and web-based apps - have the same degree of control over the GPU as native apps. The Epic Citadel demo has already been ported to WebGL proving it's possible to have great graphics generated by the browser.

Asm.js is a bit more difficult to explain - it's a special subset of JavaScript that can be compiled straight into machine code, similar to how the bytecode of Android apps is compiled to native code. The goal is to reach near-native speeds of execution. Browsers that don't support asm.js can still run the code but without the performance benefits.

Asm.js code isn't written by hand, instead it's generated by tools like Emscripten, which take code written in C and transform it to asm.js-compatible JavaScript. This means developers can use existing C code bases when developing their apps.

In terms of speed, Mozilla published some benchmarks a year ago showing asm.js getting close to native speed and outperforming Dalvik, which was Android's runtime of choice back then. Of course, Android is transitioning to a new, faster runtime (ART), which is optional in KitKat and already mandatory in Android L. Asm.js has progressed since then, too.