Latest Ext JS 7.8 is now available. Learn more

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

November 19, 2012 400 Views

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)