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 demo.  There are lots of different browser icons which circle around the screen and follow your mouse.

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.

Timeline of CPU usage, GPU usage and Frame updates.  In IE8, the CPU timeline shows it being continually at about 50% usage, there is no GPU usage and the fram updates occur twice over half a second.

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.

Timeline of CPU usage, GPU usage and Frame updates.  In Chrome 4.1, the CPU timeline shows it being continually at about 50% usage, there is no GPU usage and the frame updates occur twice over half a second.

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.

Timeline of CPU usage, GPU usage and Frame updates.  In Safari 4.0.5, the CPU timeline shows it being continually at about 50% usage, there is no GPU usage and the frame updates occur twice over half a second.

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.

Timeline of CPU usage, GPU usage and Frame updates.  Firefox 3.6 continually uses 50% CPU, no GPU and has 8 frame updates oer half a second

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.

Timeline of CPU usage, GPU usage and Frame updates.  In IE9, the CPU goes up to about 50% usage and then down to zero usage 33 times over half a second.  There are visible gaps in the CPU usage when it goes down to zero.  GPU uses also has spikes of usage which go up to 100% approximately 33 times over half a second.  There are 32 frame updates over half a second.

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 (126)

  1. Anonymous says:

    @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.

  2. Anonymous says:


    The Dev channel has been updated to 5.0.371.0 for Windows, Mac, and Linux.

  3. Anonymous says:

    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?

  4. Anonymous says:

    How did you bastardize the Opera logo?

  5. Anonymous says:

    And if I read "interoperable/interoperability" once again, I will kill a kitten myself

  6. Tihiy says:

    That’s all good and cool, but DirectWrite text rendering sucks balls.

  7. Anonymous says:

    >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?

  8. Anonymous says:


    Beautiful images. ie9 very goog performance…

  9. Anonymous says:

    @Gérard: thanks for defending me. I’ll take over now.

    @Will: a simple scenario. You’re a web developer. You develop primarily for a LAMP stack, so your development machine IS a LAMP machine. To test under IE 6, 7, 8, and 9, you need:

    – either 4 extra rigs that do nothing but run IE 6/7/8/9,

    – or a few virtual machines. Which don’t have 3D acceleration available. Nope, not even in MS VirtualPC.

    So, the irrealistic scenario is found with this very small, uninteresting, useless band of Web users: DEVELOPERS! DEVELOPERS! DEVELOPERS! DEVELOPERS!

    SO, let’s play it YOUR way:

    FACT: Firefox 3.6 is slightly faster than Jscript 5.9 at Sunspider on single core machines. Not everybody use a dual,tri, or quad core for browsing the Web. Chrome and Safari are still ways ahead. If you developed for the Web, you’d know it.

    FACT: Firefox 3.7 uses point sampling for CSS image zooming. It doesn’t degrade an image’s quality, but its filtering. Degrading an image’s quality for performance reasons would be resampling the image to use less RAM, reducing the color palette… You can make Firefox use bilinear filtering, but then you’ll notice all those images used in CSS for interface elements suddenly looking fuzzy when zoomed. If you developed for the Web, you’d know it.

    FACT: Internet Explorer 9 isn’t ready for prime time either. It wouldn’t be a Developer Preview otherwise. If you knew how to read, you’d know it.

    FACT: Firefox 3.7 nightlies run on WinXP, and also on Vista/7 with D2D enabled. IE 9 does not, and will not, run on XP. If you knew how to read, you’d know it.

    FACT: current IE 9 builds don’t abort on XHTML errors, and don’t abort when innerHTML etc. modify an XML DOM. Before both issues are addressed, progress has to be made. I never said otherwise. If… Well, enough beating on a dead horse.

    AND, since obviously you can’t read, I will now say with short words and simple sentences so that you can understand.

    I like IE 9 preview a lot. It catches up on other browsers in many ways. There are still parts of it that need to get better. Other browsers are catching up where IE 9 got ahead, so IE developers must not let up.

    Simple enough?

  10. Anonymous says:

    I really wonder if there’s anyone who had to mess with ie6,7,8 and still gets excited with news about pimping this braindamaged browser family.

    how about fixing 7 and 8 to comply with the standarts? how about making things work?

  11. Anonymous says:

    Shiny graphics won’t make IE any less broken, insecure, or any more standards compliant. Instead of actually FIXING all of IE’s problems, they’re just tacking on more crap.

    IE’s no closer to blowing away Chrome/Firefox than it was when they started coming around.

    How about you Microsoft developers stop wasting time with gimmicks stolen from other web browsers and just FIX INTERNET EXPLORER.

  12. Anonymous says:

    Hey IE team, why don’t you stick your heads out of your a$$es and just drop the whole fvcking IE lameness, else we will have to use Chrome Frame forever


  13. Anonymous says:

    Hey IE team, why don’t you stick your heads out of your a$$es and just drop the whole fvcking IE lameness, else we will have to use Chrome Frame forever


  14. Mike says:

    The work that you guys are doing on 9 is amazing amazing amazing. We’ve been building comps all month using the preview and it’s ridiculous how fast this thing is! We have a patchwork collage comp that lets you navigate hundreds of images and zoom into individual images through script. It’s like silverlight deep zoom. We’re seeing 100 times performance in IE9 compared to FF and Chrome5! Once 9 comes out we would like to stop using Flash and move to HTML5 since it’s much simpler and faster. Please hurry up and ship this thing with more CSS3 and video support and everyone will love you again! It’s not posssible for you to ship this soon enough! Please please please!

  15. Philip Kahn says:

    No idea if you guys saw this … but on Engadget, they link to a (beautiful) April Fools mockup for IE9. Just thought I’d point you guys to it, in case it somehow had an impact on this or future IE design: http://www.engadget.com/2010/04/07/internet-explorer-9-going-all-metro-according-to-allegedly-leak/

    On topic, though, I should point out that Opera performs quite well, actually (10.51) on this test, and it would be worth including in your discussion.

  16. dlh2009 says:

    @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.

  17. infinte says:



  18. Aaron Carlson says:

    That’s interesting.  Are you looking into switching to managed code for IE9?

  19. Joe says:

    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.

  20. 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.

  21. Nicolas says:

    Very cool graphs. I’ve been impressed with the performance of IE9 on my machines. My laptop with Intel onboard Graphics is just as fast as my desktop with 1GB NVIDIA GFORCE. You blow away Chrome and FF on everything. I’m sure that Google is running around trying to decide how to keep up. I’ll probably switch once you actually ship. Nice work gents!!!!

  22. Greisha says:

    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.

  23. Rob says:

    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.

  24. EricLaw [MSFT] says:

    @Aaron: No. To use managed code in IE, you can author against Silverlight.

  25. Justin L. says:

    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.

  26. Not Telling says:

    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.

  27. Damian says:

    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.

  28. Damian says:

    P.S: How to enable hardware acceleration on Firefox for future testing: http://www.basschouten.com/blog1.php/2010/03/02/presenting-direct2d-hardware-acceleratio

  29. Christopher Austin (SF) says:

    @Microsoft: I admit that I’ve launched the IE9 test drive several times only to play with the flying images. Hardware acceleration will change how we build, use, design, and think about web applications. Congratulations to everyone on the IE team. Add a decent canvas implementation and you’ll win over this long time dedicated Firefox guy.

    When is the beta?

  30. Christopher Austin (SF) says:

    Will SVG be hardware accelerated? That would be sweeeeeet!

  31. balsampear says:

    dbclick(is float bug?):



    my mail:


  32. Savil says:

    @Christopher Austin — Yes, SVG is hardware accelerated.

  33. bp says:

    at ie8 and ie9

    dbclick(is float bug?):



    my mail:


  34. GSP says:

    Thanks for the detailed analysis. You’re off to a good start with IE9.

  35. Kim says:

    I’m very impressed! Now just kill IE 6-8 and we’ve got the web back on track! ;)

  36. Marty says:

    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.

  37. Ryan says:

    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?

  38. Julian says:

    Trying flying images in Internet Explorer 7, it ran 256 images at an acceptable 26fps.  

  39. someone says:

    When is the end of support for IE6 on Windows 2000 and IE8 on Windows XP SP3? June 2010 and April 2014?

  40. anonymous says:

    On one side, Silverlight 3.0 with accelerated graphics is available for Windows 2000 and on the other side IE9 won’t support XP?

  41. Jawed says:

    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.

  42. Fair says:

    All major browsers have implemented hardware acceleration in their current alpha/beta releases. Why don’t you compare IE9 to those? This kind in sneaky and misleading advertising really confirms how MS is still up to no good. Play fair FFS! That’s all I ask.

  43. Voter says:

    +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.


  44. Thomas says:

    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.

  45. Wurst says:

    You should have also tested the current Firefox 3.7 nightly with D2D/DW rendering enabled…


  46. sevenflavor says:

    Does using DirectWrite means ClearType will now be enforced in IE9? Can I be rest assured that ClearType can be turned off?

  47. hAl says:


    It seems Opera also reduces the images quality to gain extra frames (simlar to Firefox).

  48. Eric Wilson says:

    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.  

  49. DK says:

    I can’t get the FF 3.7 beta to work with D2D. It crashes and runs SLOWER than FF 3.6.

  50. Wurst says:

    I remember reading that Firefox has a proprietary CSS property for defining the scaling mode.

  51. Matt says:

    what a crock. Really, why not try a: using something non-proprietary (openGL) for acceleration and b: try not becoming *more* resource intensive?

    hardware acceleration is not going to help people using intel graphics.

    Way to ensure that this will not pave the way for anything.

  52. Matt says:

    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.

  53. bcollie says:

    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!

  54. Paulo Canedo says:

    I can run this sample with 60fps on my firefox 3.6.3 (linux).

  55. SMS says:

    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.

  56. Will Peavy says:

    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.

  57. timeless says:

    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.

  58. Mark says:

    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…


  59. James Gentile says:

    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.

  60. droid says:

    Hey IE Team, Great job on the HW accell.


    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.


  61. droid says:

    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.

  62. Yancey says:

    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.

  63. EricLaw [MSFT] says:

    @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.

  64. Jim Mugn says:

    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.

  65. Open Web says:

    Microsoft as usual doesn’t even test the latest   Firefox 3.7 with Direct2D/DirectWrite GPU hardware acceleration.


    Or Chrome 5.0.


    But they’ll use IE9 in the test. Typical FUD.

  66. Jeffrey Gilbert says:

    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.

  67. WhoDat? says:

    Got a W3C standard based browser yet?  No?  Come back when you do.

  68. Frank says:

    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!

  69. Matt says:

    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.

  70. Maurice says:

    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?

  71. Young Geezer says:

    What has the web turned into? Does anyone stop and question why we need GPU support for a web browser in the first place? Keep in mind that this isn’t a movie, and it isn’t a Java app. It’s a horrible site that’s so css/javascript heavy it makes computers slow to a crawl. Somehow, amazingly, IE9 does okay on it.

    Why don’t you work on getting SVG, CSS2, MathML, DOM, HTML5, and XHTML in IE 7-8? Or removing ActiveX and the OS-entrenchment so we can all have a safer Internet? Or Passing the Acid3 test? No? Because that wouldn’t be all fun and showy?

    Oh wait, IE9 doesn’t even support these things correctly or pass the Acid3 test either – 55/100 isn’t impressive. In school that’s called an "F."

    At least when it’s done, we’ll be able to use IE9 on every Windows computers we have, so we’ll eventually be able to view the web like the rest of the world. Whoops. IE9 won’t even be available on XP.

    As a web developer and designer, I would much prefer an IE that respects open web standards than one that can render crappy websites really fast.

    Good job, guys.

  72. 48fps says:

    The Webkit based browser on Haiku OS proves that you don’t need hardware acceleration though:


  73. LOVE_MOSS_NOT says:

    This thing has Canvas support right? yeah yeah silverlight, blah blah, no thanks

  74. Rafi says:

    I just read the entire page of comments and as an intelligent, fair-minded person I’m amazed at the lack of a reasonable discussion here.  

    Most of the critical posts resemble "You suck because of X Y or Z" and in every case, anyone willing to spend 3 minutes thinking about it with an open mind, can come up with reasonable responses to X, Y, or Z.  I know this has become the norm in our industry but it just kinda bums me out.  Everyone is more interested in the flame rather than having a real discussion.

  75. mark simon says:

    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.

  76. Ronald says:

    Cool! Now, when can we expect to see a <canvas> implementation. ;)

  77. @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.

  78. James Gentile says:

    @Young Geezer,

    it sure gets tiresome dispelling the exact same fud everyday…

    IE8 had the best CSS 2.1 support at it’s release.

    A lot of these standards are not finished and are subject to change, html5 is not due to be standardized until 2022 (that’s twenty twenty two) for crying out loud? As soon as MS implements it as is today, and it changes tommorow, you guys will be screaming embrace extend extinguish on every blog/forum and accusing MS of breaking "teh internetz".  If you want to be mad at someone, why not be mad at w3c for moving so ridiculously slow? If these standards were finished, MS could implement them.  

    Also, You thinking that acid3 corresponds to anything, really, equals fail.  The author of acid3 himself has admitted the test does not do a representative test of the standards, it’s utterly useless and random.  You can have good html5, css, svg and still fail acid3, or vice versa.  Hardware acceleration is great for new unimaginied as of now scenarios, abusing MS for implementing it is done right daft. Get a grip and drop the fud.

  79. Jason Weber [MSFT] says:

    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),


  80. Prabir says:

    Now it would be great if IE would have visual studio like MEF extension manager.

  81. Chris Adams says:

    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.

  82. IBall says:

    That’s pretty neat. You’re right, even Chrome slows to a crawl.

    Funny you didn’t bother to test Opera 10.51, it flies even on my really old AMD box running XP.  I’m getting 60+ FPS.

    IE 9, you guys still got a lot of catching up to do…

  83. ombarg says:


    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.php

  84. Matt says:

    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"

  85. 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.

  86. Brian says:

    So far bad SVG support and poor acid 3 results.

    At this rate of innovation IE14 will be worth trying out!

  87. Nusi says:

    I am glad that MS is making IE9 faster. This will surely have a positive impact on all cases where I have to use IE as a html browser, or where the OS’s native html/JS rendered is used. Afaik, this happens mostly in MS own apps.

    Unfotunately, I have the impression, that using DirectX is just a hack to get around limited JavaScript engine. Although you are making it faster with this step, you might not forget the the competition is able to use hardware rendering AND has a good JavaScript engine.

    Looking at IE history and IE release cycles, it is very likely that the competition will release a hardware rendered browser far earlier than MS releases a final IE9. And then it is ‘back to drawing board’ for the IE team – with very demotivated devs.

  88. Jammrock says:

    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!

  89. miramardesign says:

    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 :(

  90. EricLaw [MSFT] says:

    @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.

  91. Matt says:

    "I have the impression, that using DirectX is just a hack to get around limited JavaScript engine"

    if that is your impression, you should do some research. ie9 has a new JIT’ing JavaScript engine which is faster than Firefox 3.6’s and 3.7’s.

  92. Jason says:

    Runs at 60+ FPS on Firefox 3.6 for me as well. I question your study, Microsoft. Chrome is definitely 3-5fps, though.

  93. Gary says:

    FireFox 3.6 flatlines at 19fps for me with 64 images.

  94. Joe says:

    @jason (two up from here) what operating system are you using, and what graphics card?

  95. Opera says:

    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)

  96. pibby says:

    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.

  97. dan says:

    "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?

  98. Thai says:

    If IE9 gets 100 points on acid3 test, I’ll consider it.

  99. raffi says:

    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.

  100. Downunder says:

    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.

  101. Mitch 74 says:

    @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.

  102. Bill Myers says:

    Nice work but I’m still waiting for Microsoft to focus on real industry standards…  

  103. ao says:


    Nice work but I’m still waiting for Microsoft to focus on real industry standards…  


    Which standards do you mean?

    HTML5, CSS3.. they are all no standard (yet)

  104. Will says:

    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.

  105. LJ says:

    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.

  106. Math says:

    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"?


  107. Todd says:

    As an enterprise web developer, I can see quite a few uses for this. Very cool! I can’t wait. I love thinking of the cool UI I can do with this.

    Hmm… I find all the fanboi comments a bit amusing. If other browsers are doing better, then awesome. Without feeling threatened, try to make suggestions / comments on what is actually good / bad about IE 9 and where it is going. Some of you seem a bit uninformed and a bit wild eyed.

    Giving useful feedback will actually help IE9 be a better product. I scratch my head at all the religious zeal. Technology is awesome. Personally, I want them all to do well. It certainly makes my job easier, lol.

  108. Fanboi? says:

    @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.

  109. Matt says:

    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.

  110. Menas says:

    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.

  111. Matt says:

    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.

  112. Menas says:

    "Internet Explorer 5.0 for the Macintosh, shipped in March 2000, was the first browser to have full (better than 99 percent) CSS1 support."

    you misread what I wrote. I said you can implement it, it doesn’t mean it will work. that’s the case in IE6-8. don’t know if you’re a professional webdesigner or not, but having a stylesheet for IE6, 7 and 8 is lame, or relying on javascript what should be done with CSS and HTML (won’t even mention XHTML 1.0 or 1.1)

    "Direct2D accelerates HTML5 and CSS3. Why bother doing either if they’re too slow to use?"

    Firefox, Safari, Chrome and Opera are slow to use? Final versions with demi support for CSS3 and HTML5, but at least DOES html 4 and CSS2.1 WELL, while any other IE couldn’t. learn your history ffs.

  113. @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 Talbot

  114. AlfonsoML says:


    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).

  115. EricLaw [MSFT] says:

    @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!

  116. toyotabedzrock says:

    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.

  117. DK says:

    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.

  118. Opera Pixels says:

    I’m also seeing 60fps with Opera but the images look terrible. Opera must either have bugs with the image sizing code or they’re cheating somehow to improve frames per second. Does anyone know how Opera resizes the images? IE9 seems to have the most crisp images. Opera the works. Firefox is somewhere in the middle.

  119. Bill says:

    DK: They never said they ran on OSX at all.

  120. Chrome User says:

    Opera seems pixelated on both OSX and Win7. They’re cheating but the images are moving so quickly that it’s hard to see the damage.

  121. Chrome User says:

    When you turn on Firefox hardare acceleration yet just get a solid white screen. That doesn’t seem very along.

  122. Matthew Raymond says:

    @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.

  123. Reality Check says:

    OpenGL is the industry standard and only accepted system for high performance 2D/3D graphics. Building on Microsoft Windows only proprietary systems is a short sighted decision that you will regret. You have time to correct this before IE9 ships in 2012. Please consider this before IE9.

  124. David says:

    @Reality Check: If OpenGL is the "only accepted system for high performance 2D and 3D" … why are many (most?) Windows games written to use DirectX? What makes you think IE9 is 20 months away (that would be Jan 2012)? Why on earth would you write against OpenGL when the core technology, guaranteed to be present, is DirectX?

    At everyone else – why is the focus on Acid and other corner case tests? The real problem seems to be that the specs can be misinterpreted, or simply take too long to get to the "approved/released" stage. See also the W3C comments about HTML5 being 2022 for "Recommendation" (vs 2010/2011 for candidate recommendation): http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F

  125. Doesn't Matter says:

    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.