As part of our continuing series, we ran the new Amazon Kindle Fire through our tests to see how it stacks up as an HTML5 app platform.
When the Kindle Fire was announced, we were excited about getting our hands on it. As the first mass-market tablet at the $200 price point, we knew it had a good shot at selling millions of units. But at the same time, we were apprehensive that Amazon might have skimped on hardware capabilities to reach that price. We were also concerned about the browser platform. The Fire runs a customized version of Android 2.3.4 (Gingerbread) and in the past, we’ve been disappointed with the quality and completeness of that browser. We were hoping that Amazon would improve the stock Gingerbread browser significantly.
“The Kindle Fire is a competent but minimal HTML5 platform that reflects its $200 price and Android 2.x lineage.”
After putting the Kindle Fire through our test wringer, we can say that while it’s a solid browser for normal page browsing, it lags the best of the competition in HTML5 capabilities. Constrained by its Gingerbread foundation, it’s a competent but minimal HTML5 platform that reflects its $200 price point. At this stage in the tablet game, we would expect better.
Table of Contents
Our First Look “Methodology”
Acid3 and Modernizr
The Fire scores a less than perfect 95/100 on the Acid3 test. Like other Android tablets, it lacks SVG support and incorrectly displays the Acid3 visual test compared to the reference implementation. With both the iPad2 and the BlackBerry PlayBook now scoring 100/100, this puts the Fire behind the pack. In addition. the Fire failed test 46 (media queries) and came in slower than required on three other tests including the self-described “challenging” test 26 for garbage collection speed.
We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. Since the Fire hardware lacks a camera, an accelerometer and a GPS, some of the results (geolocation failure!) are predictable. What Modernizr did find was support for CSS 2D transforms and Canvas as well as other Android 2.x capabilities. Notably absent: 3D transforms, web sockets, web workers and many HTML form input types. Again, not that surprising considering the Android 2.x heritage.
Happily, web fonts seem to be well supported. Both Google Fonts and Typekit dynamic fonts render correctly. But Typekit font loading and page scrolling on the Google Fonts page (with tens of different onscreen web fonts) was noticeably slow.
For the most part, the Amazon Kindle Fire has similar SunSpider results compared to Apple iPad 2 and BlackBerry PlayBook.
We threw caution to the wind and started off on our most challenging CSS3 animation test, the Kick Fu game that was developed for the launch of Sencha Animator. While the game did play, the frame rate was poor, and touch responsiveness while animations were running was also substandard. The Fire lacks a separate GPU, but the CPU has a competent GPU core – and even so, it looks like it wasn’t leveraged for hardware acceleration. The Playbook, for example, does a far better job leveraging the same GPU core.
We tried a Canvas-based GitHub network graph. Rendering performance was fine and the result was accurate. Pinch/zoom happily also works although Android’s tendency to toggle into low-quality mode when moving content reared its head once again. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid and we were able to change the scene without issue. However, like all webkit implementations, all bets were off when we zoomed and panned the page. Animation stuttered, froze and occasionally the accompanying audio cut out. We also looked at other Canvas animations and they worked at reasonable frame-rates.
Finally we tested embedded HTML5 audio and video. HTML5 audio playback seemed to work well, although the default playback controls were tiny, hard to touch and didn’t seem to work very well. HTML5 video is “supported’ but tapping play simply launches the video in the native player. Complete HTML5 video support with embedded playback and effects is not there. There also appears to be no Ogg Theora codec on the device as we couldn’t get any Ogg Theora demo to play.
“The Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal.”
Sencha Touch Kitchen Sink
Our Kitchen Sink app is built with Sencha Touch and tests all aspects of our mobile web app framework. The Kitchen Sink gives mobile browsers a good workout as it exercises a huge set of browser features including a wide range of CSS3 effects.
The first thing we noticed was the crispy CSS rounded corners. They’re not anti-aliased properly on the Fire. Webkit masks are also not supported. Then we got the first really big surprise of our run-through. We found that the Kindle Fire has problems processing touch events with good responsiveness. Update: and we’re not the only reviewers to notice this. And similar to early HTC phones (since fixed), the OS and browser seem to fight over who gets touch events. Sencha Touch 2 was designed to adapt to this behavior, so the Touch 2 preview kitchen sink works better than the Touch 1 version. And of course, since the Fire is based on Android 2.x, full multi-touch with independently tracked touches is not supported either.
As you’d expect with a device lacking a GPU, graphics effects like transitions were less than smooth, although display artifacts were not as bad as the full-screen flashes and repaints that are a problem on honeycomb-based tablets.
No to low Impact from “Accelerated Browsing”
Kindle Fire: Suggestions for the HTML5 App Developer
In summary, the Amazon Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal. It does a good job of displaying ordinary web pages and its resolution and rendering capabilities meet that need well. But there are too many sharp edges, performance issues, and missing HTML5 features for us to recommend that any developer create web apps primarily for the Kindle Fire. The iPad 2 running iOS 5 continues to be the tablet to beat, with the PlayBook a respectable runner-up in HTML5 capabilities.