source: extremetech.com
At the Mix developer conference today in Las Vegas, Microsoft launched preview code for the most critical element of its upcoming Internet Explorer 9 Web browser: the underlying rendering engine.
Key goals for the new browser engine are few and simple: improved speed and support for new Web standards, particularly HTML5 and SVG (the World Wide Web Consortium (WC3) organization, to which Microsoft contributes test code and other resources, oversees both).
IE9 isn't an full-fledged Web browser yet; so far, it's merely the rendering subsystems wrapped in a simple user interface that does nothing more than allow Web address entry and provide developer tools. IE9's director Dean Hachamovitch told a select group of reporters (myself and PCMag Editor-in-Chief Lance Ulanoff among them) last week at its Redmond, Washington, campus that big changes were also coming to the browser's user interface, but that this release was aimed at giving developers a target for their Web site code.
Internet Explorer has been something of an object of derision among browsers when it comes to speed, and particularly in JavaScript performance. SunSpider JavaScript Benchmark results are often cited as an indication of this, but Microsoft has long maintained that it's put development efforts in other parts of the pipeline needed to render Web pages, such as layout and display. This newest version of Internet Explorer addresses both JavaScript and other speed bottlenecks.
Speed Through GPU Acceleration
Because much of what a browser does involves rendering graphical images and drawing them to the display, it seems logical that such operations would be performed on the hardware optimized for them: the video card. Current browsers, however, only use the CPU for these operations. IE9 moves graphics processing to the GPU.
IE9 will be able to take advantage of both high-end gamers' powerhouse video cards and the more modest models found in low-powered machines. Though JavaScript performance plays a role in Web browser performance (as we'll discuss below), there are other factors as well: too—networking, HTML parsing, CSS, data collections, DOM, COM marshalling, layout, and display rendering. The IE dev team has profiled the most common performance patterns among thousands of the world's most popular sites and found that rendering actually accounted for a bigger part of the pipeline than JavaScript. Clearly, handling the display rendering steps in the GPU will have a significant positive impact on Web performance.
JavaScript Speed through Compilation on a Second Core
Browsers handle JavaScript through on-the-fly interpretation which, just like human language interpretation, requires steps between the code and the execution on the CPU. To be fair, what Firefox, Chrome, and Opera use is a bit better than straight-up interpretation: They use a JIT (just-in-time) compiler for some JavaScript, which delivers a palpable speed boost over interpreting the code.
But IE9 will go beyond the JIT idea by taking advantage of the fact that nearly all PCs bought in the last few years have, in effect, more than one CPU—they're dual- or quad-core machines these days (and Intel just released the first six-core CPU), and can run up to twice as many threads. Multicore CPUs use one core to render the JavaScript the old way and the second to actually compile it to run directly in machine code on the hardware, with no translation required. Any programmer knows that the speed difference between interpreted and compiled code is enormous, so it follows that in some cases the performance gain will be game-changing.
Jason Weber, the Principal Program Manager lead for Internet Explorer, showed a demo of spinning 3D icons that dramatically illustrated the difference both JavaScript compilation and GPU acceleration can make. As icons were added and spun faster, all current browsers topped out the CPU (or "pegged" it) and the spinning demo slowed down to a painful 5 frames per second or fewer, with a dozen icons spinning slowly. But spinning and zooming 256 icon globes at warp speed in IE9 left the primary CPU core with processing time to burn. Said Weber, "We're only using a quarter of the first core of the CPU. This is enabling developers to create a completely new class of applications on the Web."
The SunSpider benchmark only tests one element of browser performance, and it actually doesn't even test some of the most frequently used JavaScript commands. Microsoft has set up a test of the most frequently used ones on the test site for the new browser platform and, though engineers were quick to deny the term "benchmark" for these, the results were impressive. For these top 15 JavaScript actions, IE9 came out twice as fast as the current SunSpider-leading Opera browser. Of course, we'll need to do our own tests to validate Microsoft's results—and we will—but it made for an effective demonstration nonetheless.
IE has a history of frustrating developers because of the need to fork parallel code, especially for earlier versions. Hachamovitch wanted to send the message that sites should just deliver one code base for all browsers that adhere to real standards. This comes back to what has been a programmer's Holy Grail for years: the concept of write-once, run-anywhere. One of the recurring themes at the press preview was IE9's goal of "browser interoperability."
IE hasn't been alone in needing its own special code. Firefox has had the "-moz" prefix for some commands that only work in that browser; and Webkit, too, has required a "-Webkit" prefix for some. Microsoft Program Manager Tony Ross demonstrated how a simple two lines of code to get rounded corners on a rectangle quickly grew far more cumbersome when all the alternate code for these different browsers was added. "Ultimately, running the same markup and having complete interoperability is a two-way street: There's the part that the browser has to play, and the part developers have to play. We encourage them to detect for capabilities rather than for browsers."
Ross and other Microsoft engineers have been extremely active in the W3C, the official standards body of the Internet. Though tests like Acid3 have purported to indicate support for "standards," it turns out that many of the capabilities it tests aren't official W3C specs. Hachamovitch did note that "as we support more of the markup that Web sites are using, our Acid score will go up." But he went on to decry the test's claim to represent true standards: "As standards and browsers change, you see a lot of variance." That said, the new IE9 browser engine's Acid3 score is up from 20 to 55 out of 100 on the test, and that could still go up when we see beta.
A couple of specific HTML5 features that the IE9 platform will support are the video and audio markup tags. And where Firefox hopes content providers will switch to the open-source Ogg formats, IE9 will support industry standard MPEG-4 and H.264 for video and AAC and MP3 for audio.
New Support for SVG
Sure, you can offer a PDF download for complex content like floor plans and org charts, but why not make these decipherable right inside the webpage? SVG allows just that. SVG is a W3C standard for animated, interactive graphics based on paths rather than bitmaps. No matter how much you zoom in on an SVG image, edges remain razor sharp—unlike bitmapped image formats such as JPEG, which show degradation as you enlarge them. This holds true for text, too; that's key for the org chart example mentioned above.
In fact, John Hrvatin, Senior Program Manager Lead, Internet Explorer, told the press group that IE9 is the first browser that natively supports SVG inline with HTML; previously, XHTML was required. SVG is the descendent of VML, which came out of the Visio drawing tool. Other browsers use SVG for the popular map sites, while until version 9, IE uses VML.
Said Visio veteran and now Internet Explorer Partner Program Manager Ted Johnson, "SVG is a huge standard. We're not doing all of it in the first release, but we're doing a tremendous amount of it. When we ship, we're going to be covering all the way through what we consider 'static SVG.' Filter effects, animation, and fonts won't be included. A lot of these are still in flux. What's exciting about SVG is that you can easily see the markup in view source alongside its graphical result in the browser."
Will Microsoft Get It Right with IE9?
After years of criticism about IE's lack of support for standards and slower Web page loading than that of its competitors, it looks like Microsoft is taking some concrete, drastic steps to address these issues. Only time will tell, but Hachamovitch's plea to developers to stop coding separately for Internet Explorer is a good sign, as are the rendering speed initiatives. Taking advantage of today's ubiquitous multiple cores in the CPU and discrete graphics hardware is both radical and logical, and could completely change the game when it comes to page-rendering speed. It will be interesting to see if other browser makers take the gauntlet and implement these techniques.
One factor, though, is IE9's release schedule. Microsoft reps were completely noncommittal about when the browser would be released, in either a beta or final version. Given the frequency with which we see new editions of Firefox and Google Chrome, it's conceivable that another browser could come out with hardware acceleration before anyone gets a chance to use IE9.
For now, you can take the platform for a test drive by visiting ie.microsoft.com/testdrive in your current browser.
Wednesday, March 17, 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment