A Closer Look at Internet Explorer 9 Hardware Acceleration Through Flying Images

April 8th, 2010

One of our objectives with Internet Explorer 9 is taking full advantage of modern PC hardware to make the browser faster. We’re excited about hardware acceleration because it fundamentally improves the performance of websites. The websites that you use every day become faster and more responsive, and developers can create new classes of web applications through standards based markup that were previously not possible. In this post, we take a closer look at how hardware acceleration improves the performance of the Flying Images sample on the IE9 test drive site.

When you run Flying Images across different browsers you’ll see that Internet Explorer 9 can handle hundreds of images at full speed while other browsers, including Internet Explorer 8, quickly come to a crawl.

Flying Images is a great example of the types of experiences that become possible with Internet Explorer 9’s hardware acceleration. Flying Images uses standard HTML, CSS and JavaScript markup to animate images, using a common coding pattern that you’ll find in many places on the web today, particularly inside JavaScript based games and animation frameworks which need real-time responsiveness with a frame-rate of 60 frames per second (considered real time).

We redesigned the core of Internet Explorer 9 to be hardware accelerated. Internet Explorer 9’s display rendering subsystem uses the GPU for all graphics and text on web pages. Internet Explorer 9 moves graphics work that has traditionally occurred on the general purpose CPU to faster, more specialized hardware. Internet Explorer 9’s JavaScript engine takes advantage of multiple-processor cores to background compile JavaScript into machine code. Internet Explorer 9 uses modern processor instruction sets across the entire product. Taken together, these changes enable computations to occur faster and in parallel, freeing the CPU to spend time performing other operations.

The easiest way to see the impact of hardware acceleration on the performance of a page like Flying Images is by comparing CPU and GPU activity across browsers.

You can monitor CPU and GPU activity using TaskManager or your favorite utilities. For detailed performance analysis though, we recommend using the Windows Performance Tools (available for download here). These development tools are commonly used to profile Windows resource usage and can filter activity at the process level. We wouldn’t recommend these tools for the casual user but they’re a valuable resource for developers analyzing performance. The results below came from running the Windows Performance Tools on a two year old Dell Precision WorkStation (3.0 GHz Intel Pentium Dual-Core, 4GB physical memory, NVIDIA GeForce 8600 GT, 100GB 7200 RPM drive, Windows 7). These results will vary slightly based on exact PC configuration, but the overall patterns are representative of the Internet Explorer 9 customer experience.

Let’s start by looking at the performance characteristics of Flying Images in Internet Explorer 8. The below graphs show the CPU and GPU usage and Visual Update frequency over a one half second period after the page was fully loaded and animations started.

Internet Explorer 8 has essentially taken an entire core of the CPU (50% of the dual-core machine) and is using that entire core to move the images as quickly as possible trying to maintain 60fps. Although some browsers (including IE8) have a multi-process architecture, the web programming model is single threaded, so a multi-core CPU can’t work in parallel on this problem. Even with this significant CPU usage, you can see that Internet Explorer can only make one move every 0.221 seconds which is shown through the visual updates part of the chart below. The result is 4.5 frame updates per second or 4.5fps. You’ll also notice Internet Explorer 8 does not utilize the GPU for this graphically rich scenario.

If we perform the same analysis on Google Chrome 4.1, you’ll see that Chrome also uses an entire core of the CPU, and doesn’t make any use of the GPU, trying to move the images at 60fps. Chrome is only able to make one move every 0.238 seconds which results in 4.2fps.

Notice that IE8 and Chrome 4.1 have nearly identical 4fps results even though Chrome 4.1’s JavaScript engine outperforms IE8’s JavaScript on common industry benchmarks. Flying images gives a more holistic view on browser performance. It calls on many different browser subsystems: JavaScript to calculate the new position of the images, CSS and layout to position the images, the display system to present them on the screen, and more. It’s an example of how browser performance is a multidimensional problem that spans more than JavaScript.

Continuing with webkit based browsers, let’s look at Apple Safari 4.0.5. Safari also uses an entire core of the CPU trying to move the images at 60fps, but is only able to make one move every 0.191 seconds which results in 5.2fps. Even though both Chrome and Safari are based on webkit, Safari is able move the images 20% faster than Chrome. This is a good example of how the Google and Apple architectures and webkit instances have divergence. You’ll also notice that although Safari is the most graphically capable of the webkit based browsers it does not utilize the GPU.

Moving to Mozilla Firefox 3.6, you’ll see that like other browsers Firefox uses an entire core of the CPU trying to move the images at 60fps. Firefox does a better job on performance and is able to make one move every 0.062 seconds. This results in 16.1fps which is noticeably faster than the above browsers, but is still only a quarter of the 60fps goal. One of the techniques that Firefox uses to achieve this performance is to slightly degrade the quality of the images during scaling, while the other browsers attempt to maintain full image quality. One of the challenges with not being hardware accelerated is that you’re often forced to make tradeoffs around things like performance and quality. We’ll talk more about this in a future post.

When you run this page in the Internet Explorer 9 Platform Preview and look at the graph below, you’ll immediately see how hardware acceleration fundamentally changes the performance characteristics of the web. The first thing that you’ll notice is that Internet Explorer 9 utilizes the GPU and is able to move the images in real-time at 60fps. More importantly, Internet Explorer 9 is able to achieve this real-time performance only using 12% of the total CPU and 15% of the total GPU.

When the webpage was loaded, Internet Explorer 9 took advantage of the additional processor cores to compile the JavaScript into native machine code. Using the CPU, Internet Explorer 9 can execute the machine code on each move to quickly determine the next location for the images and then move them through the CSS layout process. It then hands off the display of these images to the GPU, which through specialized hardware efficiently updates the screen. Since the CPU and GPU perform execution in parallel, additional computation can be occurring on the CPU while the GPU is updating the screen. In this example though there’s nothing to compute, so the CPU remains unused until the next move of the images is required.

The most shocking thing about this example is that it doesn’t challenge Internet Explorer 9. Internet Explorer 9 is only using 12% of the CPU and 15% of the GPU without compromising the quality of the images, which means that 80% of the PC resources are available to developers.

It’s clear that HTML5 will enable a new class of applications that were previously not possible through standards based markup, and these applications can’t be limited by the performance of today’s browsers. Doing HTML5 right means enabling developers to build web applications that have the performance of desktop applications. That’s our objective with Internet Explorer 9 and why we’re so excited about hardware acceleration.

Let us know what you think of hardware acceleration!

Jason Weber Lead Program Manager for IE Performance

Update: Fixed incorrect capitalization.