The HTML5 Scorecard: The Good, The Bad and the Ugly in iOS 7

We’ve been testing the final release of iOS 7 over the last few days against our usual battery of HTML5 tests. Normally we’re effusive about new releases of iOS to the point of fanboy-dom, but this time, and for the first time ever, we’re disappointed in the execution of iOS software. Although there are some impressive performance gains in SVG and JavaScript, the sheer number of bugs and broken features, clearly mark this release as a beta. While nowhere as bad as the Android 3 browser — our all time champ of broken web releases — we recommend that organizations standardized on HTML5 development hold off upgrading until an iOS update fixes these issues.

Update for iOS7.1 Mar 12, 2014: the iOS7.1 release happily fixes almost all of the web problems in iOS7.0 that we describe in this blog. Read our recent blog entry describing the HTML5 improvements in iOS7.1.

iOS 7 Bugs & Features

Max Firtman has already done an excellent first pass about the new features, bugs and quirks in iOS 7’s web runtime. If you haven’t read his post, you should read it now. We will not repeat all the findings here; but to review, there are two very big bugs in iOS 7. First, WebSQL permissions to increase the default 5MB of space for an app to the previously permitted 50MB limit no longer work correctly, and require a workaround. Second, “Save to Home Screen” apps are basically broken. Once more than four apps are saved to home screen, the save slots are recycled and sometimes duplicated, and the phone has to be rebooted in order to clear itself. Further, any external URI no longer opens correctly and all JavaScript modal dialogs (alert, prompt etc.) are disabled. Finally, If your app uses AppCache and you are managing state via hash or other mechanisms, the history object will never update, disabling history.back.

We recommend that organizations standardized on HTML5 development, hold off on upgrading to iOS 7 until an update fixes these issues.”

Beyond these major bugs, there are also some very troublesome design decisions in iOS 7. First, there is no way to hide the URL bar using JavaScript (and the user no longer has a “full screen” button in mobile Safari). This will throw a wrench into layouts if your app relies on absolute positioning. One workaround, suggested by Andrea Giammarchi, is to ask the user to take an action (such as swiping up) in order to reset into full-screen. But there is no programmatic way to do this (as of yet). And once you are in full-screen, tapping anywhere in the bottom region first summons the browser chrome and there is no way to cancel this. This makes for poor UX for bottom-positioned toolbars: the first user tap summons the browser chrome, which boosts the tool-bar up the page, and then requires the user to tap again to take an action. There are related problems with the status bar which can be worked around.

In addition to these decisions, right and left swipe gestures within about 10 percent of display edge are always grabbed by iOS and treated as a forward/back request, and not passed to the browser. Furthermore, if you’ve built back/forward behavior into your app using history push-state, then accidental swipes will load the previous state as if it was a prior web-site. This will probably be unexpected behavior. Chrome for Android was the first browser to introduce this behavior, but has now removed it based on feedback from web developers. We hope Apple follows suit quickly.

In our own testing, we discovered a number of additional bugs in the iOS 7 runtime.

  • On iPad, an orientation change when an input is focused shifts content unpredictably, and causes screen rendering artifacts.
  • Launching and quitting the same home screen app several times can hard lock the device requiring a hardware reboot.
  • requestAnimationFrame animations do not appear to background correctly, and cause performance degradation in RAF animations on the active page. This defeats one of the major purposes of using RAF animations.
  • On iPad, if the document body is set to 100 percent height, content is shifted upwards by 20px in landscape mode. This can be worked around by calling window.scrollTo(0, 0) on the orientationchange event.
  • In certain cases, resizing a composited layer (an element with 3D transform) does not repaint it correctly. Instead, the cached bitmap is stretched.
  • CSS Animations will sometimes fire before implicit z-indexes have been calculated, resulting in incorrect z layering during an animation.
  • Scripts running within Web Workers are not suspended unless either the originating page is explicitly killed, or the Safari process is explicitly terminated. Neither switching to another tab, nor minimizing Safari, nor turning off the screen seem to stop Worker execution. This is a serious issue that allows any web page to drain the battery of an iOS 7 device and slow down performance of the whole system without a user alert.

Performance Characteristics

In addition to feature/bug testing, we also put iOS 7 through a battery of our standard performance tests on an iPhone 5 running iOS 6.1 vs. iOS 7. There are some remarkable increases in benchmark performance as well as some very notable misses. First up, we want to note that something odd has happened to the JavaScript timer on iOS 7. In previous versions, iOS had an exceptionally well implemented timer: 4ms with extremely good consistency (see below). But using John Resig’s standard timer test resulted in this odd profile: a timer that jumps between 4ms and 12ms with clockwork regularity and much more noise than iOS 6.

iOS7 timer

Figure 1A: JavaScript timer resolution: iPhone 5/iOS 7

iOS6 timer

Figure1B: JavaScript timer resolution: iPhone 5/iOS 6

Perhaps this is a limitation of the test in some way, but it’s certainly nothing we’ve ever seen before, and one more reason to make sure that you use requestAnimationFrame for JavaScript animation.

In good news, raw JavaScript performance has increased substantially. SunSpider 1.0 is about 15% faster on iOS 7 vs iOS 6.1, and iOS 7’s Octane score is 70% better vs. iOS 6. Some Octane tests showed dramatic speed-ups: Navier-Stokes performance increased by almost 4x. By comparison, Safari on my 2 year old MacBook clocks in at 5,600 — so iOS 7 is now 50% as fast as desktop Safari on Octane! This is either some serious JIT hacking, or we also speculate that there may be some GPU offloading of general computation in iOS 7?

iOS7

Figure 2: Octane Benchmark – iPhone 5 iOS 6 vs. iOS 7 (higher is better)

But it’s not all good news on the performance front. During the iOS 7 beta, we were concerned at the very slow DOM interaction benchmarks that we were seeing from Dromaeo on iOS 7, and expected that Apple would get performance back to snuff before final release. For DOM traversal, attributes and modification, performance is now back at iOS 6 levels, which is good. However DOM Query is still 50% of iOS 6 speed. This is a major concern for the many HTML5 apps that perform high numbers of DOM queries, and this needs to be on Apple’s fix-list for its next update.

iOS7

Figure 3: Dromaeo benchmark – iOS 6 vs iOS 7 (iOS 6 = 1.00 – higher is better)

Graphics Performance

Test of Canvas performance show a minor improvement in iOS 7 — about 10% in the Fishtank test and on Mindcat microbenchmarks. But SVG is the real revelation. Thanks to a switch to a new drawing algorithm, SVG Path drawing speed has improved 200x. Yes that’s literally 200 times faster. In iOS 6, a 10,000 segment SVG path took about 11 seconds to draw. In iOS 7 that’s now 53 milliseconds. iOS is now 6x faster than the Surface RT — the previous champ at SVG drawing performance.

iOS7

Figure 4: SVG Path Drawing Benchmark (lower is better)

Other SVG capabilities experience similar speed-ups. Some SVG Filter operations now appear to be GPU accelerated — which means that meaningful filter animations are now possible on iOS. But performance is dependent on specific filters. Color transformations (Color Matrix & Color Curves) and displacementMaps are fast. Complex compositing and lighting effects are still slow.

And now the real killer. In the rush to get iOS 7 out the door, making sure SVG animation via JavaScript was fast seems to have been dropped on the floor. Animating SVG with JavaScript is now a hit or miss proposition. Animating 500 SVG circles used to be 50 fps on iOS 6. On iOS 7, the animation simply freezes after a few frames. We tried other apps that have interactive UI elements built with SVG, and we saw a similar severe performance degradation.

iOS 7: A Beta Release of Web

Given all these bugs and issues, combined with some genuine major advances, it’s hard not to interpret this as a beta release that was rushed into production for the release of the iPhone 5S. In a way, it reminds us of the Android 3 release — which was rushed into production for the Motorola Xoom tablet — with severe bugs and performance deficiencies. We’re eagerly awaiting the release of the first update for iOS 7 when we hope Apple delivers on its usual commitment to quality.

But beyond bugs, the design decisions in iOS 7 clearly privilege consumer content over business applications. We remain convinced that Enterprises that want to deploy HTML5 applications to mobile devices can’t rely on consumer browsers and need a secure and predictable mobile environment designed for business applications. iOS 7 has convinced us that more than ever that the future of HTML5 app deployment for business is Sencha Space.

