The Samsung Galaxy Tab is the first widely-marketed Android Tablet to hit the market so we thought we’d take a look at how the device stacks up as an HTML5 app platform. We’ve been reasonably pleased with the iPad as a platform for HTML5 apps (although we’d prefer more memory and a better CPU -- we’re keeping our fingers crossed for iPad 2). Just as we did with the Blackberry Torch in August, we’re going to put the Samsung Galaxy Tab through our functionality and performance wringer.
“The Samsung Galaxy Tab is billed as the first mass-market Android tablet; unfortunately, it's a little bit of a disappointment.”
The Galaxy Tab has been a hot seller at Sprint stores here in the Bay Area, so after hitting three stores, we finally found one with a device in stock.
Our First Look "Methodology"
For consistency, we’re going to use the same battery of tests and use cases that we used in our Blackberry Torch review: a gauntlet of standards (Acid3), features (Modernizr), performance (SunSpider) and real-world tests.
Acid3 and Modernizr
The Galaxy scores a 93/100 on Acid3 (compared to 100/100 on the iPad). The failures are showing up in bucket 3 and bucket 5 of the test. Bucket 3 tests DOM2 Views, DOM2 Style, CSS3 selectors and Media Queries. The single failing test in Bucket 3 is a media query test. Bucket 5 includes a number of SVG tests, and since Android doesn’t ship with SVG, all these tests fail, subtracting 6 from the Acid3 score.
Next up, Modernizr! As with Android phones and the Galaxy Tab, Modernizr detects a fairly complete range of HTML5 Family features from CSS3 styles to localStorage and Canvas. There are, however, notable exceptions. In common with the iPad, the Galaxy Tab lacks Web Workers, WebGL, inline SVG and IndexedDB. Unlike the iPad (running iOS 4.2), the Galaxy Tab still lacks CSS3 3D transforms, SVG, and Web Sockets.
For real world testing, we checked basic CSS3 Animation performance using our own CSS3 vs. Flash Ads page. Happily, the Flash ads actually load on the Galaxy Tab. Sadly the performance of both Flash and CSS3 Ads are sub-par. Unlike the iPad, the Galaxy Tab does not use GPU acceleration for animation, so CSS3 Animations are quite choppy. What's more surprising is the sub-par Flash experience. Flash font rendering is pixelated to the point of being unreadable. And when the page is scrolled, the Flash Ads jiggle up and down as the browser tries to re-position Flash content to catch up to the page movement.
Moving to more complex animations, we next look at the more advanced CSS3 animations created by Sencha Animator. Since Animator relies heavily on 3D transforms, which Modernizr has already told us are not supported, it's not surprising that the animations don’t render correctly. (On a more surprising note web fonts don’t seem to load correctly either).
We skip SVG tests since Android doesn’t support SVG, and head straight to Canvas. We look at a github network graph. The graph renders perfectly, and reasonably quickly. Check! Then we put it through the Canvas color-cycling wringer. No dice. The load indicator simply sits there and spins. No dynamic Canvas on the Galaxy.
Finally we test HTML5 audio and video. Neither seems to work as embedded content, although it does seem that an HTML5 video will play via the native video player in full-screen view.
Sencha Touch Kitchen Sink
As we might expect from the preceding tests, most of the Sencha Touch Kitchen Sink just works, but the smoothness of both animations and scrolling isn’t as accomplished as the iPad. GPU acceleration for CSS3 transforms is a significant area of catch-up for the Android team.
The Samsung Galaxy Tab: Suggestions for the HTML5 App Developer
Beyond these specific tests, we should probably step back a second and look at some of the more general browser shortcomings in the Galaxy Tablet.
One of the oddest aspects of the Galaxy Tab browser is its CSS pixel to device pixel ratio. When queried in landscape mode, the Galaxy reports a screen.width of 683px and screen.height of 334px. Since the actual device resolution offers 1024×600, it's giving us a 1.5× ratio of device to CSS pixels. This is a little bit of an odd choice since there shouldn’t be any reason why it can’t offer a 1:1 device-to-CSS-pixel ratio (or even just match the iPhone/Nexus One convention of a 320 pixel device.width -- which would give it a 1.875 ratio). This makes the Galaxy slightly bigger than a regular phone screen in CSS pixels, but not really big enough to handle what people want to put in a tablet screen.
The practical effect of this decision is that the Galaxy Tab is effectively an "over-sized phone" for the purposes of web content. For example, an iPad-style side-navigation section just won’t fit on the screen. We think it's probably best to treat it as a phone with big pixels rather than a true tablet.
Additionally, with these big pixels comes another Android artifact. When the Android browser gets ready to animate anything -- whether it's a CSS animation or a plain old page scroll -- it shifts from high-quality to low-quality display mode. In low-quality mode, it turns off anti-aliasing (presumably on the theory that since things are moving, you won’t notice the quality degradation.) This would be less noticeable on a smaller device. But on the 7″ Galaxy Tab, the resulting pixelation is striking, particularly since it switches to low-quality mode as soon as it detects a touch start event (but before anything moves).
The Samsung Galaxy Tab is billed as the first mass-market Android tablet; unfortunately, it's a little bit of a disappointment. Its performance and other limitations make it more of an oversized Apple iPod touch than a true tablet. We’re still waiting for the first awesome Android tablet.