With Internet Explorer 9, developers can build new classes of HTML5 applications that were previously not possible. We’re having fun building sample web applications that provide a glimpse into the types of experiences that hardware acceleration provides. In this post, we take a closer look at Flickr Explorer, one of the samples that we released alongside IE9 Platform Preview #2.
With Internet Explorer 9, Flickr Explorer is generally able to maintain a near real-time responsiveness of 52fps (52 frames per second). In contrast, other browsers struggle to maintain 4-8fps, which is barely 15% the performance that Internet Explorer 9 provides in this particular scenario.
Let’s take a closer look at the CPU and GPU activity graphs collected while running the Flickr Explorer sample to see more hardware acceleration in action. These traces were captured while zooming in on a selected Flickr photo, and use the same machine and methodology that we previously discussed.
First, results from Internet Explorer 8 are shown below. Like we saw with the earlier Flying Images demo, Internet Explorer 8 utilizes an entire CPU core (50% of this dual core machine) to animate the images on screen. Internet Explorer 8 does not utilize the GPU in this scenario.
Internet Explorer 8 can barely make one screen update every 0.253 seconds, which results in roughly 3.9 frames per second (FPS). This is clearly a very poor experience for the user.
Next, let’s check out how the new Chrome 5 beta handles this task. As you can see below, it doesn’t fare much better than Internet Explorer 8. Chrome is able to update the screen every 0.222 seconds, achieving a frame rate of about 4.5 FPS. Again, this results in a very choppy and undesirable experience. Chrome also does not utilize the GPU in this scenario.
Safari 4 handles the demo similarly to Chrome, earning a slightly lower frame rate of 4.2 FPS. Again with Safari, the GPU remains unused while the CPU remains a bottleneck.
Next, let’s take a look at Firefox. We used the most recently Firefox nightly build, Minefield 3.7a5, for this analysis. Like each other browser tested, we ran Minefield in its default configuration (which means hardware rendering with D2D was not enabled). We will post comparisons with Firefox’s hardware acceleration when it’s on by default in their beta.
Firefox handles the demo much better than Chrome and Safari. The screen gets updated roughly once every 0.12 seconds, which results in a frame rate of about 8.3 FPS. While this is nearly double the score of Chrome, it is still quite slow and barely usable.
Finally, the results from Internet Explorer 9 Platform Preview 2 are shown below. We can see that, unlike with the other browsers, the CPU handles this task with ease and has periods of frequent rest where Internet Explorer and your applications can performance additional operations, while the GPU renders Flickr Explorer to the screen.
Internet Explorer 9 is able to update the screen once every 0.019 seconds on this mid-range configuration, which equals a frame rate of about 52 FPS.
When you play with the demo, the difference between Internet Explorer 9 and other browsers is crystal clear. While you can easily zoom in, out, and pan through the Flickr photos with Internet Explorer 9, it’s difficult to do this with the other browsers.
We’d like to extend a special thanks to the Flickr team for building such a simple, easy to consume services API. We were able to put this sample together in a couple of days using the same APIs that web developers program against today. The only difference is that we have higher expectations for the types of application that you can build through standard markup and these APIs.
We’re excited to see what new experiences web developers will create with IE9’s hardware acceleration!
Program Manager for IE Performance