20130924-iOS7.png 9 Comments   Read more

BlackBerry 10: The HTML5 Scorecard

In our last HTML5 scorecard, we took a look at the Microsoft Surface vs. the iPad gen4 and gave our nod to the iPad as the best HTML5 platform on tablets. This time, we’re putting the just launched BlackBerry Z10 running the new BlackBerry 10 OS through the test wringer. Going in, we were expecting very good things from the Z10. Last year, we gave a thumbs up to the Playbook OS2 HTML5 experience, and had good experiences with pre-release versions of the Z10 when developing Sencha Touch 2.2. So, prejudices firmly in mind, we headed out to a Best Buy and got ourselves a Z10 for scorecard testing.

In our tests, we found that the Z10 is a worthy addition to the top tier of mobile HTML5 devices that includes the iPhone 4+, the iPad gen 2/4 and the Microsoft Surface. We found solid advances in HTML5 feature implementation and very good performance in general. Most exciting to us is the support for getUserMedia(), which allows streaming video capture directly from the browser. We think BlackBerry’s UI for video capture is nicely designed. We did find a few feature glitches in our version 10.0 device that we expect to be cleaned up in the 10.1 release.

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. Since the feature scope of HTML5 is enormous, we focus on testing newer features and graphics and animation performance. We use a variety of homegrown and third party test-sites, including modernizr, html5test, html5rocks, haz.io, and in-the-wild web demos to check feature presence and correctness.

Got a great app idea, or a Sencha Touch app you want to port to the latest BlackBerry platform? Join us for the free half-day technical and highly interactive Sencha Touch on BlackBerry 10 Bootcamp led by top BlackBerry developer evangelists at SenchaCon 2013. Register today!

Device Essentials

First up, some essentials for the web developer. If you’re looking for traffic from the Z10 (or the forthcoming Q10, search for the following user agent string:

Mozilla/5.0 (BB10; Touch) AppleWebKit/537.10+ (KHTML, like Gecko)
Version/10.0.10.822 Mobile Safari/537.10+

The Z10 supports at least 10 simultaneous touches, which we gamely verified by cramming our fingers and thumbs onto the test screen. Multiple touches were very reliable up to 4 simultaneous touches: above that new touches and a move of an existing touch seemed to get a little mixed up. Since there are practically no applications that rely on more than 4 fingers on a screen, this is just fine.

In our tests, we found that the Z10 is a worthy addition to the top tier of mobile HTML5 devices that includes the iPhone 4+, the iPad gen 2/4 and the Microsoft Surface.”

Next, JavaScript timer resolution. BlackBerry has changed its default timer resolution from 17ms to 4ms in this release. This is the same interval supported by iOS and desktop browsers, so script animations paced by a setTimeout() loop will now run at the same pace (last we checked Android was still at anywhere from 4s to 17s though). The timer is a little noisy with occasional spikes to 20ms or more, so the even better news is that BB10 now supports requestAnimationFrame so animation can be smoother and more efficient.

HTML5 Features

The Z10 has a very complete set of HTML5 features, scoring 485 on the current html5test.com feature test. New this year is IndexedDB, File API, Microdata, in-browser WebGL, some new HTML5 form features, getUserMedia(), as well as support for the Ogg audio codecs Ogg Vorbis and Ogg Opus.

What deserves showcasing is the Z10’s WebGL support: it’s pretty darn good. The standard WebGL demos worked extremely well. We were excited to see the many planets animated demo running happily at 35fps. In fact, the only demo that showed any noticeable stutter was Mozilla’s animated raytracing demo.

Khronos Group’s Many Planets demo (35fps!)

In addition to WebGL, the new audio codecs played perfectly, and seamless iframes displayed correctly. We also tested getUserMedia() and it worked correctly for video capture (although audio-only is not supported yet).

On the other hand, we found some bugs in other newly implemented features. IndexedDB demos did not run correctly or crashed the browser. The W3C test page for Microdata crashed, and scoped styles did not appear to work in a minimal demo. We talked to BlackBerry, and found out that all three bugs are being investigated already and should be fixed in dot releases. Lastly and as a side note, some of the built-in HTML5 form inputs look like they were ported directly from the Playbook OS without adjustment for the smaller screen of the Z10. For example, the HTML5 color input was not sized correctly and we had to scroll within the control in order to select colors.

Graphics & Animation Performance

In real world tests, Canvas and SVG performance was respectable. Canvas color cycle was very smooth. In Microsoft’s fishbowl demo which stresses the compositor, with 50 fish sprites and the fps meter active, we got 50fps. With all effects active, the performance dropped to 20 fps. Zynga’s informal goal for casual games is 125 sprites at 60fps, so Canvas could be a little better. CSS3 animation demos worked well, handling multiple simultaneous animations smoothly and consistently. CSS filter shorthands as well as more complex SVG filters were also properly supported. We did find some SVG regressions: a problem with SVG filter light sources, malfunctioning gradient animations and a crash with David Dailey’s classic SVG floating balloon. Talking to BlackBerry, many SVG bugs are fixed and will roll out in dot releases.

Finally, we’re happy to say that BlackBerry continues to have a fantastic implementation of position: fixed, and overflow scrolling. It’s rock solid.

A Solid Upgrade to an Already Fine HTML5 Browser

With the release of BlackBerry Z10, the BlackBerry browser team once again delivers a very solid HTML5 platform. An industry leading HTML5 score, solid WebGL performance and a terrific getUserMedia implementation are the standouts for us. With the forthcoming performance and bug fixes, the Z10 has a solid shot at being the best mobile platform for HTML5 app deployment.

20130501-bbz10-blog.png No Comments   Read more

Microsoft Surface vs. the iPad gen 4: The HTML5 Scorecard



This week, we’ve been putting both the iPad gen 4 and the Microsoft Surface tablet through their paces to see how they stack up as HTML5 platforms. HTML5 is the next generation of web technologies that is increasingly being adopted to develop applications that can be written once and run on multiple operating systems, browsers and devices. Having comprehensive, high performance HTML5 support is now a “must-have” feature for new mobile devices. For end users, both these devices should deliver solid user experiences from well-designed HTML5 apps.

In our testing, we’re happy to say that both tablets are solid HTML5 platforms. The Microsoft Surface comes with Internet Explorer 10 and Windows 8 while the iPad comes with Mobile Safari and iOS 6. Internet Explorer 10 on the Surface has a broad, well implemented HTML5 feature set that mostly meets and occasionally exceeds Mobile Safari’s. On the performance front, the iPad 4 leads in JavaScript, interaction and Canvas performance: the Surface has a faster vector graphics (SVG) implementation.

Going in, we were bringing expectations set by the iPad gen 3 and our developer hardware for Windows 8. When we reviewed the iPad 3 in the Spring, we were disappointed with iPad performance. Ordinary web pages as well as HTML5 apps had stutter and visible tiling. Raw JavaScript performance was actually lower on the iPad 3 than the iPad 2. In our opinion, it was an underpowered device, so we were not entirely surprised to see the iPad 4 arrive with vastly improved hardware specs so quickly. On the Microsoft front, when we took our first look at the IE10 preview last Fall, we were very impressed with its HTML5 feature list, but wondered if performance would hold up on tablet-grade hardware. Read on to see what we found.

The Microsoft Surface

Since there are already plenty of reviews of the Surface tablet for the regular user, we won’t spend much time on its general features except to say that

  • The mixed keyboard/touch interface that Windows 8 pioneers is a winner,
  • Bezel gestures to activate control and navigation become natural quickly (but tend to activate inadvertently)
  • The integrated (and very sturdy) kickstand should become a standard tablet feature.

We’ll also note that if you plan to evaluate the Surface yourself, it’s essential to install all waiting upgrades including the pre-installed Office Preview. Before upgrading, entering text was absurdly and unpredictably laggy not just in Office, but also in browser-based input fields.

If you’re looking for Surface traffic, its user agent is: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; ARM; Trident/6.0; Touch)

The Surface supports multi-touch, with up to five separately tracked simultaneous touches. Its JavaScript timer resolution is the Windows standard 16ms (or 64 ticks per second) when on battery power. When plugged in, the timer jumps to what appears to be a 4ms resolution (the same as iOS and Chrome for Android), but the timer became so noisy at this resolution that it was hard to establish exactly what the resolution was supposed to be. As we’ve noted before, JavaScript animations that use a setTimeout of zero to pace their progress will now run faster or slower depending on whether the Surface is plugged in or not. Using explicit time or requestAnimationFrame for JavaScript animation is once again highly recommended.

