A Closer Look at Internet Explorer 9 Hardware Acceleration Through Flying Images
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.
Comments
Anonymous
January 01, 2003
It's nice to see Microsoft in the game again. I expected to see hardware acceleration and multi-core support from Google first so this was a surprise. You might actually have the best browser when IE9 ships unless Google does something. Your speed is "wow" and your standards support is acceptable. I never thought I would say that. IE7 was a poor excuse for a browser and IE8 was a fools attempt at catching up. It's time that finally Microsoft found the Ozzie religion and took the browser seriousely. If Chrome can't match your speed and hardware acceleration then I'll consider switching to IE. Your development tools still lag behind 5 years and that's the only thing that makes me hesitate from doing my testing in IE9. How much of graphics card memory will IE9 use?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
>Which version of sunspider: 0.9 or 0.9.1? Both. Last night's FF 3.7 nightly. >10% faster on both machines I bothered to try. Too lazy to run it yourself? >You confuse a "FACT" and an announcement. English isn't your first language, is it?Anonymous
January 01, 2003
Hi, Beautiful images. ie9 very goog performance...Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
@Math: You can't be serious about IE9 being 20 times faster than Chrome. IE9 has the lead with graphics for a few short months but Chrome will catch you before IE9 ships. Firefox is the loser since they're no longer relevant.Anonymous
January 01, 2003
http://googlechromereleases.blogspot.com/2010/04/dev-channel-update_08.html The Dev channel has been updated to 5.0.371.0 for Windows, Mac, and Linux.Anonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
@Philip Kahn: Wouldn't it be cool if Microsoft was actually thinking about this kind of interface for IE9? So simple, so clean, so, almost perfect. Take that interface into consideration, Microsoft. On the other hand, I am glad to see that IE9 is using the power of computer hardware. This only make sense since web applications are eventually going to become the norm. I can't wait until the first beta! Keep up the excellent work! IE9, my idea.Anonymous
April 07, 2010
REMOVE COM AND GOTO MANAGED CODE!!! AND ADD GDI+ ADAPTER FOR OLD COMPUTERS!!!Anonymous
April 07, 2010
That's interesting. Are you looking into switching to managed code for IE9?Anonymous
April 07, 2010
I just wish that the work done on the JavaScript engine would be back-ported to the DLR. Pity extra effort wasn't made to address the bridge between HTML5/JavaScript and the CLR.Anonymous
April 07, 2010
I, for one, am really impressed with how IE9 is taking advantage of the current hardware offerings. Separate core JS compilation is a brilliant idea, and the hardware accelerated graphics are just incredible. Well done, and congratulations.Anonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
Please make a blog post about text rendering and explain what you are trying to do to address the font bold/blurriness that DirectWrite is causing at small font sizes.Anonymous
April 07, 2010
Are you creating this as a distraction to the multitude of deficiencies that IE9 will have? I mean, if you can't give 'em what they want, dazzle 'em with pretty pictures.Anonymous
April 07, 2010
@Aaron: No. To use managed code in IE, you can author against Silverlight.Anonymous
April 07, 2010
It's exciting to see Microsoft taking IE9 seriously. But you've got to get the names of the other browsers correct: It's Firefox, not FireFox.Anonymous
April 07, 2010
One can't deny that these results are anything short of incredible. Nobody expected this from Microsoft. Reading through this post reinforced that when Microsoft get's serious competition they respond with a flaming vengeance. I guarantee that Chrome and FF management are scared right now because they have to respond quickly or game over. Watch out webkit because the dragons they be angry.Anonymous
April 07, 2010
Looks fantastic! Would of been nice though if you could of compared it to Firefox's Hardware acceleration, as Firefox's fast ramp up on the nightly builds of hardware acceleration has been in large part to you guys showing off IE9s.Anonymous
April 07, 2010
P.S: How to enable hardware acceleration on Firefox for future testing: http://www.basschouten.com/blog1.php/2010/03/02/presenting-direct2d-hardware-acceleratioAnonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
Will SVG be hardware accelerated? That would be sweeeeeet!Anonymous
April 07, 2010
dbclick(is float bug?): http://www.31hh.com/test2.html http://www.31hh.com/test3.html my mail: wiml[at]21cn.comAnonymous
April 07, 2010
@Christopher Austin -- Yes, SVG is hardware accelerated.Anonymous
April 07, 2010
at ie8 and ie9 dbclick(is float bug?): http://www.31hh.com/test2.html http://www.31hh.com/test3.html my mail: wiml[at]21cn.comAnonymous
April 07, 2010
Thanks for the detailed analysis. You're off to a good start with IE9.Anonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
I tried the IE9 preview on my machine with ATI graphics and I can get 256 images moving around at 54 frames per second (fps) in IE9. Chrome stops working with 100 images at 1 fps. That makes IE9 138 times faster than Chrome with ATI graphics. I don't understand how you did this but the web thanks you.Anonymous
April 07, 2010
An interesting update to this article would be to compare IE9 with a Firefox nightly build with Direct2D acceleration enabled. Any plans to do so?Anonymous
April 07, 2010
Trying flying images in Internet Explorer 7, it ran 256 images at an acceptable 26fps.Anonymous
April 07, 2010
When is the end of support for IE6 on Windows 2000 and IE8 on Windows XP SP3? June 2010 and April 2014?Anonymous
April 07, 2010
On one side, Silverlight 3.0 with accelerated graphics is available for Windows 2000 and on the other side IE9 won't support XP?Anonymous
April 07, 2010
It would have been nice to have included Opera in your measurements, since that browser (version 10.51) is quite close to the current IE9 Platform Preview in terms of performance in this test, despite not yet employing GPU acceleration.Anonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
+1 for fixing the text in IE9 so that it's comparable with Win7 Cleartype at small sizes. D2D seems to be doing horrible things to small-size type. Much prefer IE8 to 9 in that regard - and while zoomy graphics are nice, THE WEB IS TEXT! PLEASE fix. https://connect.microsoft.com/IE/feedback/details/542316/font-rendering-is-worse-in-ie9-than-ie8Anonymous
April 07, 2010
I'll tell you what, I've been using Firefox for years but if IE9 can render today's web pages as well as those mockups of future pages, and can do so with the low ping on hardware that the graphs promise, you may be looking at (or rather reading the rant of) another convert back to IE. Keep up the good work guys. Stick a pleasing UI on this and I just might forget about Firefox.Anonymous
April 07, 2010
You should have also tested the current Firefox 3.7 nightly with D2D/DW rendering enabled… http://forums.mozillazine.org/viewtopic.php?t=1775755Anonymous
April 07, 2010
Does using DirectWrite means ClearType will now be enforced in IE9? Can I be rest assured that ClearType can be turned off?Anonymous
April 07, 2010
@Jawed It seems Opera also reduces the images quality to gain extra frames (simlar to Firefox).Anonymous
April 07, 2010
This is great stuff, but IE9 is months (if not a year) from shipping. You're comparing released code to an internal engineering build. Hardly apples to apples. I'm not even aware of an planned ship date for IE9 yet. Do anyone really think Chrome and FF won't build some of this tech into their own browsers by then? As Wurst mentioned, FF 3.7 (which is also in the under development phase) already supports some of this technology.Anonymous
April 07, 2010
I can't get the FF 3.7 beta to work with D2D. It crashes and runs SLOWER than FF 3.6.Anonymous
April 07, 2010
I remember reading that Firefox has a proprietary CSS property for defining the scaling mode.Anonymous
April 07, 2010
The comment has been removedAnonymous
April 07, 2010
PS: firefox hits 60FPS, not 16.1. Way to get creative. Even on an intel graphics setup with a core2duo I get 65~ FPS running the link.Anonymous
April 07, 2010
The GPU graphs for other browsers are just not credible as they show absolutely no GPU load. I ran this using FF 3.6 with loads of images and spun it quite fast, GPU load varied between 3 and 10%, more than enough to show on your graphs scale. Fair enough they don't accellerate, but they most certainly use some GPU!Anonymous
April 08, 2010
I can run this sample with 60fps on my firefox 3.6.3 (linux).Anonymous
April 08, 2010
Look at the Google blog running Quake II in JavaScript in a WebKit Browser. This is what you will be competing with at release. Not the current crop of Browsers. When testing, the JavaScript interpreter still seems quite slow in IE9. I hope it speeds up as you remove debug code.Anonymous
April 08, 2010
Great work on this IE Team. We're now in a golden age of browser development, and I think we're going to see lots of really cool stuff coming out in the next few years from all the browser makers.Anonymous
April 08, 2010
presumably they were measuring GPU use per process instead of globally. There's nothing wrong with saying that the current releases of browsers don't use the GPU -- they don't.Anonymous
April 08, 2010
Where is Opera in this comparision? I suspect left out simple because it does in SOFTWARE, what IE9 needs to do in HARDWARE. Opera have been working on Hardware accelration for some time now, and when it arrives, it will be a game changer... http://my.opera.com/chooseopera/blog/2009/02/05/meet-carakan-and-vegaAnonymous
April 08, 2010
Matt, look at the specs of the machine tested, it was a pentium 4 dual core, a core 2 duo is quite a bit faster. But Firefox is still slower, even on this core i7 965, I get 16-20 fps with ~190 objects in firefox (with degraded image, yay) but with IE9 I get 64 fps which is must be a hard coded limit because I get 64 fps with much lesser objects as well. The d2d firefox was slower than IE9 as well, but I assume it did it without messing up the image quality. And opengl isn't good for anything, most developers do not use it, period.Anonymous
April 08, 2010
Hey IE Team, Great job on the HW accell. Question: What if the flying images are Animated GIF's? I noticed that in IE9 animated gifs animate faster than in IE8 but they look very aliased in IE9 while in IE8 they look very nice. For example this image looks nice, anti-aliased but is not performing well in IE8. In IE9 it performs well but looks aliased. http://upload.wikimedia.org/wikipedia/commons/c/ca/Beam_mode_4.gifAnonymous
April 08, 2010
VS2010 can be extended with managed code and COM. When will IE be extendable with managed code? Obviously it's possible without throwing away COM since it was done in VS2010. The managed extension mechanism should be as/more powerful as in Firefox 3 and involve no native/COM interop.Anonymous
April 08, 2010
Please stop playing around with goofy animations and instead work on supporting common things that most other mainstream browsers support. It doesn't matter how fast you can display the page if it doesn't render properly.Anonymous
April 08, 2010
@droid: You can extend IE with Managed Code, but that doesn't mean you should. Keep in mind that VS2010 isn't a a heavily multi-process architecture like IE, and it already loads the framework. There are three issues: 1> Performance/Reliability 2> Manage Addons 3> The “side-by-side” framework problem More details on each: 1> The performance and reliability problem is that .NET is a pretty heavy framework to be loading, and hence we’ve seen some significant performance problems with sites that are using the framework because of the cost to load the framework into the process and so forth. WPF, in particular, can result in very slow performance as we saw with the original CardSpace/InfoCard implementation. Reliability-wise, if there’s a problem with your .NET framework configuration, it could result in a crash or very difficult to troubleshoot error message. 2> If I recall correctly, the way the Manage Add-ons dialog works does not interact well with .NET Framework addons, because the registration of those controls points at mscoree.dll as the implementing binary, and it’s not that binary that shows the publisher’s version information. This could lead to a confusing Manage-Addons user experience for such controls. 3> The side-by-side problem is that, prior to Dev10/.NET4, you can only have one version of the CLR in the process at a time. If the user has a BHO/Toolbar written against DotNet 1.1 (say) and thus the 1.1 CLR is loaded, a future attempt to load a control based on the 2.0 CLR will fail. This is essentially exactly the same issue as Raymond Chen talked about for the shell. Now, having said all that, using Managed Code for ActiveX controls is much less evil than using it for BHOs/Toolbars. Because ActiveX controls are typically loaded only by certain pages, and only on-demand, the performance/reliability and side-by-side problems are far less severe than for those other extension types that are always automatically loaded by the browser on each tab startup.Anonymous
April 08, 2010
While this is promising on MS's front, I fail to see how their release schedule (a year out) can compare to an existing Safari/FF/Opera user base that has a much shorter release schedule (and lighter-weight payload). As you're read here, HwAcc is cropping up everywhere in the browsers, and it'll be out to market before the end of Summer (Opera, FF, Chrome). I know it's not the IE9 team's decision, but splitting this work out to a stable branch more often would give you a bit of credibility in these tests. If you're demo'ing prototypes, compare it to the others' prototypes as well.Anonymous
April 08, 2010
Microsoft as usual doesn't even test the latest Firefox 3.7 with Direct2D/DirectWrite GPU hardware acceleration. http://www.basschouten.com/blog1.php/2010/03/02/presenting-direct2d-hardware-acceleratio Or Chrome 5.0. http://googlechromereleases.blogspot.com/2010/04/dev-channel-update.html But they'll use IE9 in the test. Typical FUD.Anonymous
April 08, 2010
Wake me up when IE can do this. http://www.satine.org/archives/2009/07/11/snow-stack-is-here/ http://www.youtube.com/watch?v=3R6sb4NO25EAnonymous
April 08, 2010
Opera 10.50 isn't listed in these tests but in my own test runs it was the only browser to perform comparably to IE9, though it had visual errors when the items and zooms scaled up, and I'm not sure if this was due to the code or to the beta nature of the browser. Yes opera 10.50 is beta, but so is IE9 PP.Anonymous
April 08, 2010
Got a W3C standard based browser yet? No? Come back when you do.Anonymous
April 08, 2010
Versiera renders network maps of 10,000+ nodes using HTML 5 and canvas. Tests using SVG yields considerable slower performance. Our goal is to get to about 55,000 network nodes rendered in real-time. Please add CANVAS to IE9!Anonymous
April 08, 2010
whotroll: Serious people understand that "Standards support" isn't a boolean value. frank: Have you tried your "SVG tests" in IE9, whose hardware-accelerated SVG implementation is orders of magnitude faster? jeffrey: Opera already released 10.51 final.Anonymous
April 08, 2010
Since IE9 is for Vista and above I guess none of that new-fangled 2d hardware acceleration (HA HA HA HA HA) reaches poor old XP?Anonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
The Webkit based browser on Haiku OS proves that you don't need hardware acceleration though: http://www.youtube.com/watch?v=wMO1SqSmv3sAnonymous
April 08, 2010
This thing has Canvas support right? yeah yeah silverlight, blah blah, no thanksAnonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
there is no discussion with Microsoft possible, they use but don't release any source-code of their own. u say flame i say reasonable criticism. again come back when DirectX is open-sourced.Anonymous
April 08, 2010
Cool! Now, when can we expect to see a <canvas> implementation. ;)Anonymous
April 08, 2010
@Rafi: I'm glad to see someone with an open mind. I'd like a discussion. We've been looking for reasonable responses to X, Y and Z for while now. X. Does IE9 fix the behavior whereby an element with a transparent background becomes inaccessible unless the background-image is set to some graphic (generally a transparent gif)? Y. Is the IE9 JS garbage collector any more intelligent than the IE8's terrible implementation? (Admittedly, IE8 has one at least, whereas IE7 didn't, as far as we could tell.) Z. Does IE9 fix the undesired visual artifacts when setting opacity on 24bit PNGs having semi-transparent alpha data? These 3 items alone are known to be financially bruising to a great many web developers out there. I thank you in advance for your reasonable responses.Anonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
Thank you for the feedback. @Jawed, @Fair: Including all of the combinations of nightly builds and other browsers would have resulted in an extremely long blog post. In the future, as other browsers get further along with their support for hardware acceleration and become more stable, we’ll perform the same analysis against hardware accelerated browsers. It will be interesting to see how the different approaches to hardware acceleration impact overall performance. In the interim you can use the WPT tools linked to above to see how the different nightly builds and browsers perform on your hardware. @Matt: We test on a wide spectrum of graphics cards daily, and systems with Intel integrated graphics are seeing a significant improvement in graphics performance over software based rendering (non hardware accelerated browsers). Although you'll have better performance with a discrete graphics card, integrated solutions also fundamentally change the performance characteristics of the browser. @bcollie: The graphs show only the GPU activity for the browser itself (the brower processes). You will have a small amount of GPU activity from the operating system itself and other applications that might be running. It’s important to filter the GPU activity by process to understand how the application (process) itself is using the GPU compared to the operating system. @droid: All graphics will be hardware accelerated in Internet Explorer 9, including animated formats. @ Ovid Stavrica: The IE9 JavaScript engine has been designed from scratch and includes a new and efficient modern garbage collector. We’re in the middle of development and will share more details around that over time. The IE9 graphics subsystem has also been designed from scratch to support modern graphics and hardware acceleration. All graphics composition now take place on the GPU and the limitations with software based composition have been removed. Thanks again for the feedback and support (which we appreciate), JasonAnonymous
April 08, 2010
Now it would be great if IE would have visual studio like MEF extension manager.Anonymous
April 08, 2010
Apple is obviously doing some hardware acceleration on OS X: using Safari 4 on OS X 10.6, Flying Images gets 30-40 FPS (the latest WebKit nightlies are north of 60FPS with ~20% of one core) which is much better than the performance listed above. Chrome is barely changed at ~5FPS / 100% CPU, however, so the hardware is pretty similar.Anonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
@Jason Beautiful images. Going back to standards support and the future of the web ... and sorry to be off topic, i have a question about SVG: IE 9 preview currently implements 28% of SVG () Opera, Chrome, Safari and Firefox implement 94% , 87%, 82% and 72% respectively. What are your plans to the final IE 9 version? 30% 40% 95? Please can you share with us your goals with more precision? Thank you very much () http://www.codedread.com/svg-support.phpAnonymous
April 08, 2010
ombarg, you might want to read the page before you use it as a reference. From your link: "Now I know that I'm going to get complaints that the SVG test suite doesn't cover all functionality (I agree with you), nor does the score give a fair indication of other factors like performance (again, I agree with you), so please take this page as what it is: A data point from a guy who had too much time on his hands"Anonymous
April 08, 2010
I spent a couple days messing around with IE9 and I think it's a very well rounded approach covering many critical specs; though hardware acceleration is the icing on this cake! Having JavaScript and the rendering use different CPU cores in addition is really nice too. We should see IE9 without hardware acceleration for XP though. V/7's memory usage is wasteful and the GUI was destroyed requiring 2-5 times more clicking to use things like the start menu and Windows Explorer then in XP. Still even in a virtualized copy of Vista IE9 runs pretty smooth. But if the Windows team expects me to upgrade to 7 or actively use my copy of Vista I expect fixes to deal with the arthritis inducing GUI that took away many of the good aspects of XP. Not trying to be rude though that sort of stuff really does matter when you perform the same tasks sometimes hundreds of times a day. Good design is about minimizing steps to achieve a goal...and minimalism usually INCREASES the necessary steps to achieve goals, please keep that important concept in mind when you folks work on IE9's GUI. Any way keep up the good work! I'll be working on test cases in a few weeks once I finish Version 2.9.Anonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
Opera 10.51 is actually faster, smoother and more responsive with the flying images test than even IE9 preview. On my 3-year old laptop I get about 16-19 fps with 64 images on IE9 preview with 64 images. Chrome 4.1 gives me a paltry 1-2 fps. Firefox 3.6.3 is 7-11 fps. On Opera 10.51 I get 25-30 fps. Yay, Opera!Anonymous
April 08, 2010
Are there any planned updates to the IE developer toolbar(F12)? It seems awfully slow in IE8 and I dread having any IE only layout issues since my trusty firebug is useless. I imagine the hardware acceleration will help.. Also, it seems to stop working if there is bad markup in the page :(Anonymous
April 08, 2010
@miramardesign: You can try out the improved developer tools in the IE9 Preview Build; while they're not done yet, some of the functions are orders of magnitude faster than they were previously.Anonymous
April 08, 2010
The comment has been removedAnonymous
April 08, 2010
Runs at 60+ FPS on Firefox 3.6 for me as well. I question your study, Microsoft. Chrome is definitely 3-5fps, though.Anonymous
April 08, 2010
FireFox 3.6 flatlines at 19fps for me with 64 images.Anonymous
April 08, 2010
@jason (two up from here) what operating system are you using, and what graphics card?Anonymous
April 08, 2010
I'm getting 50 fps with Opera 10.51 and 256 images. steady 63 fps for 36 images... Radeon 4870 here and XP SP3 (LOL)Anonymous
April 08, 2010
ok - now that explorer is using the graphics card and winnning the speed dragrace why don't you add xhtml, modern javascript, threading, inheretence, and things that require actual dev brainwork instead of copying dx code from windows and pretending to add new feature. nice job doing nothing yet again.Anonymous
April 08, 2010
"developers can create new classes of web applications through standards based markup that were previously not possible" you're quite right. not previously possible because of IE! Instead of making pretty pictures fly around the screen... how about you work on getting a browser thats w3c compliant?Anonymous
April 08, 2010
If IE9 gets 100 points on acid3 test, I'll consider it.Anonymous
April 08, 2010
Flying pictures reminds me of the hype for DHTML support in IE4, back in 1998, and how you could do PowerPoint kinda stuff in the browser. It's funny how everything goes full circle. I don't understand why software rendering is so slow though. I'd expect a modern CPU to easily reach the fill-rate needed to animate a bunch of 2D images. I think we all forgot how to write fast graphics code. You could get better performance on a 486.Anonymous
April 08, 2010
Great work on IE9, I am watching this with interest. It is sad to see so many spiteful comments from the trolls. I hope you guys have a thick skin and keen coding, I know you'll keep proving the haters wrong.Anonymous
April 08, 2010
@dan: for the perspective of someone who has worked AGAINST IE for years now on stuff like XHTML and SVG, I must say that's what they're doing, more or less, now. However, it's far from complete: IE9's XML parser still doesn't raise a fuss if there's an error in an XHTML document. Other browsers (Firefox) do, and some others go further (Chromium 5) by enforcing DOM methods VERY strongly (you can forget about using innerHTML in XHTML documents with them). Now, a little bit of nuancing... IE 9 uses Direct2D and DirectWrite, which are MUCH better at uploading data to the screen than GDI ever was. They can do that because they don't DRAW forms, to make things simple they can 'blit' very, very fast. However, it doesn't make IE 9 THAT much faster outside of drawing: when Direct2D is disabled, IE 9 is much slower than Firefox (I'll take the following cases: a virtual machine, a first boot without proper driver, or Safe Mode) at, say, making a DIV follow the mouse cursor... Chrome and Opera are only marginally slower (if at all) while IE 9 lags as badly as IE 8 (interestingly, IE 7 was faster). So, there's still stuff left to optimize on the drawing side. Firefox doesn't reduce image quality on moving images: Gecko merely uses point sampling for CSS images. In many cases, images in CSS are used as interface complements (rounded corners, custom borders etc.) that get all fuzzy when zoomed with bilinear filtering, and more advanced algorithms are too much of a performance drag - as such , Firefox 3 by default draws images in tags with bilinear filtering on, and CSS images with filtering off, because in the latter's case, it more often than not looks BETTER to have hard edges than fuzzy ones. That it saves CPU time is also a nice bonus. About the interfaces used: IE 9 enjoys a very particular "feature", is that it doesn't try to make use of available accelerations:
- it doesn't use GDI (that's why there's no WinXP version)
- it doesn't use Quartz 2D, nor CoreAnimation (that's why there's no Mac version)
- it doesn't use xlib, meaning it doesn't use RENDER if available (that's why there's no UNIX version). In short, making IE faster is easier because it's simpler than other browsers. But, if we look at interfaces that are FASTER than GDI, let's say, xlib with RENDER available, well, Firefox 3.6 reaches 40 fps with 36 images on an Athlon64 X2 3800+ - not exactly a powerful machine. So, should the IE team be congratulated for making IE faster on Vista and 7? Maybe. Considering the challenge (removing ALL reliance upon GDI and switching to a new API, throwing backward compatibility out the window), I'm not so sure; seeing that it took a few developers at Mozilla a week to achieve pretty much the same thing (without forgoing backward compatibility), robs that achievement of most of its glamour. When Google developers do the same to Chrome in barely more time, make this look like old news. Now, let's put things more in perspective. The IE team not only accelerates pure drawing, but also object tracing: accelerated SVG in IE is still without peers, for one reason: SVG in IE is tailored to the Direct2D backend, and all operations that can be accelerated, are. If we take Mozilla's Cairo implementation, tracing an SVG form is done is software, and the only accelerated part is the compositing on screen. This is due to historical reasons (SVG in Gecko predates Cairo), but the day the Mozilla developers get around to beefing up their SVG implementation, and delegate more operations to Cairo (which already has an SVG backend), it's gonna fly there too. Even without Direct2D, if there is, say, an OpenGL driver around... I like IE 9, for the support to standards it provides. It can still get better (see XHTML + XML DOM conformance above). I like IE 9, for its speed. It could be much, much better (see software-mode Direct2D gripes above). I hope future versions will improve on both points.
Anonymous
April 08, 2010
Nice work but I'm still waiting for Microsoft to focus on real industry standards...Anonymous
April 08, 2010
[quote] Nice work but I'm still waiting for Microsoft to focus on real industry standards... [/quote] Which standards do you mean? HTML5, CSS3.. they are all no standard (yet)Anonymous
April 08, 2010
more griping from mitch, how boring and misleading. FACT: IE9 is faster at sunspider than FF3.7, even without d2d. FACT: Pretending like "safe boot" or "running without a driver" are valid scenarios is disingenuous, as usual. FACT: Anyone can run the demo themselves and see that the image quality in ff is inferior, regardless of any claims mitch might make. FACT: Tests of ff3.7 from his fellow commentors (and from the ff developers themselves) prove that their acceleration isn't ready for prime time (it's not on by default, it doesn't work with many drivers, and it crashes a lot). FACT: mitch disingenously implies that their implementation (which took them more than a week, btw) doesn't "forgo" backward compatibility while their page has a partial LIST of all the ways that it really does (prolly part of the reason it's not on by default) FACT: the ie team already have said the fact that their xhtml parser doesn't presently abort on errors is simply a limitation of preview #1 and will be fixed.Anonymous
April 09, 2010
I am using Mac OS X 10.6, Snow Leopard. The GPU is old ATI Radeon X1900XT. Safari 4 and Firefox 3.6, both can achieve 60 fps. Chrome 5 can only get 2-3 fps. Interesting, IE9 or Windows has a long way to go.Anonymous
April 09, 2010
Uh, LJ, "long way to go" meaning: "IE9 is already 20 times faster than Chrome, and the since the demo only tries to get to 60fps, there's no way to compare Safari and IE9 results since they both max out"? Yeah.Anonymous
April 09, 2010
The comment has been removedAnonymous
April 09, 2010
@Todd by being an "enterprise web developer", I assume you coded for IE6 your entire life. having to code for the rest of the world doesn't seem an issue to you, because you do intranets with that odd browser. So you have no idea how far and evil microsoft went for all these years, ignoring that freakshow that was IE6 and IE7 is still widespread, and they yet have the oportunity to repeat the same thing again (starting from Windows 7 of course). They are trying to manage a way to go against the standards, implement their own proprietary version of stuff (3D, their own "canvas", etc), so every "enterprise web developer" thinkgs its awesome and neat, amateurs will find IE is easier to code because of sloppy javascript proprietary functions, ends up joining the band wagon, and there we go 2001 once again.Anonymous
April 09, 2010
The only company doing "proprietary 3D" stuff is Apple (and they're asking the standards bodies to bless what they've done). Microsoft hasn't done anything with 3D, and hasn't announced support for canvas, so claiming that they'll have their "own" is just trolling.Anonymous
April 09, 2010
argumentum ad populum Matt, just a matter of time. just note how they are trying to amaze you with shiny spinning images and biased and distorted benchmarks. if they were real about it, they would be going to match prototype vs prototype, not final vs prototype. They actually did it with Internet Explorer 6, why wouldn't they do it again? See how distracting this whole D2D graphics were, instead of improving what really matters, HTML5 and CSS3. Implementing something doesn't mean it works in production. CSS 1 was "implemented" in IE6, did it work? Same thing for CS2 in IE7. and so on.Anonymous
April 09, 2010
Menas, you need to learn your history and your technology. Internet Explorer 5.0 for the Macintosh, shipped in March 2000, was the first browser to have full (better than 99 percent) CSS1 support. Direct2D accelerates HTML5 and CSS3. Why bother doing either if they're too slow to use? >why wouldn't they do it again IE6 had no real, strong, competitors. IE9 has several.Anonymous
April 09, 2010
The comment has been removedAnonymous
April 09, 2010
@Will > FACT: IE9 is faster at sunspider than FF3.7, even without d2d. Which version of sunspider: 0.9 or 0.9.1? Which revision version and build number of FF 3.7: alpha 2 or today's nightly firefox-3.7a5pre? How much faster? half of a second? 1 tenth of a second?? 1 hundredth of a second??? 5 msec???? What's your PC configuration (memory, cpu, video card, etc), etc.? A "FACT" is something that anyone can verify, reproduce, compare, measure, especially in the world of web browsers. A "FACT" should not be an opinion, a wish or some kind of commitment to accomplish in the future. A "FACT" is best gathered, realized and presented as admissible by an independent party seeking the truth like a judge in a court of law or a scientific comittee. When I examine the graph http://ieblog.members.winisp.net/images/Dean_MIX10_2.png , I can not even see how faster IE9 preview is compared to Firefox 3.7 alpha2. And the data provided by Microsoft mentions a 12msec differential between Fx alpha2 and IE9 preview 1. 12msec is more like a photo-finish issue to me: 12msec is not comparable for an human and is barely noticeable. If that is what you call faster, then what about the 3125msec of difference between the IE8 RTW and Firefox 3.6. There is a difference of order of magnitude here. > FACT: the ie team already have said the fact that their xhtml parser doesn't presently abort on errors is simply a limitation of preview #1 and will be fixed. Then it's not a "FACT". It is just an announcement. A to-do item. You confuse a "FACT" and an announcement. You present such announcement like it's a "done thing" but it is not. We have good reasons to not gobble anything and everything IE Team, MSDN and Microsoft marketing say and claim and have been saying. Not just about application/xhtml+xml but on security, on SVG testing, on CSS2.1 compliance, HTML 4 conformance, on so-called "Professional-grade" testcases, on DOM 2 style testing, etc. We have the right to be vigilant, thorough and critical of IE Team posts in this blog. Especially about their testings and their testcases and the "conclusions" they reach from their testings and their testcases. IE8 fails over 150 testcases from the CSS2.1 test suite (alpha 2; march 16th 2010). And anyone can verify this for him/herself. Gérard TalbotAnonymous
April 10, 2010
@EricLaw As you have mentioned the garbage collector as a piece being reworked, I wonder if I should file a bug about IE9 not cleaning up memory in a complex app. I know that it's better to provide simplified testcases, but I tried and I messed it up badly and now I don't have enough time to create a simple test. In any other browser the test runs correctly and in the long run there's very little increase of memory usage, but IE9 eats memory like if nothing was being cleaned up (as I said, simpler tests work correctly).Anonymous
April 10, 2010
@Alfonso: Yes, we're making major investments in the script engine in IE9. If you have any test case that reproduces the problem, please do file a bug. Obviously, simpler testcases are better, but we'll take whatever we can get. Thanks!Anonymous
April 10, 2010
I think you conveniently left out Opera since it can hit 60+fps without using an entire core even on a machine with much lower specs than your workstation. P.S. You should be using the newer Opera logo from the press resources area of there site.Anonymous
April 10, 2010
Results seem a little disingenuous. I'm getting 60 fps and lower CPU usage than the stats listed above for IE9 and I'm using Safari 4.0.5 on OS X 10.6. Did you decide to only run the test on 10.5? It would be more honest to compare IE9 to at least the most recently released OS/Browser combination, if not the nightlies/betas for each.Anonymous
April 10, 2010
The comment has been removedAnonymous
April 10, 2010
DK: They never said they ran on OSX at all.Anonymous
April 11, 2010
The comment has been removedAnonymous
April 11, 2010
When you turn on Firefox hardare acceleration yet just get a solid white screen. That doesn't seem very along.Anonymous
April 12, 2010
@Chrome User: "When you turn on Firefox hardare acceleration yet just get a solid white screen. That doesn't seem very along." I encountered that problem in a recent nightly build when I first load a page. It seems to go away if you switch to another tab and back. Support for D2D in Minefield is certainly glitchy, but it's not totally unusable. While I don't have any benchmarks for you, my experience is that the most recent nightly build of Firefox with D2D enabled is faster than the IE9 Testdrive for SunSpider and roughly equivalent in performance on most of the Testdrive tests on the web site. The biggest performance issue I can see at the moment is that it's a bit slower (but faster than 3.6) with some of the SVG stuff like SVG-oids "Nebula mode", but you could argue that Canvas 2D is a better fit for that use case.Anonymous
April 12, 2010
The comment has been removedAnonymous
April 12, 2010
The comment has been removedAnonymous
April 13, 2010
It doesn't matter because IE9 is extremely fast and that's all that matters for the people who surf the web daily. Keep up the good work IE team.
