Sencha Inc. | HTML5 Apps

Blog

Samsung Galaxy Android Tablet: The HTML5 Developer Scorecard

December 09, 2010 | Michael Mullany

Samsung Galaxy Android Tablet: The HTML5 Developer ScorecardThe 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. Samsung Galaxy Tab test results in the Acid3

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.

Performance Testing

Which is all to say that there are really no surprises in the feature and standards tests: the Galaxy seems to incorporate a mostly off-the-shelf copy of Android 2.2 (there are Samsung specific WebKit patches -- model number SPHP100 -- mostly for double-byte language support). So onwards to performance. For these tests we look at SunSpider Javascript benchmarks as well as real-world tests. Since SunSpider is a CPU-only test, it doesn't account for the fact that Apple offloads lots of tasks to the GPU for better performance, so a comparison isn't entirely fair. That said, the SunSpider results show a solid performance advantage on SunSpider for the Samsung Galaxy vs, the iPad running Apple iOS 4.2. In theory, we should see better performance on the Galaxy. samsung-galaxy-tab-performance-vs-ipad 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.

There are 33 responses. Add yours.

MItchell Simoens

4 years ago

Just like how the G1 was the first android phone, it was a bit of a disappointment. Maybe we will have a “Hero” like tablet.

Dowied

4 years ago

Quite a revealing writeup.  Do note however that the Galaxy Tab is running a version of Android that Google themselves asserted is not optimized for tablet operation- apparently Honeycomb (Android 3.0) is for that purpose. You can compare then (perhaps with iPad 2 by that time).

On another note, the graph above seems to be generated from Ext4- correct?  Question related to that (if you can say it this point): will we be able to have gradient backgrounds (or any customer non-white alternative) to Ext4 charts?  Thanks.

Ed Spencer

4 years ago

@Dowled the graph isn’t rendered using Ext 4 in this case, though we could have used it to achieve the same outcome.

You can tweak Ext 4 charts any way you like - including gradient backgrounds.

Dan

4 years ago

Awesome work. Thanks! Archos 101/70 next?? smile

Hey guys! Which tablet for 220 dollars max? if not

4 years ago

[...] S5PC110 with PowerVR SGX540 = 90 million triangles/sec   Check out the HTML5 developer scorecard: http://www.sencha.com/blog/2010/12/0…per-scorecard/  Galaxy Tab beats iPad 4.2 in all the performance testing.  Source         Reply With [...]

Jason

4 years ago

You should try target-densityDpi to get the full resolution in the browser.

http://darkforge.blogspot.com/2010/05/customize-android-browser-scaling-with.html

bastille1789

4 years ago

As far as the acid 3 test, it would depend on which browser you are using. On Dolphin and the stock browser, yes it turns out to 93. If you run the same test on Opera though, you do get a higher yield. You should check it out. If I recall correctly, I believe it is 100. I stuck with Dolphin HD anyway.

Michael Mullany

4 years ago

Jason brilliant link. Thanks!

Apple iPad The Real Deal

4 years ago

[...] still waiting for the first awesome Android tablet," the report observed.  Full Article here@ Samsung Galaxy Android Tablet: The HTML5 Developer Scorecard - Sencha - Blog   __________________ [...]

Aron

4 years ago

Hi!

I think you missed something very important about the Galaxy Tab. The built in browser is much slower than Dolphin browser HD regarding scrolling with Flash ON and running scripts.

Check this out:
http://www.telekom-presse.at/Der_Browser_Dolphin_bietet_bessere_Performance_auf_Android_Smartphones_und_Tablets.id.14340.htm

You can use babelfish from altavista to translate it. The main message is that the built in browser is much slower than Dolphin HD.

Please run one or two of your tests in Dolphin HD and report on it. Otherwise it is not a fair comparison.

Thanks & Regards!
Aron

Diário do Android

4 years ago

Am I wrong, or the chart is saying that less is better and the Galaxy Tab leading the way in which he says is worse than the iPad?

“Smaller is Better”

Mike

4 years ago

For many enterprises, the lack of NTLM authentication support on Android 2.2 makes the Galaxy Tab a non-starter for internal use. I didn’t have much of a problem with the device features, screen, etc., but since I was unable to access any internal applications, the device wasn’t much more than a comically large mobile phone.

Michael Mullany

4 years ago

Diario - the benchmarks show that the CPU on the Galaxy has better JavaScript performance than the CPU on the iPad, BUT it’s iPad’s use of GPU accleration that makes real world performance of the iPad superior to the Galaxy on anything graphics or animation intensive. I think I might have to make that point a little clearer in the blog.

Aron

4 years ago

Michael, are sure its the GPU thing which makes the difference and not the browser issue? Please, please, please test Dolphin HD on the Tab. Seems to make a huge difference in performance… maybe there is your explanation for speed difference…

Ariya

4 years ago

Aron - How would Dolphin or any similar browsers would exactly help here? Dolphin essentially “wraps” the standard Android WebKit library with browser GUI (e.g. menu, tabs, gesture, etc). All the dirty work of rendering, painting, parsing, etc is carried out by the said library, not the browser.

Kenneth Christiansen

4 years ago

You can surely remove the 1.5 upscale by using the viewport meta tag extension “targetDensityDpi = device-dpi”. Android supports this.

Aron

4 years ago