IE10 has a new collection of CSS properties and events to control touch event handling. All HTML5 apps (and web pages to boot) will want to use the ms-touch-action: none, to suppress OS pre-emption of touch events within their app. WebKit style touchstart, touchend etc. are not available. Instead we have Microsoft’s new pointerEvents, which unifies mouse and touch events under one roof. This makes use of a gesture abstraction library or a full framework pretty much essential for building cross-platform web apps. The Surface has a rock-solid implementation of position: fixed, and even makes a jittery attempt at supporting background-attachment: fixed — which Mobile Safari still ignores.

HTML5 feature coverage

We tested HTML5 feature presence using Modernizr. IE10 on the Surface has a long list of HTML5 features. This includes indexedDB, CSS animations, 2D and 3D transforms, gradients, transitions, workers, websockets, video and audio playback, and file API. Leapfrogging the iPad 4, IE10 even has a *-implementation of CSS Regions and Exclusions — which we think is a first for a shipping mobile HTML5 browser. Grid layout — which looks to be a permanent IE-only feature is also supported.

There are some notable omissions and deficiencies compared to the iPad 4. There is no support for the input tag for camera or video capture (introduced in iOS 6), the flexbox implementation is the older, superseded version. There is no border-image support (admittedly the border-image support in mobile Safari is not completely correct either.)

Neither platform supports WebGL, but Microsoft has previously said that it won’t support it. Nor were the more esoteric HTML5 inputs like color supported. Notifications and server sent events were likewise absent from both platforms.

JavaScript Performance

We ran both the iPad 4 and the Surface through Sunspider and Google’s V8 benchmark. Although Sunspider is an imperfect test, it has great historical comparability. The figure below shows the performance of the Surface and iPad 4 indexed to the iPad 2 = 1.0. As can be seen, raw JavaScript performance on both platforms is roughly 2x the iPad 2. The iPad 4 has a performance advantage with an average 20% performance edge over than the Surface. On version 7 of the V8 benchmark, the performance difference was more stark. The iPad 4 clocked in at 1565 vs. 775 for the Surface (higher is better), a 2x advantage for the iPad.

We should also note that if you’re running an app in a UIWebView on iPad 4, you’ll experience a dramatically slower JavaScript experience thanks to the pre-Nitro engine — about 30% of the speed in Mobile Safari.

SVG Support and Performance

Since IE10 has a hardware-accelerated SVG implementation, we decided to dig into performance for SVG. First, we ran David Dailey’s decahedra demo which combines rotating and overlapping shapes with SVG gradient animations. The Surface comfortably handled an entire screenful of 50 shapes with solid performance. In comparison, the iPad 4 started to show visible frame transitions at around 15 shapes. A more dynamic pseudo 3D corridor navigation game, reached approximately 18 fps on the Surface vs. 12 fps on the iPad 4.

The SVG implementation in IE10 on the Surface is rich with a full complement of SVG features. It’s fantastic, for example, to see broad support for SVG filter effects like color channel manipulation. We did notice a few minor blemishes. The performance of the lighting effects we tried was very poor (10s+) and the feSpotlight primitive was not supported. Lighting effects were noticeably darker than the reference SVG test images. And although Modernizr reported SMIL support, we were unable to get any declarative SVG animation to run successfully. SVG Filter effects are also imperfect on Mobile Safari, and anyone looking to use them should expect vigorous testing and cross-browser normalization.

Canvas Performance


The Microsoft Surface and the iPad 4 now join the iPad 2 and the RIM Playbook 2 as impressive HTML5 tablet platforms.

Raw canvas benchmarks like this one from mindcat showed the iPad 4 with about a 2x advantage over the Surface. In our benchmark, the iPad 4 scored 1.81 vs. the Surface’s 0.90. In a variety of Canvas test apps we saw perfectly acceptable performance from the Surface. This included canvas color cycling (once guaranteed to bring a mobile browser to its knees) as well as a variety of Impactjs-based games. On the other hand, the Craftymind videos that pull and manipulate video frames using Canvas worked smoothly only on the Surface. The iPad 4 showed no video playback at all. Other demos combining Canvas and Video worked perfectly on the Surface, but also did not work on iPad.

Beyond test apps, Microsoft’s own fishbowl demo seemed to be a good stress test of real world Canvas use. This demo composites multiple separate canvas contexts together on top of a background video, with sound effects in a separate audio element. There are also CSS transforms and CSS opacities present. With all effects disabled except basic sprite animation, the Surface managed about 110 concurrent sprite animations at 60fps, while the iPad 4 managed about 135. Strikingly, when we enabled more effects (masks, background, shadows and more.), the iPad 4 held up well while the Surface struggled. With all effects enabled except the background water video, shadow effect and audio, the iPad 4 could support about 100 concurrent sprite animations at 60fps, whereas the Surface was able to support only 10. Canvas compositing appears to be a particularly challenging graphics operation for the Surface vs the iPad.

CSS, DOM and Other Performance

Early mobile platforms had issues with CSS performance, but we saw good CSS performance with transition and animation effects. Although we had to hack together a non-Webkit version, our boat rocking CSS animation which combines 5+ concurrent animations was smooth and jitter free. Anti-aliasing of transformed edges (a notable problem for desktop Chrome) was quite good on both platforms although there is still a little work still to do. Gradients on both platforms were smooth and free of banding. Video playback was also trouble free.

Finally, on the DOM Interaction and CSS Selectors portions of the dromaeo benchmark, the iPad 4 simply crushed the Surface. For some time, Webkit has had a speed advantage over IE’s engine in DOM manipulation, but it’s shocking how wide the performance gap remains. Although DOM interactions are typically a small part of application time, expect some performance penalty from this source in highly dynamic applications.

(higher is better) iPad gen 4 Surface iPad Advantage
DOM Attributes 161.84 37.5 4.3 x
DOM Modification 136.5 13.9 9.8 x
DOM Query 4560.0 356.6 12.8 x
DOM Traversal 138.3 4.9 28.2 x
CSS Selector (Avg) 1654.7 458.7 3.5 x

An Embarrassment of Tablet Riches

The Microsoft Surface and the iPad 4 now join the iPad 2 and the RIM Playbook 2 as impressive HTML5 tablet platforms. Both are a big improvement over the iPad 2 — the previous best tablet for HTML5 apps. It’s also very encouraging to see Microsoft stepping up to the plate and delivering an HTML5 implementation that’s comprehensive and performant. There’s still work remaining of course. It would be nice to see SVG from both companies with native graphics performance in their next generation tablets. And getting camera and video access from a web page is a notable item on the Surface’s to-do list. We’re looking forward to reviewing the upcoming Surface Pro tablets with higher powered Intel processors.

SUMMARY FINDINGS Apple iPad (gen 4) Microsoft Surface (WinRT)
JavaScript Performance Excellent (2x iPad 2) Good (1–2x iPad 2)
DOM & CSS Interaction Excellent Poor
Graphics & Fonts Good (no webgl, svg perf -) Good (no webgl, SMIL)
Audio & Video Fair (limited manipulation) Good
CSS3 Styling Excellent Excellent
CSS3 Position & Layout Good (no grid) Good (old flexbox)
CSS Animations Excellent Excellent
Input & Semantic Elements Excellent Excellent
Multi-Touch Excellent (10 touch points) Good (5 touch points)
Timer Resolution Excellent (4ms) Good (16ms)
Database, File & Workers Fair (no IndexedDB) Good (no WebSQL)
Communications Good Good
Device access Good (no streaming) Poor (geo only)
Experimental features Poor Fair (Regions & Exclusions)
20121119-surface-vs-ipad-preview.png 11 Comments   Read more

A Survey of JavaScript Timers on Mobile

It wasn’t too long ago that web developers were struggling with poor implementations of JavaScript timers in desktop browsers. John Resig’s survey of desktop browser timers at the end of 2007 showed serious problems with timer resolution and/or timer consistency on all tested browsers. The practical effect of this was that JavaScript animations could run at different rates in each browser, choke up when too many concurrent timers were active, and often display stutter and jerkiness. (For more background on how timer resolution affects the user experience (and why we need a special Animation timer), Nicholas Zakas blog post on JavaScript animation is quite helpful.)

