An Early Look At IE9 for Developers

We’re just about a month after the Windows 7 launch, and wanted to show an early look at some of the work underway on Internet Explorer 9. 

At the PDC today, in addition to demonstrating some of the progress on performance and interoperable standards, we showed how IE and Windows will make the power of PC hardware available to web developers in the browser. Specifically, we demonstrated hardware-accelerated rendering of all graphics and text in web pages, something that other browsers don’t do today. Web site developers will see performance gains and other benefits without having to re-write their sites.

Performance Progress. Browser performance involves many different sub-systems within the browser. Different sites – and different activities within the same site – place different loads and demands on the browser.

For example, two news sites might look similar to a user but have very different performance characteristics. Because of how the developers authored the sites, one site might spend most of its time in the Javascript engine and DOM, while the other site might spend most of its time in layout and rendering. A site that’s more of an “application” than a page (like web-based email, or the Office Web Apps) can exercise browser subsystems in completely different ways depending on the user’s actions.

The chart below shows how much time different sites spends in different subsystems of IE. For example, it shows that one major news site spends most of its time in the script engine and marshalling, while another spends most of its time in script and rendering, and the Excel Web App spends very little of its time running script at all.

Note that this chart shows the percentages of total time spent in each subsystem, not relative time between sites. It focuses on just the primary browsing sub-systems and doesn’t include “frame” functionality (like anti-phishing), or third-party software that’s running in the IE process (like toolbars, or controls like Flash). It also factors out networking since that’s dependent on the users network speed. Notice also that a site’s profile can change significantly across scenarios; for example, the Excel Web App profile for loading a file is quite different from the profile for selecting part of the sheet.

The script engine is just one of these browser subsystems. There are many benchmarks for script performance. One common test of script performance is from Apple’s Webkit team, the SunSpider test. The chart below shows the relative performance of different browsers on the same machine running the SunSpider test.

In addition to IE7 and the current “final release” versions of major browsers, we’ve included the latest pre-release “under development” builds of the major browsers. We’re just about a month after IE8 was released as part of the Windows 7 launch, and the version of IE under development is no longer an outlier. 

It is worth noting that once the differences are this small, the other subsystems that contribute to performance become much more important, and perceiving the differences may be difficult on real-world sites. That said, we remain committed to improving script performance.

We’re looking at the performance characteristics of all the browser sub-systems as real-world sites use them. Our goal is to deliver better performance across the board for real-world sites, not just benchmarks.

Standards Progress. Our focus is providing rich capabilities – the ones that most developers want to use – in an interoperable way.  Developers want more capabilities in the browser to build great apps and experiences; they want them to work in an interoperable way so they don’t have to re-write and re-test their sites again and again. The standards process offers a good means to that end.

As engineers, when we want to assess progress, we develop a test suite that exercises the breadth and depth of functionality. With IE8, we delivered a highly-interoperable implementation of CSS 2.1 and contributed over 7,200 tests to the W3C. Standards that do not include validation tests are much more difficult to implement consistently, and more difficult for site developers to rely on.

Some standards tests – like Acid3 – have become widely used as shorthand for standards compliance, even with some shortcomings. Acid3 tests about 100 aspects of different technologies (many still in the “working draft” stage of standardization), including many edge cases and error conditions. Here’s the latest build of IE9 running Acid3: 

As we improve support in IE for technologies that site developers use, the score will continue to go up. A more meaningful (from the point of view of web developers) example of standards support involves rounded corners. Here’s IE9 drawing rounded corners, along with the underlying mark-up:

Another example of standards support that matters to web developers is CSS3 selectors. Here’s a test page that some people in the web development community put together at css3.info; it’s a good illustration of a more thorough test, and one that shows some of the progress we’ve made since releasing IE8:

Community testing efforts like this one can be helpful. Ultimately, we want to work with the community and W3C and other members of the working groups to define true validation test suites, like the one that we’re all working on together for CSS 2.1, for the standards that matter to developers. For example, this link tests one of the HTML5 storage APIs; some browsers (including IE8) support it today, while others don’t.

The work we do here, both in the product and on test suites, is a means to an end: a rich interoperable platform that developers can rely on. 

Bringing the power of PC hardware and Windows to web developers in the browser. The PC platform and ecosystem around Windows deliver amazing hardware innovation. The browser should be a place where the benefits of that hardware innovation shine through for web developers.

We’re changing IE to use the DirectX family of Windows APIs to enable many advances for web developers. The starting point is moving all graphics and text rendering from the CPU to the graphics card using Direct2D and DirectWrite. Graphics hardware acceleration means that rich, graphically intensive sites can render faster while using less CPU. (This interview includes screen captures of a few examples.) Now, web developers can take advantage of the hardware ecosystem’s advances in graphics while they continue to author sites with the same interoperable standards patterns they’re used to.

In addition to better performance, this technology shift also increases font quality and readability with sub-pixel positioning:

96 point Gabriola on a Lenovo X61 ThinkPad at 100% Zoom using GDI (note jaggies):

96 point Gabriola on a Lenovo X61 ThinkPad at 100% Zoom: Direct2D (without jaggies):

Last week, Channel 9 interviewed several of the engineers on the team. You can find videos of the interviews here:

Introduction, and Interoperable Standards

Early look at the Script Engine

Hardware accelerated graphics and text in the browser via Direct2D

While we’re still early in the product cycle, we wanted to be clear to developers about our approach and the progress so far. We’re applying the feedback from the IE8 product cycle, and we’re committed to delivering on another version of IE.

Thanks,
Dean Hachamovitch
General Manager, Internet Explorer

Update 11/23/09 - The IE9 demo from PDC is now available.  The IE content starts around minute 48.