Samsung Galaxy Android Tablet: The HTML5 Developer Scorecard
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 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.“The Samsung Galaxy Tab is billed as the first mass-market Android tablet; unfortunately, it's a little bit of a disappointment.”
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.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.
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.
There are 33 responses. Add yours.
MItchell Simoens
2 years agoJust 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
2 years agoQuite 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
2 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
2 years agoAwesome work. Thanks! Archos 101/70 next??
Hey guys! Which tablet for 220 dollars max? if not
2 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
2 years agoYou 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
2 years agoAs 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
2 years agoJason brilliant link. Thanks!
Apple iPad The Real Deal
2 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
2 years agoHi!
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
2 years agoAm 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
2 years agoFor 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
2 years agoDiario - 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
2 years agoMichael, 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
2 years agoAron - 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
2 years agoYou can surely remove the 1.5 upscale by using the viewport meta tag extension “targetDensityDpi = device-dpi”. Android supports this.
Aron
2 years agoAriya - 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
2 years agoKenneth: 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
2 years agoAriya: 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
2 years agoKenneth: 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
2 years agoExcellent 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
2 years agoTo 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
2 years agoAron: 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
2 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
2 years agoThanks 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
2 years agoJason: 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
2 years agoAron: 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
2 years agoThanks 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
2 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.
iulian
2 years agoEnable Flash in the browser in Android Samsung Galaxy
Charles
2 years agoLook to be a pretty powerful tablet.
itzco
2 years agoI 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
2 years agoAt 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.