Chrome 1.0 was the first to introduce a high resolution, deadly consistent JavaScript timer platform.”

Since then, JavaScript timers on desktop browsers have improved vastly. Chrome 1.0 was the first to introduce a high resolution, deadly consistent JavaScript timer. This was soon matched by other browsers, and as a result, web developers have become used to respectable performance from JavaScript animations in desktop browsers. The most recent version of every major browser except IE has a 4ms timer with very good consistency even as the number of concurrent timers gets larger than 100. Internet Explorer before Windows 7/IE9 used the low resolution system timer as its JavaScript timer – which gave a 15.6ms timer resolution. This changed in Windows 7, which now offers two different resolutions, the old 16ms timer when your device is in power-saving mode and a new 4/5ms timer when in normal mode. (This configuration can be changed in advanced power options.)

Chrome 20

Firefox 12

Figure 1: Chrome 20 and Firefox 12 have high resolution, scalable and consistent timer implementations

JavaScript Animation on Mobile

However, mobile browsers have been a different story. The conventional wisdom has been that JavaScript animations on mobile can suffer from stutter and synchronization problems. This is one of the reasons that CSS Transforms and Animations have become a popular way to perform mobile animations since content movement is performed in hardware by the GPU and gets the benefit of sub-pixel tweening. However, there hasn’t been much written about mobile timers, so we decided to do a semi-scientific study of timer performance by running John Resig’s timer test on 20 or so of our mobile test lab devices. The test animates a pixel using setInterval() at 0ms timeout at various levels of concurrency and call stack depth. We tested devices running iOS3 through iOS5 on iPhones, iPads and iPods, Android 2.2 through 4.1 on Samsung, LG, HTC, Huawei and Motorola devices, as well as the RIM Playbook 1 and 2. Here’s what we found:

Timer Resolutions

Most mobile devices we tested had timers set at 10ms resolution. This was the case for the vast majority of Android devices, as well as devices running iOS3 and iOS4. Chrome for Android and iOS5 had faster timers: their timer resolution was 4ms. And the Blackberry Playbook 2 had the slowest timer: approximately 17ms. One outlier for the Android browser was the Motorola Droid 2 Global which had a timer resolution of 16ms. Finally, when we ran the timer test on our “straight-from-Google-IO” Nexus 7 tablet running Android 4.1 and Chrome for Android, we got an odd result which showed the timer whipsawing from 4ms to 10ms. (This may due to some webkit behavior that backs the timer off to 10ms, if it’s already processing a timer callback, but would love to see if anyone from the Chrome team has insight on this.)

In other words, the most recent devices running Android 4, Chrome for Android and iOS5 have desktop-class timer resolutions, while older Androids and RIM devices have timers that are 2x to 4x coarser grained.

Timer Consistency and Scalability

Next we looked at the variability of the timer measurements at various levels of timer concurrency and stack depth. The ideal performance result is a horizontal line at the y coordinate of the timer resolution—whatever that is. Here the results were a little varied.

Our star performers were the iPhone and iPad2 (below left), as well as the Motorola Xoom running the stock Android ICS browser (below right). Each were highly consistent at their respective timer resolutions of 4ms and 10ms, with no deterioration as the number of timers increased, and just one or two spikes. Other notable performers were Chrome for Android on the Motorola Xoom and one of our Samsung Android 2.3 devices.

iPad2 running iOS5

Motorola Xoom running Android ICS

More typical, however was a drift of anywhere from -5ms to +10ms around the expected timer resolution, particularly when the number of concurrent timers exceeded 8. This was true across all Android handset makers and all versions of Android 2. The typical result from an Android 2.x device looked something the example below—in this case, a Samsung phone running Android 2.3.5.


A Samsung phone running Android Gingerbread


Finally our worst performing devices. Surprisingly, one of these was from Apple. While all our iPods had noisy performance graphs, our iPod/iOS5 was particularly poor—with a few spikes that were literally off the chart. We also found the Playbook 2 timer to be extremely noisy, regularly spiking to 2x the 18ms timer resolution.

iPod running iOS5

Blackberry Playbook running Blackberry OS

Lessons learned and conclusions drawn

Our survey of mobile timers shows mostly good news. The most recent mobile browsers on Android—both stock Android and Chrome for Android now have desktop quality timers. Surprisingly, it doesn’t look like Apple is taking particular care to achieve good performance on the iPod browser. For highest performance on iOS, this probably means it’s best to stick with GPU-accelerated 3D transforms for the moment. It also reiterates the need for wide adoption of the work-in-progress animation timing spec.

20120712_survey-javascript-timers.png 1 Comment   Read more

HTML5 Scorecard: RIM BlackBerry PlayBook OS 2.0

20120426-blackberry-playbook-sm Last month, RIM released OS 2.0 for the BlackBerry PlayBook. We were already very impressed with the PlayBook 1.0 browser, and we were anticipating more, new and better. We put it through our HTML5 test wringer, and were pleased to find that the PlayBook 2.0 browser is an excellent upgrade, adding new features and upgraded performance in several areas. Notably, it features the first HTML5 color picker input type that we’ve seen on mobile, advanced SVG filters as well as a perfect Acid 3 score.

The original Blackberry PlayBook browser, released this time last year, was already a very solid HTML5 browser. In our original PlayBook HTML5 scorecard, we noted that it was far superior to the Android 3 browser and overall, an excellent HTML5 platform. We were particularly impressed with the quality of its SVG, Canvas and CSS3 Animation implementations. In this review, we’ll mostly concentrate on what’s new and improved.

In our original BlackBerry PlayBook HTML5 scorecard, we noted that it was far superior to the Android 3 browser and overall, an excellent HTML5 platform.”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in an number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. We also use a variety of homegrown and third party test-sites, including Modernizr, Acid3, and our own Sencha Animator demos and Sencha Touch Kitchen Sink.

### Device Essentials

But first up, some essentials for the web developer. If you’re looking for traffic from the PlayBook OS 2, search for the following user agent string:

Mozilla/5.0 (PlayBook; U; RIM tablet OS 2.0.0; en-US) Apple/Webkit/535.1+ (KHTML, like Gecko) Version/7.2.0.0 Safari/535.1)

The PlayBook OS 2 supports up to 4 simultaneous touches, so interactions that rely on two simultaneous pinch/zooms are possible.

Next, JavaScript timer resolution. We’ve been looking at timer resolution on mobile lately and it can vary widely by device. For example, iOS 5.1 currently has a 4ms timer resolution with high consistency, Android 4 has a 10ms timer with low consistency. In contrast, the PlayBook 2.0 appears to have a 17ms timer. This means that script animations paced by a `setTimeout()` loop will run about 4x slower on the PlayBook 2 by default; a good reason to use explicit time in your web animations whether via JavaScript or time-based CSS3 animation. The PlayBook 2 browser doesn’t yet support the relatively new requestAnimationFrame API. For developers looking to use requestAnimationFrame cross-browser, we suggest that you use a polyfill to get the advantages of requestAnimationFrame when you can.

Perfect 100/100 Acid3 Test in the BlackBerry PlayBook OS 2 browser

Perfect 100/100 Acid3 Test in the BlackBerry PlayBook OS 2 browser

### Acid3 and Feature Detection

Just like the original PlayBook, the PlayBook OS 2 has a perfect Acid 3 score, with no rendering artifacts. Our favorite modernizr check sites, haz.io and HTML5Test report a very complete set of HTML5 features, including 3D transforms, HTML5 audio and video, web sockets, workers, web intents, SMIL, SVG and WebGL. What’s particularly nice to see is an almost complete implementation of HTML5 input types such as color picker and time.

Some minor missing features from the modernizr feature check: File API support, background-repeat, and IndexedDB. Since the only implementation of IndexedDB on major mobile platforms is the beta of Chrome for Android, this is not a very surprising omission (and WebSQL is still available anyway).

However, as we’ve noted before, just because a feature is detected, it doesn’t mean it’s working. WebGL, for example, won’t execute in a normal browser page on the PlayBook OS 2, and only activates when used in a WebWorks hybrid application. Similarly, some of the HTML5 input elements exist but you probably wouldn’t use them in their default style. For example, the time input has the unsettling habit of rewinding back to 0 when you spin past the highest value rather than looping. The color picker, while functional, is probably too spartan for use in a consumer application.

SVG Filters in the BlackBerry PlayBook OS 2 browser

SVG Filters in the BlackBerry PlayBook OS 2 browser

### Graphics Performance

In real world tests, Canvas and SVG performance was excellent, even on stressful demos like Canvas color cycle and the classic SVG floating balloon. CSS Animation performance was equally excellent. The only graphics effect we could see missing was robust support for image slicing in `border-image`. But no WebKit browser supports this feature properly yet, with the exception of recent desktop Chromes. We’re happy to report that the PlayBook 2 also has an excellent implementation of advanced SVG filters–morphology, diffuse lighting, specular lighting, custom composition filters–they’re all here. As with desktop browsers, it’s not possible yet to animate filters at an acceptable FPS, but even having static filters of this sophistication is an amazing advance for web developers everywhere. Instagram-like image effects are now available for anyone with the two to three days it takes to learn the physics and syntax of SVG filters.

Here is a screenshot from the PlayBook 2.0 of a morphology filter (from IE10’s SVG Filter demo page.)

The code for this is simple:



Just like in the original PlayBook, Sencha Animator CSS3 Animation demos work very well, handling multiple simultaneous animations smoothly and consistently.

We’re also happy to say that the PlayBook OS 2 has a rock solid implementation of `position: fixed`. Even with the fastest scrolling, we were unable to dislodge fixed content from its place on screen. `overflow: scroll` and `overflow: auto` also work smoothly (with one fingered scrolling vs. iOS’s two fingered scroll).

### Removal of Non-Standards Track Features

A last note–in a move that’s guaranteed to make anti-prefixers happy, the PlayBook OS 2 browser has removed support for `-webkit-mask`. CSS masks are very handy but have been hanging out as a WebKit only feature for nigh on four years. Although there is a new standards draft for filters and effects that aims to regularize this feature, since other engines do not appear to be on track to support the feature (Gecko wants you to use SVG masks instead), it’s probably a good idea to remove any critical dependencies on masks if you want your app to work cross platform in the future.

20120426-blackberry-playbook-2-badge

### A Very Fine HTML5 Browser

With the release of BlackBerry PlayBook OS 2, the RIM browser team once again delivers a high performance and up-to-date HTML5 platform for web app developers. For businesses that want to bet on a stable, state of the art device for HTML5 applications, the BlackBerry PlayBook with OS 2 is an excellent choice.

20120426-blackberry-playbook-thumb.png 12 Comments   Read more

HTML5 Scorecard: The New iPad and iOS 5.1 — A Mixed Bag

Apple iPad, 3rd generation

Apple’s new iPad has a beautiful screen, but often struggles to smoothly display and scale even average webpages.

This month, Apple released the “new iPad”, its newest and latest tablet device, featuring a high resolution “Retina Display”, an updated CPU and GPU and more memory. A few weeks before the launch of the iPad, Apple also released iOS 5.1, a mostly maintenance release that included fixes for battery life among various others. 61% of devices are now upgraded to iOS 5.1.

Our HTML5 scorecard typically focuses on what HTML5 developers need to consider when developing for a platform or mobile operating system. Both the new iPad and iOS 5.1 are significant updates in the Apple ecosystem. In this HTML5 scorecard, we’ll look at them independently, explore a few of the issues we found and give developers some guidance on how to work both the new iPad and with iOS 5.1.

In a nutshell, the new iPad is a mixed bag. The new iPad’s display is incredibly fine grained and web site text now appears unbelievably sharp. On the other hand, the browser experience is noticeably slower with stutters and redraws on complex web pages and web apps. Images that haven’t been updated for retina displays now appear blurry in contrast to the sharp text. iOS 5.1 doesn’t offer many new features, and it does take a step backwards. For hybrid apps (web apps packaged in a native shell), iOS 5.1 breaks localStorage and WebSQL persistence, so developers can’t rely on them anymore.

### iOS 5.1

As has been widely reported by web developers, iOS 5.1 has changed the behavior of an embedded WebView. WebViews power HTML5 applications that live inside of native packages, such as PhoneGap or Sencha Touch native packaging. They provide an embedded web browser that is hosted within a native application, permitting the distribution of web apps to native app stores. WebViews are a feature of all modern mobile operating systems.

Prior to iOS 5.1, when an embedded WebView was used, data stored locally using HTML5 storage was kept persistent. Specifically, if your application used localStorage or WebSQL, it was considered part of the application’s data. When a new version of the app was installed or the app was hard-closed, the persistent data was kept around. The next time the app started, the localStorage would appear as if it had never gone away, exactly as what happens in Mobile Safari.

In iOS 5.1, this data is no longer considered persistent and is treated as temporary or transitory data, so iOS can destroy it at any time, without warning, including during low memory scenarios. This is probably because Apple can’t reliably iCloud backup, or iCloud sync from anything that’s not stored in the native CoreData storage. As such, they’re pushing developers to move to Apple native data systems to make apps iCloud-ready. Of course not everybody will want to do this. For developers who relied on localStorage or WebSQL as their mechanism to store data in their app, breaking this mechanism is a big deal. There are various workarounds, such as using the PhoneGap-SQLPlugin which uses the underlying SQLite, or writing your own JavaScript bridge to CoreData.

We also poked around iOS 5.1 to see if there were new HTML5 features like CSS regions or support for the File API or any other new web platform features. We used our favorite tool, haz.io which builds on the open source Modernizr detection library to see what’s new under the hood. In short: nothing. No new features showed up between iOS 5.0 and iOS 5.1. iOS still features some of the best HTML5 support on any mobile browser, but this latest incarnation hasn’t increased the depth of Mobile Safari’s support for the standards. We’re hoping to see CSS Regions come to iOS soon, as it’s supported in Safari 6. Mobile Safari reports “5.1” as its version number, so it’s likely only a matter of time until we get the ability to use the Regions feature. We were also looking to see if WebGL, which is currently only available for Apple iAds, is available in the public browser. haz.io reports that WebGL is supported in Mobile Safari, but when we used the Khronos demo repository to test, we were unable to get any of the demos to work.

For the HTML5 developer out there, heed the warnings when using localStorage or WebSQL in a packaged app on iOS 5.1, and don’t expect any new HTML5 features in iOS5.1 Mobile Safari.

### Retina iPad

For HTML5 developers, the most obvious thing about the Retina Display iPad is the huge number of pixels that the device now manages. The new iPad sports a resolution higher than a 1080p television. User interfaces are doing more than 4x the work pushing all the new pixels around. The new iPad houses an Apple A5X CPU together with a PowerVR SGX543MP2. The A5X is a dual core ARM-Cortex A9 design, running at 1GHz, and the GPU is a quad-core design running in roughly the same graphics class as the Nvidia Tegra line. From what we can tell, the main difference between the A5 (which powers the iPad 2 and the iPhone 4S) and the A5X is the new quad-core GPU. Given the new pixel density, it stands to reason that it’s the most upgraded component of the new iPad’s processing subsystem.

Since we’re focusing on HTML5 developers, we focus on web benchmarks for performance. We re-ran the iPad 2 with iOS 5.1 along with the new iPad with iOS 5.1 and found a set of interesting results. As usual, we turned to SunSpider and the V8 Benchmark Suite for raw JavaScript processing power. We found (and perhaps given the new display’s tax on the whole system this is unsurprising) that new iPad was marginally slower than the iPad 2. The SunSpider score is about 150 points slower than the iPad 2, and the V8 Benchmark was 45 points slower. We ran the tests a few times and while the specific numbers were a bit different each time the overall result was the same: on pure JavaScript processing, the new iPad is slower than the iPad 2.

SunSpider Results

SunSpider v0.91 Results, smaller is better.
Benchmark

V8 Benchmark Suite v6, bigger is better.

We then turned our attention to some complex web sites and apps to see how the new iPad performed with graphics. We turned to our Sencha Animator Kickfu demo, which is a very complex CSS3 animation, and were pleased that it ran reasonably well. Wanting to push it a bit further, we decided to pinch-zoom in and try to play the game again and this time we saw an immense amount of tiling occurring. This severe tiling seems to have been introduced in iOS 5, so it’s not a new iPad thing, but definitely an artifact introduced in newer iOS’ that hasn’t gotten better with new hardware.

Our tests always include Canvas, and we tested our two current favorite Canvas apps, Canvas Rider and Canvas Cycle. Both of them test the CPU/GPU and the browser’s Canvas drawing engine. The new iPad does fine here, rendering both of these examples with the same performance as the iPad 2. Given how fast the iPad 2 is, it’s impossible to visually discern any difference in Canvas performance between the two devices.

In general web browsing, we did notice one notable difference between the iPad 2 and the new iPad. It draws much more slowly on complex pages. For example, on the Ext JS examples page, when scrolling the page, it visibly loads in new tiles at the bottom of the page while moving. Also, when zooming in on image rich pages such as our Sencha Touch 2 product page, the same tiling behavior occurs again that rarely occurred on the iPad 2. It’s clear that this is due to the the new Retina Display. It’s very likely that images and other assets being transferred to the GPU are taking more time (and bus bandwidth) than the device can handle in real time.

We’re definitely not hardware or chip experts here, but we figured we’d dig a little with the iFixit breakdowns to see why this might happen and if were parts on the new iPad that were not upgraded to match the new resolution. The iPad 2 uses an Apple A5 System on a Chip, which includes 512 MB of DDR2 RAM in the SoC package. Compare that to the new iPad which has an A5X SoC, which does not include the memory in the SoC package. Rather there are two 512 MB Elpida DDR2 chips. The new iPad has two times the memory, and four times the pixels to push, but runs the memory bus at the same speed as the iPad 2. Again, we’re not experts on embedded systems design, but it stands to reason that some of the graphics performance issues we are seeing, (especially tiling and performance degradation from box shadows) might be caused by this system imbalance.

### The New iPad and iOS 5.1: tips for the HTML5 developers

We’re usually effusive about the latest mobile browser and hardware from Apple. But this latest offering is a mixed bag at best and a disappointment at worst. For the last few years, we’ve grown accustomed to Apple leapfrogging the competition each year with superior hardware and even better HTML5 browser software. The latest set of Apple hardware has regressions compared to the iPad 2 including slower JavaScript performance. And with iOS 5.1, the removal (or breaking) of features that developers have trusted is a real letdown. While we believe that the iPad is still the best tablet in the market, it’s the first time a new Apple product hasn’t categorically outshone its predecessor. Particularly for business applications, there is no reason to choose the new iPad over the iPad 2.

20120327-ios-5-1-scorecard-thumb.jpg 19 Comments   Read more

HTML5 Scorecard: Chrome for Android Beta

Sencha HTML5 Developer Scorecard of Chrome for Android beta

Chrome for Android icon As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the new Chrome for Android mobile browser beta. There have been rumors of Chrome for Android for quite some time, and we were encouraged but a little underwhelmed by the stock Android 4 browser. We were hoping that there was more to come.

And we didn’t have to wait long. After testing Chrome for Android, we’re happy to say that it’s a very solid HTML5 browser, and even in its beta form, is a “must-install” for any Android 4 owner. Hopefully Chrome for Android quickly becomes the *only* browser for Android 4.

bq(pullquote right). If you own an Android 4, there is no question you should download and use Chrome Mobile beta as your primary browser.”

h3. Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

Chrome for Android scores a perfect 100/100 on the Acid3 test, just like the Android 4 browser. However, the tell tale rendering artifact (a very faint red/pink box in the upper right corner) that has marred a perfect score on other Android browsers, once again rears its head. (Chrome Desktop doesn’t have this artifact, so perhaps this is an OS/graphics stack issue rather than a browser problem). In practice, this won’t impact web browsing or web development much, but it would be nice to fix this for the final release.

Next up, Modernizr! Once again, we used haz.io which is a clean and mobile friendly Modernizr checker. The verdict? High marks on HTML5 support — as one might expect from the folks who brought you Chrome. Once again, the browser does have @font-face support — Google Fonts display perfectly — but TypeKit does not yet detect Chrome for Android correctly. As with the original Playbook, and Android 4 stock browser support, Typekit has a lag between first ship and support, but I’m sure the Typekit folks are on top of this.

Compared to the stock Android 4 browser, there is a substantial number of additional HTML5 features: Web Workers, Web Sockets, HTML5 Input Types, overflow: scroll, requestAnimationFrame and more. That’s not to say that Chrome for Android has absolutely everything. As detected by the other handy testing site for HTML5, many newer features are absent, notably Shared Workers and WebGL. The video codec cold war also continues: Ogg Theora and Ogg Vorbis support is still not there — which is not a surprise.


Chrome for Android running on a tablet and phone

Chrome for Android running on a tablet and phone

h3. Performance

For performance benchmarking, we use SunSpider. In the last 9 months, all the mobile browsers have converged at basically the same SunSpider performance levels. This also holds true for Chrome for Android. Although it’s slightly faster on one or two tests vs. Android 4 browser, it’s in the same general ballpark, which is not too surprising since they’re both using the V8 engine on the same hardware. Since Chrome for Android is visually much faster and smoother than the Android stock browser, this is probably a good time to consider putting SunSpider on the shelf as a good predictor of user-perceived performance.

h3. Real World Tests

As we’ve said many times previously, many mobile browsers do well on the checkbox tests like Modernizr, but fall short when it comes to real world applications and content. (In some cases, mobile browsers have even reported support when none exists.) So for real world testing, we use a collection of our own favorite HTML5 sites and demos.

First up, the new CSS properties for mobile content. On our HTML5 wish list for 2011 we asked for high performance position: fixed. And Chrome for Android delivers. For simple pages, Chrome for Android does a top notch job of glueing fixed position content to the screen. Fixed headers and footers for simple mobile optimized pages are now easily implemented without having to use a framework. However, the browser struggled when trying to maintain fixed positioning on more complex pages, particularly when combined with pinch/zoom. We saw poor frame rates and occasionally content disappeared or was misplaced. Happily, the *very new* @-webkit-overflow-scrolling: touch@ property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (Nice job Chrome team!)

On to SVG. On Chrome mobile, basic SVG worked very nicely. Our Raphael vector demos were very smooth, and many other SVG effects like text on a path, and animated gradients worked smoothly at a good frame rate. For more advanced effects (demos at David Dailey’s page), there’s still work to be done: SVG effects like complex filtering were either not supported or ran at low frame rates. Since there is little popular content that relies on these advanced effects yet, this is not such a big deal. However, when CSS Filters start to percolate into general usage, getting these right will become more important.

We next tried Canvas and here Chrome for Android has a good implementation. Basic Canvas drawing is unproblematic, and our favorite Canvas stressor — Canvas Color Cycling was smooth and high performance even under pinch/zoom. The most complex demos we could find (that can cause even desktops to pause), such as the demos at Mr. Doob did cause some problems — with long wait times and occasional complete display failures.

Our testing of embedded HTML5 audio and video went well. Plain inline HTML5 video works, (although don’t try to combine it with other effects or Canvas). This is an area where Chrome Beta has the advantage over iOS 5 which still lacks inline video playback.

Finally, we took a look at CSS3 Animations & Transforms. This is an area that we’ve invested in here at Sencha with Sencha Animator. Poor Android performance on 3D transforms has been a limitation on the complexity of CSS animations that can deploy cross platform. Our most complex animation — our Sencha Animator KickFu game — was playable, but the frame rate was too low for a smooth experience — I’d estimate a 5-10 frames per second performance. More basic CSS3 animations — even 3D ones — worked well, although we did uncover our first official bug for the Chrome team which we will be filing — transformed elements seem to drop border-radius. In addition, there are a few layout quirks that are present in desktop Chrome for transformed elements that also show up in Mobile Chrome.

h3. Sencha Touch 1.0 Kitchen Sink

Although we’re in late beta with Sencha Touch 2, we decided to test Sencha Touch 1.1 instead. Compared to Android 4, the Chrome for Android experience is vastly improved. Full-screen flashes and screen flicker are absent. Other things that we take for granted such as smooth border radii, masking etc. are also well implemented. But it’s also true that some of the browser properties that we rely on for layout in Android are now different in Chrome Beta and these result in minor artifacts in layout and list scrolling that we’ll need to be address.

h3. Chrome for Android beta: tips for the HTML5 developer

