While most modern browsers now support hardware acceleration, the quality of implementations
varies greatly between browsers. Hardware acceleration is more than just a checkmark.
How a browser chooses to enable hardware acceleration has a direct impact on the performance
and user experience of Web applications.
To highlight the quality and performance differences in hardware acceleration, let's look closely at the
Paintball test drive, released with
IE 10 Platform Preview 1. Paintball uses HTML5 Canvas to simulate shooting
paintballs against a wall. Paintball demonstrates how quickly images compose an entire scene.
Many other HTML5 Canvas performance examples on the web just measure how quickly the same image can be drawn on
Paintball draws an entire scene as quickly as possible. At its end, you'll see two numbers. The first is how long drawing
the entire scene took in seconds; the second is the number of paintballs fired per minute.
In this test, more paintballs in a shorter time is better.
Screen shot of Paintball demo rendered in IE10 Platform Preview 1
We wanted Paintball to be a general purpose Web application for painting any phrase with any color of paintball. To this end, Paintball programmatically
generates paint splatters at runtime based on the specified RGB values. Programmatically
manipulating images at runtime is a common scenario for emerging HTML5 Web applications.
Paintball starts by drawing a solid rectangle which is the color of the paint splatter.
Paintball uses a sprite sheet to hold the frames of the splatter animation:
Paintball decides how large the resulting splatter should be, and draws a frame
from the sprite sheet using the destination-in composition mode. This causes
the pixels being drawn to mask the current contents of the canvas.
By generating the graphics on the client, Web developers are able to build and download fewer images. This is a great approach for programmatically changing the color of an image.
The paintballs are created in a canvas which is not visible on the screen, and then
drawn to the primary display canvas. Using a secondary, off-screen canvas to compose the effects improves performance quite a bit, in all browsers, by using composition operations
only while the animation is in progress. Once the animation has reached its final frame (paint fully
splattered), we can use a cached view of the secondary canvas when drawing the full scene.
Paintball uses the same HTML5 markup for all browsers as specified by the HTML5
Canvas specification. Although all modern browsers now support these API’s, the quality
differences are extremely noticeable. Here’s a visual comparison of the rendering
You'll notice the following differences:
These differences capture the kinds of problems that developers face building sites that look and work consistently across browsers. Developers want to use the same markup
and experience interoperable results. While these bugs might seem minor (and shouldn't be hard to fix), they represent the quality issues across browsers that make developers resort to
plug-ins or lower their expectations for sites.
The performance differences between implementations are even more striking. For our testing we used the same mid-range configuration that
have used throughout the last year. Here’s how quickly these modern browsers,
which all have some degree of hardware acceleration, compose the scene (on Windows 7):
Let’s look at detailed performance traces to see how the different browsers use the
CPU and GPU when animating a single paintball shooting and splattering onto the
screen. The below results were generated using the
Windows Performance Toolkit.
With Chrome 12 you’ll notice that it takes 3.7 seconds to shoot a single paintball.
We can see that when the paintball first appears on the screen as a ball, there
are lots of updates with moderate GPU and CPU utilization. Chrome is able to maintain
almost real-time animation. Once the splatter effect (described above) starts to
render, we see GPU and CPU utilization spike for several seconds. During this time,
there are no screen updates, so the demo appears to freeze. Finally, the browser
catches up and the scene finishes rendering.
Firefox 4 handles this scene quite well in 0.550 seconds. CPU and GPU utilization
is fairly steady throughout the animation although the CPU activity does increase
as the splatter effect is rendered. Screen updates occur predictably, rendering
19 frames during the rendering of the scene.
IE 10 renders the scene quite smoothly, in the shortest amount of time (0.475 seconds)
and with the most frames. From the below graph, you can see how CPU and GPU utilization
are lower than with Firefox, and the screen updates occur more frequently and at
more regular intervals.
Performance in Safari 5 can be misleading from the CPU/GPU measurement perspective.
While the GPU utilization is lower, and that screen updates occur frequently at
regular intervals, nothing appears to be happening on the screen. That’s because
Safari is telling the GPU to paint the same image over and over again. Safari only
draws a few images to the screen and then jumps to the final frame without any animation
occurring. Safari feels hung and unresponsive during this time.
The graphs above show a single paintball splatter – a small slice in the overall
work done to render the entire Paintball demo. While most browsers can handle a
single paintball well, many of the browsers have a difficult time scaling to dozens
of paintballs. For example, Firefox renders a single splatter fairly well (almost
as fast as IE 10). However, when faced with a higher load in the full demo experience,
performance in Firefox slips to about 20% of Internet Explorer 10.
Here’s the total CPU time, GPU time, and visual updates across browsers.
Browsers with full hardware acceleration and fully interoperable implemenations of HTML 5 features deliver a better experience for
Web developers and end users.
We hope this look into the internals of Paintball will help you better understand
the different quality and performance characteristics across browsers, particularly
in relation to HTML5 Canvas and composition modes. It’s an exciting time to be developing
graphically rich Web experiences!
—Seth McLaughlin, Program Manager, Internet Explorer Performance Team