Ariya -  I don’t know how but everyone who had trouble with the built in browser seems to be happy using Dolphin HD. This tells me there is something done badly in the Tab’s built in browser, so that Dolphin can beat it so badly.

The good in that is that the Tab becomes a decent browsing device with Dolphin HD so please run one or two of tests again!

Thanks & Regards!
Aron

Ariya

4 years ago

Kenneth: Unfortunately that means we have to manually upscale the metrics for all the divs and text, because the dpi is still “fake”. That metatag just adds one more scaling factor to the equation.

Kenneth Christiansen

4 years ago

Ariya: If they adapted the browser to their device, you should get 1 css pixel = 1 real pixel with targetDensityDpi == device-dpi, and the media feature -webkit-pixel-ratio should be equal to 1.0, making it possible to detect these things using media features like

@media screen and (-webkit-pixel-ratio: 1.0) {
  body { background-color: green; ... }
}

It should be fake if you do *not* ask for device-dpi as you would get high-dpi (meaning a dpi of 240, which divided by 160 (a DIP = density independent pixel is defined as 160 dpi) results in the upscaling of 1.5.

Android supports custom values, and some prefines as “high-dpi” for the targetDensityDpi extension.

Ariya Hidayat

4 years ago

Kenneth: That is exactly the problem: device pixel ratio still returns 1.5 even after setting the dpi to the device dpi (and 1 css pixel = 1 physical pixel).

John Drefahl

4 years ago

Excellent write-up, and very informative.  I currently own a Galaxy S phone and couldn’t be happier.  But I think you are right to point out that until Android 3.0 is releases with optimization for tablets the Galaxy Tablet is kind of dead on arrival.  What I would love to see is just some write ups on all the grey market Android tablets that are available in China..  I wonder if they are experiencing much of the same issues.. or are they any better?

Aron

4 years ago

To John Drefahl: Dolphin browser HD is a whole different story on the Tab than the basic browser…

Its a pitty that authors don’t care to try it…

Ariya

4 years ago

Aron: In case I did not make clear: yes I did tested Dolphin HD on a variety of Android devices (including Samsung Galaxy Tab). And guess what? It produces the same result as the stock Android browser.

We’re testing the web rendering engine here (i.e. Android implementation of WebKit). Any browser that uses the same engine/library will yield the same tests outcome.

Jason

4 years ago

@Ariya,

If you don’t want to simply assume 1:1 pixel ratio on Android after adjusting the viewport, there is a trick you can employ to get the visual pixels on the screen using JS. Simply create a width:auto block element like a div, then render it in on the page, then using getComputedStyle to get the width of the element. Like so:

var div = document.getElementById(“tdiv”);
var divw = getComputedStyle(div, null).getPropertyValue(“width”);

You can then calculate your own pixel ratio. Of course, it would simply be easier to assume 1:1 and use screen.width.

At Yahoo, we do most of the rendering on the server side, so we keep a database of all the Android devices and their approximate pixel widths but since you guys just focus on Android/iOS you can just use this technique.

Aron

4 years ago

Thanks Ariya!

I did not get it earlier that you have run the test. Your result is very, very interesting, because it means that either the other testers reported experience is based on pure feelings and not scientic testing as your results. Check out carrypad.com or the Austrian site I linked earlier. Chippy at carrypad.com concluded also that Dolphin HD performance is superior to built in browser.

You wrote: “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.”

Every other tester said that Dolhin HD is much smoother than the built in browser in doing the scrolling with Flash.

I would like to ask that you re-run that srolling with Flash test again on the Tab… and in the mean time I could let the other testers know your results and page and invite then for a chat here… Would it be OK?

I got the feeling form others that Dolphin HD is significantly better in scrolling the page with Flash and now you contradicted it. This is a very important point so I would like to see clearly in it…

Ariya

4 years ago

Jason: I’m not sure I completely understand the idea. Our resolution independent approach works fine as long as the browser has a proper dpi and returns a sensible device pixel ratio, e.g. iOS with and without retina display.

Ariya

4 years ago

Aron: My experiment with Dolphin HD is independent of what is reported in this article. I did not focus, nor have interest, on Flash performance because we focus on standard web technologies (HTML5 family).

Again, everyone can run their own favorite browsers against various benchmarks out there (JavaScript tests such SunSpider, v8 benchmark, Dromaeo; Canvas tests: color cycler, ..) and compare the performance.

Aron

4 years ago

Thanks Ariya!
My point was that if Flash performace is better in Dolphin HD than what you reported in the basic browser, than maybe HTML5 performance could be better too. However you confirmed that your tests show same performance for HTML5 in both the built in browser and Dolphin HD. That is also a very interesting conclusion, because it highlights the mystery of the curious reason for the large Flash performance difference of these browsers.
Thanks & Regards!
Aron

Jason

4 years ago

@Ariya, I’m not familiar with how Sencha gets the pixel ratio, but you can calculate it yourself using the JS I posted above if the CSS media selectors are not working.

Charles

4 years ago

Look to be a pretty powerful tablet.

itzco

4 years ago

I got one and it’s a wonderful device, really loving it.
the CSS @media queryes are actually not working well but I found this blog which mentions how to fix it, it works for the browser not yet for opera:
http://darkforge.blogspot.com/2010/05/customize-android-browser-scaling-with.html

Jermajesty

3 years ago

At last, someone comes up with the “right” anewsr!

Comments are Gravatar enabled. Your email address will not be shown.

Commenting is not available in this channel entry.