Chrome for Android is a big leap forward for web browsing on Android devices — even in its beta form. We suspect that many of the browser limitations are limitations more of the device processors than the browser itself. There is still work to be done before general release, but in all we’re very happy to have a top notch browser for Android. If you own an Android 4, there is no question you should download and use Chrome for Android as your primary browser as soon as you are able.

20120209-chrome-for-android-thumb.png 14 Comments   Read more

Android–Ice Cream Sandwich: The HTML5 Developer Scorecard

Samsung Galaxy Nexus

As part of our continuing series, we ran the new Galaxy Nexus through our tests to see how it stacks up as an HTML5 app platform.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the Samsung Galaxy Nexus, the first device to ship with Android 4.0, aka Ice Cream Sandwich. We’ve been hearing rumors over the last few months about the “involvement”:http://androidandme.com/2011/10/news/google-chrome-is-finally-coming-to-an-android-device-near-you/ of the Chrome team in Android 4, so we had our hopes up that the browser would be a major step forward. In the past, we’ve reviewed Android 2.x (Gingerbread) devices, like the “Galaxy Tab”:http://www.sencha.com/blog/samsung-galaxy-android-tablet-the-html5-developer-scorecard/ and Android 3 (Honeycomb) devices, and the “Motorola Xoom”:http://www.sencha.com/blog/motorola-xoom-the-html5-developer-scorecard/ –and have been disappointed by the performance and correctness of the browsers.

Ice Cream Sandwich is a major step forward for the Android Browser, but still falls short of iOS 5.”

After putting the Galaxy Nexus through our test wringer, we can say that Ice Cream Sandwich is a major step for the Android browser. However, it still falls short of iOS 5. It’s a solid browser for normal page browsing and it adds major new features that support most of the HTML5 spec. It also has taken a big step forward in correctness of rendering, which is a welcome change for people who want to push their mobile browsers to the limit.

h3. Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

The Galaxy Nexus scores a perfect 100/100 on the Acid3 test, just like Android 3. However, a close look at the Acid3 results reveals that there are still rendering artifacts. In the top right of the test image there is a telltale faint red/pink box which should not be there, since Acid3 requires pixel-for-pixel of the reference image. In practice, this won’t impact web browsing or web development much, but it’s a bit of fit-and-finish that “we’re not quite there yet” on Android.

We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. This time, we used the implementation of Modernizr on haz.io which provides a clean and easy way to look at Modernizer results. The verdict? Ice Cream Sandwich offers very good HTML5 support! Font-face, geo-location, and full support for the CSS3 suite. Support for the various CSS3 effects is probably what we’re most excited about: animations, reflections, 2D and 3D transformations, as well as transitions are all supported. For web developers, you can finally rely on HTML5 in Android 4.0 to build rich user interfaces. We do note that with @font-face support, the device does in fact support it, but TypeKit does not yet detect it correctly. As with Playbook support, Typekit usually has a lag between first ship and support, so don’t be discouraged just because your TypeKit web fonts don’t work yet.

With all the good news, there were features missing. Things of note that were absent from Ice Cream Sandwich were Web Workers, Web Sockets (so no real-time web on Android just yet), weak support for the new Input Types (like datetime or range), and WebGL. SVG was fully supported. We also decided do a head-to-head between iOS 5 and Android 4 on HTML5 support, and extracted some notable differences between the two platforms. This list isn’t comprehensive, but it shows some gotchas for web devs. Developers should use this guide to decide which APIs to take advantage of on a specific platform, or if they want to stick to the common set.

Feature Android 4 iOS 5
overflow-scrolling No Yes
File API Yes No
History Management No Yes
Shared Workers No Yes
Web Sockets No Yes
Web Workers No Yes
Various Input Types Half Full
Emoji (not part of HTML5) No Yes

h3. Performance Testing

When checking the user agent received, web servers report that our Galaxy Nexus was using WebKit version 534.40, which is a very modern and up-to-date WebKit. Under the hood, according to the BoyGeniusReport, the Galaxy Nexus contains a dual-core ARM processor, specifically the TI OMAP 4460, which is in the same family (Cortex-A9) as BlackBerry PlayBook and the Kindle Fire. We therefore expected SunSpider scores in the same range as other tablets. As we’ve mentioned before, this current generation of tablets all ship with dual-core processors and all have roughly the same JavaScript optimizations. So the results are again fairly predictable and look like other devices we’ve tested in this generation of hardware.

Galaxy Nexus SunSpider results

Like most devices in the dual-core Cortex-A9 family, the Galaxy Nexus has predictably good JavaScript performance. *Note:* This image was updated on Dec 14 at 1:30 PM PST.

The SunSpider tests are synthetic tests that push the JavaScript engine to its limit. So, next we turned our attention to some more real world tests, looking at CSS3 performance using our own Sencha Animator demos as well as a few other tests.

Like we tried with the Kindle Fire, 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. To our surprise, the game didn’t even start. We were a bit flummoxed by this given the fact that the whole CSS3 animation suite is supported in ICS. It’s unclear to us at the moment why this occurs. Our running theory is that the JavaScript game controls might be at fault, but it’s a wild guess at this point.

We ran through the rest of our Sencha Animator demos, some of which are very complex but are all JavaScript free, and were pleasantly surprised to see them all work beautifully. We haven’t seen an Android device run these demos well to date, and Ice Cream Sandwich shines here. For developers who want to use CSS3 2D, 3D, animations, and transitions, we’re happy to report that support on Ice Cream Sandwich is now near parity with other leading platforms.

We also tested a few other real world areas for performance and correctness. We tried a Canvas based GitHub network graph. Rendering performance was fine and the result was accurate. Pinch/zoom also worked well and didn’t exhibit the low-quality mode toggling, we’ve found in earlier Androids. The resolution and dithering of the page stayed constant as we zoomed and moved around the page. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid but it rendered to a very very small part of the screen, most likely due to the very high resolution of the Galaxy Nexus. When we zoomed in, the device managed to keep up reasonably well. The FPS easily dropped by half and audio was never dropped, and the FPS recovered when we zoomed out to the page’s natural size. Very impressive improvement over earlier Androids.

Finally we tested embedded HTML5 audio and video. In one word: finally. We used the test player on html5video.org, which gives you a video tag inline to the page. The Galaxy Nexus is the first phone we’ve seen that actually plays the video inline! iOS 5 on iPad and the iPhone do not play video inline, and we were impressed to see it work very well on Android 4. The video not only plays, but plays inline to the page. This is a big deal for web developers looking to use Video to enhance their web experience.

The Galaxy Nexus is a big step forward for developers looking to leverage HTML5 on Android.”

h3. 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.

Right off the bat, it’s obvious that the device is more HTML5-friendly than any other Android when using the Kitchen Sink. Rounded corners look beautiful (not pixelated as in earlier Androids), icon mask work correctly, multi-touch is supported and scrolling is substantially improved. It’s not all perfect though: full-screen white flashes were still noticeable when scrolling, even if greatly reduced from the seizure-inducing levels in Honeycomb. Page transitions also occasionally caused the browser to “blink” as it re-renders. Re-renders are most notable when scrolling a page that’s been fully laid out. When starting a scull, the page does a white screen-flash, then begins to scroll fluidly. Our best guess is that the browser is dumping the rendered page to the GPU to use hardware accelerated scrolling, and the blink occurs during that transition. Our guess is the CPU->GPU texture transition is the main culprit here.

Sencha Touch supports 3D transitions, specifically Flip and Cube, and they now work on Android for the first time, although screen-flashes are again a problem artifact. The other big issue we found is that address-bar hiding has changed between Android 3 and 4. This will impact web developers widely. In an single page app, like our Sencha Touch Kitchen Sink, it’s hard to get a hidden address bar to re-appear. On older Androids, pulling the whole page down would side the address bar back and push the page down with it. In ICS, this doesn’t happen reliably, and instead of adjusting the page geometry it actually overlays the address bar on top of the page content. This is not a deal breaker, but a definite change of behavior that developers should watch for.

h3. Ice Cream Sandwich: Suggestions for the HTML5 App Developer

HTML5 logo In summary, the Galaxy Nexus and Ice Cream Sandwich are a major step forward for the Android platform. Feature by feature, HTML5 support has gotten much better, rendering has become more accurate, and performance has gotten much faster. Although still behind the current HTML5 gold standard of iOS5, Android 4.0 is night and day compared to previous versions. We’re excited to see Google put this level of effort into Android’s web capabilities. And we hope they keep their foot on the gas! (And we’re keeping our fingers crossed that the Kindle Fire will get an upgrade to ICS in the New Year!)

sencha-samsung-galaxy-nexus.png 13 Comments   Read more

HTML5 Scorecard: Amazon Kindle Fire

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.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, we’re taking the measure of the new “Amazon Kindle Fire”:http://www.amazon.com/Kindle-Fire-Amazon-Tablet/dp/B0051VVOB2. 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.

h3. Our First Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. 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.

h3. Performance Testing

When checking the user agent received, web servers report that our Fire was using WebKit version 533.1, which is much older than the WebKit found on the Xoom and PlayBook. On other hand, when the Kindle is put in “desktop browsing mode”, it advertises itself as Safari 5/Mac OS X/Webkit 533.16. Under the hood, according to the iFixit teardown, the Fire contains a dual-core ARM processor, specifically the TI OMAP 4430, which is the same processor as the BlackBerry PlayBook. We therefore expected SunSpider scores in the same range as other tablets. As we’ve mentioned before, this current generation of tablets all ship with dual-core processors and all have roughly the same JavaScript optimizations. So the results are again fairly predictable.

Amazon Kindle Fire SunSpider results

For the most part, the Amazon Kindle Fire has similar SunSpider results compared to Apple iPad 2 and BlackBerry PlayBook.

The SunSpider tests are synthetic tests that push the JavaScript engine to its limit. So, next we turned our attention to some more real world tests, looking at CSS3 performance using our own Sencha Animator demos as well as a few other tests.

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.

Next we tried simpler animations. The Fire performed more smoothly, but had a notably bad implementation of timing. In the video below, the wave movements are controlled by CSS3 animations and are declared at constant speed. Instead, the animation speeds of each element diverge and lag noticeably and visibly from each other. We’ve never seen artifacts of this magnitude before. This got us wondering about the Kindle’s general timer quality, so we ran John Resig’s classic JavaScript timer test and found that the quality of the timer is similar to other Androids: with setInterval triggered every 10ms +5/-3s, with some noticeable latency spikes. (This compares to iOS 5’s best-in-class implementation of 10ms +/-1ms.) This isn’t supposed to matter as much once people get used to using requestAnimationFrame for JavaScript animations, but the Fire doesn’t have that either.

CSS3 Animations on the Amazon Kindle Fire

We also tested a few other real world areas for performance and correctness. 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.”

h3. 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 were the crispy CSS rounded corners. They’re not anti-aliased properly on the Fire. Webkit masks are also not supported. Then we got our 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.

h3. No to low Impact from “Accelerated Browsing”

Amazon Silk One of the main selling points of the Kindle browser is supposed to be its cloud-caching and pipelined HTTP connection that uses the SPDY protocol. This does seem to speed up normal page browsing a little, but it’s not very noticeable and we didn’t test this rigorously. But for HTML5 web apps, where code is downloaded and executed, there doesn’t seem to be any performance difference when we tested with acceleration on and off. It doesn’t appear as if client JavaScript is executed on the server-side at all, so the Kindle does not seem to have Opera Mini-style server-side execution. And SunSpider scores were essentially the same when accelerated browsing was turned on or off.

Side-by-side comparison of accelerated vs. unaccelerated browsing for some popular web home pages.

h3. 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.

sencha-html5-kindle-fire-thumb.jpg 19 Comments   Read more

Apple iOS 5: HTML5 Developer Scorecard

Apple iPhone 4S with Sencha logo Whenever a new device or mobile operating system comes out, we do our HTML5 Developer Scorecard to help folks who are building mobile web apps understand how to take advantage of these new devices. In early October, iOS 5 (and the iPhone 4S) was released. In our last few reviews, iOS has come head and shoulders above other device platforms as the best platform for HTML5 developers. High performance, hardware accelerated rendering, super quick JavaScript, and speed of adoption of new HTML5 features, it’s been the best platform to build modern web apps on.

Mobile Safari continues to hold the crown as the best mobile browser, providing the best HTML5 developer platform.”

The latest Mobile Safari on iOS 5 continues in that tradition. Mobile Safari continues to hold the crown as the best mobile browser, providing the best HTML5 developer platform as well as adding new features and improving others.

As usual, we looked at the basics of the browser: JavaScript and HTML/CSS rendering. For raw JavaScript execution speed, iOS 5 (with the iPhone 4S) isn’t much of a surprise and looks a lot like any other dual-core mobile device (such as the PlayBook and the iPad 2). It scored 2,275ms on the SunSpider benchmark: a solid score, but nothing new in the current hardware landscape. Things that iOS was good at continued to be good, such as smooth and fast hardware accelerated CSS3 transitions and animations. Our typical Sencha Animator tests ran smoothly and continued to render at a higher frame-rate than any other mobile device we’ve seen.

Given how good Mobile Safari has been, we didn’t run the browser through the usual paces we would have. Instead for this HTML5 Developer Scorecard, we took a look at the things that are new or better on the latest Mobile Safari:

* Canvas is crazy fast. In iOS 5, Canvas is between 5x – 8x faster. We tried two examples to see this work. First, the IE HTML5 “Speed Reading”:http://ie.microsoft.com/testdrive/Performance/SpeedReading/default.html Test. In iOS 4.x, the draw durations last roughly ~850ms, versus iOS 5, where they are a constant 10ms. Since that might be too synthetic, we also tried the Flash Canvas “image manipulation benchmark”:http://flashcanvas.net/examples/accelart.jp/blog/CanvasBench/CanvasBenchFlashCanvas.html. It reports the number of milliseconds the manipulation sequence takes. On iOS 4.x, this was ~19,000ms, but on iOS 5 it reported ~450ms. As with all benchmarks, take the result with a grain of salt, but for game developers building on Canvas, iOS 5 is a *much* more attractive platform for graphics.

* WebGL logoWebGL is supported. Sort of. If you’re an iAd developer, you can use WebGL in your ads, but you can’t use it through Mobile Safari or through a wrapped UIWebView. This is a limitation put in place intentionally by Apple as it’s possible to “work around”:http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on-ios/ the restriction in a wrapped UIWebView, but only by linking to private APIs — which means you can’t submit the resulting app to the app store.

* You can use compass directions! The DeviceOrientationEvent now supports compass headings via a new webkitCompassHeading property. The property gives you the device’s orientation relative to magnetic north. Check out James’ “sample”:http://jamesgpearce.github.com/compios5/ on your iOS 5 device to see it working.

* Better CSS position and overflow support. In iOS 5, position: fixed and overflow: scroll both work. If you’re looking to add some scrollable areas with native feeling bounce, you can now do it with these CSS properties. You don’t get a ton of control but if you’re looking to have a scrollable area in your web app, this is a really quick way to get it. There’s also a special iOS property, -webkit-overflow-scrolling: touch, which changes the scroll behavior to be more “iPhone”-like.

* WebWorkers work! In our testing we confirmed that WebWorkers — the API to let you spin up background “threads” is now enabled in iOS 5. It makes sense that this arrives just as the iPhone goes multi-core. This is great for developers who need to do some background processing in their application. That can be data updates to a server, or preprocessing some information, or anything else you can imagine when you don’t want to block the main browser UI thread. Now that iOS 5 has support for the API, we’re interested to see how it’ll end up being used in mobile (and in using it ourselves).

* HTML5 form fields are supported, including number, range, and date picker. This is great for an HTML5 developer because iOS now opens the appropriate on-screen keyboard based on the input tag type.

* XmlHttpRequest, level 2 is supported. Anybody who builds complex apps that use XHR to talk to a server is used to the hacks that XHR level 1 required. In iOS 5, XHR level 2 is supported so you can use capabilities like cross-origin support, binary data support, and more.

Apple iOS5 icon Mobile Safari in iOS 5 continues Apple’s tradition of delivering a first class browser and innovating in device APIs. Of course, there are more we’d like to see soon, primarily the MediaCapture APIs so web developers can get better access to the device camera. We’re particularly happy about the super-fast Canvas and really interested to see what developers will do with WebWorker support in mobile.

ios5-sencha-thumb.png 10 Comments   Read more