A GPU-Powered Shopping Experience with Amazon.com


A few weeks ago, we talked about the performance characteristics of our Flickr Explorer sample. We showed how hardware acceleration benefits real world scenarios such as browsing photos, and how easily web developers can build these types of applications.

Recently, we released a new set of demos alongside the third IE9 Platform Preview. Today we’re going to discuss the Amazon Shelf concept application (also see the companion Channel 9 video).

Much like Flickr Explorer, Amazon Shelf is written using standard HTML, CSS and Javascript. Amazon Shelf also incorporates a key new HTML5 feature – the canvas element. Canvas is an incredibly powerful way to draw directly to the screen using simple Javascript API calls.

When you launch Amazon Shelf, you’re shown a list of the top selling books from Amazon. This data is retrieved using the Amazon Product Advertising API. You can search for specific books, browse, and “open” books to view detailed information and customer reviews.

This demo uses common patterns that you find across many interactive web applications and games. There is one main loop that updates the books and other objects on the screen, and performs simple hit testing to support interacting with the elements on the canvas.

IE9 Platform Demo – Amazon Shelf

Canvas, like all graphics in IE9, is fully hardware accelerated by default. When IE9 users browse to a website that uses canvas, IE will automatically leverage the full capabilities of the PC to provide a great experience with levels of performance not possible with today’s browsers. Using IE9, Amazon Shelf is generally able to maintain a responsiveness of 60 frames per second, which is considered realtime. Today’s browsers are only able to achieve framerates of 1-8fps which is a small fraction of the performance provided by IE9.

We recently blogged about using the Windows Performance Tools to analyze browser performance. Using these tools, we’ve taken some measurements of loading Amazon Shelf in the top browsers available today. We used the same hardware and methodology discussed in the past. Let’s look at the CPU and GPU activity graphs to better understand how the demo performs in these browsers.

Note: Internet Explorer 8 is not included in this comparison since it does not support the Canvas element.

First up is Chrome 5. Chrome is able to update the screen once every 0.99 seconds, yielding a frame rate of about 1 FPS during the bookshelf load animation. This results in a very slow, choppy experience. One core on this dual core machine is fully utilized, and the GPU is not employed by the browser at all.

Amazon Shelf performance graph in Chrome 5

Here are the results for Safari 5. During the load animation, Safari does not attempt to render the scene at all, resulting in an effective 0 frames per second. Again, one core on the CPU is fully utilized and the GPU remains untouched.

Amazon Shelf performance graph in Safari 5

Next up, Firefox 4 Beta. We used Minefield 4.0b2pre nightly for this analysis. Again, our tests ran this latest nightly build of Firefox (like all the others) in the default configuration. This means hardware rendering with the GPU was not enabled in Firefox.

Here are the results for Firefox. The animation is rendered properly, and the screen is updated twice every .25 seconds, yielding a frame rate of about 8 FPS.

Amazon Shelf performance graph in Firefox 4 Beta

Finally, let’s take a look at Internet Explorer 9 Platform Preview 3. We see that IE9’s full usage of the GPU results in a steady, smooth frame rate of 60 FPS. The CPU handles the task without any trouble and rests frequently while the GPU renders Amazon Shelf to the screen.

Amazon Shelf performance graph in IE9 Platform Preview 3

There is a meaningful difference in the experience when running the demo in IE9 compared to other browsers. Check out Amazon Shelf on www.ietestdrive.com to see for yourself.

We’d like to thank Amazon for their help in putting this demo together, and embracing the new GPU powered, standards based markup enabled by Internet Explorer 9.

Our team can’t wait to see what other graphically rich experiences web developers armed with hardware accelerated Canvas will dream up!

Seth McLaughlin
Program Manager for IE Performance

Comments (56)

  1. Very cool says:

    Poor Amazon is stuck though, just like the rest of us supporting IE6 still.  It will be another decade to wait until IE9 is the lowest common denominator and sites like this will be acceptable to business across the board.

    Better late than never I guess.

  2. Mark says:

    Most sites don't develop only for the "least common denominator"– they support progressive enhancement. In this case, that would mean that you only offer "Amazon Shelf" view to browsers that support it. This would take a competent web developer about 5 minutes.

  3. William says:

    > This means hardware rendering with the GPU was not enabled in Firefox.

    Why don't you turn it on?

    http://www.basschouten.com/…/presenting-direct2d-hardware-acceleratio

  4. Adrian says:

    Nice.  IE9 is looking to be a huge improvement over IE8.  I'm looking forward to writing HTML5 websites.

    I'm curious to see what you do with the UI.  I'm hoping for something like the TwentyTen theme in Firefox.  Just replace the Home tab with your Quick Tabs, then add the Back/Forward/Home/Favourites buttons into the Quick Access Toolbar, so that you can do most browsing with the ribbon collapsed to save room.  You could also move the address and search bars into the title bar, since the title of the page is already available on the tab.  Then you could have the favourites bar, find-on-page bar and third-party toolbars in the ribbon area.  You could then click on the File ribbon tab to access the Back Stage similar to Office 2010 with an option to save the website to your computer, print/print preview and see recently/frequently viewed websites.  I'm guessing you've probably already got the UI all designed by now, but I thought I'd present my idea anyway.

  5. Cedric Dugas says:

    IE9 look really amazing, but I don't know who you are trying to fool with your 60fps…

    they are all working on hardware acceleration, when it's enabled everyone will be at 'mostly' the same speed,

    and all developers know this,

  6. Bill Gates II says:

    @William: The reason they don't is that they're compare the browsers with no tweaks at all, and having to change a setting counts as tweaking. If Mozilla makes hardware acceleration on by default then they'll compare using it.

  7. Jason says:

    The Firefox 4 beta with hardware acceleration crashes a lot which is why Firefox hasn't turned it.

  8. koppah says:

    They should still be comparing it with it enabled. It's misleading – they're already comparing betas to alphas etc., so why not just enable it?

  9. happok says:

    If Mozilla doesn't feel comfortable enabling it by default even on a beta, why should anybody else?

  10. Crafty says:

    What I wonder more is why wouldn't they compare it to something that is both fast and stable – Opera 10.60

    Currently, one of the faster, if not the fastest browser.

  11. JonJon says:

    Nice! Internet Explorer 9 is clearly shaping up nicely. I hope it will take over previous IE version rapidly so we can use all those wonderful features to build more complex web sites.

    On a side note, you might want to try 7capture to take better looking screen shots: it's free and can remove the background behind transparent windows. http://www.7capture.com

  12. Hans Gruber says:

    Comparing non-GPU rendering to CPU only rendering is a completely meaningless test. Thank you for wasting all of our time.

  13. fr says:

    It would be fairer to test Chrome 6, although the result would probably be similar at present.  Would be nice to know why Opera is always left out of these tests, is it because you don't want everyone to know it performs quite well on most of your tests without hardware acceleration?

    Also on the subject of performance it would be interesting to have an article about the Peacekeeper benchmark and why IE9's score is still pretty low compared to other browsers.

  14. Allvery Coolbut says:

    This is all very cool but you are omitting an important detail.  Other browsers render this Amazon app slowly… but the 3 current, shipped versions of IE in the market can't even render it PERIOD!

    Bragging about how your new, yet to be released, only available on Vista/Win7 browser that is still chromeless and has no navigation options is all very good but this is all vaporware until:

    a.) IE9 actually ships

    b.) IE6, IE7, & IE8 are dead

    Considering that there are sooo many users still stuck on IE6 (we're talking about a 10 year old browser here!) it will be 2019 before all previous versions of IE die (presuming that IE6 does actually die this year, and the other browsers live the same length of time)

    I so very much hope that IE9 gets picked up rapidly by all windows users – but I see IE9 as only a glimmer of light at the end of a very, very dark tunnel called "Its been 10 years since IE6… we should be on a shipped IE11 version by now"

  15. Mitch 74 says:

    Me, what bothers me about this is the matter of accessibility: CANVAS text, as seen here, can't be selected – and even less, read by a screen reader. It will also blur the fonts if zoomed (instead of making them bigger, a bit counterproductive) – as the text is rendered as images scaled to the 'virtual' pixel grid of a zoomed page, making it unreadable.

    Using CANVAS for this kind of use is Not A Good Idea ™. This demo falls into the category: "nice looking toy".

  16. Brian says:

    I agree with others: you should compare with other GPU-enabled browsers.

    So let me add my data.

    Internet Explorer 7, no GPU: 0 FPS

    Internet Explorer 8, no GPU: 0 FPS

    Firefox 3.6.6, no GPU: 15 FPS.

    Firefox 4.0b2pre, GPU-enabled: 30 FPS

  17. SS says:

    Excellent job IE team! I really can't wait to use IE9.

    Btw, I tried it on my ATI Mobility Radeon HD 3470, but it didn't seem to get hardware accelerated. I saw a few other people raising similar issues in MS connect.

    Another request from me is please share this great work with the IE mobile team.

  18. *Confidential* says:

    I agree with most of the posts above in that you need to start including Opera in these comparisons. Or atleast show us how IE9's software renderer competes with Opera's for all those out there with integrated graphics.

  19. badger says:

    @SS   Yes, I agree. I would like to hear more about a better IE mobile strategy. IE9's release will likely come on the heals of the Windows Phone 7 release and more than a year after IE8's release. Yet, the WP7 browser will be "halfway between [the] IE7 and IE8 rendering engine.*"  While it has been stated that the browser of WP7 will be updated at a faster clip than the WP7 OS itself**, it really just will be too little too late if we get an IE mobile update that's halfway between IE8 and IE9 2 years from now.

    These new mobile devices are increasingly graphically capable. They are screaming to take advantage of these new improvements we're seeing for IE9. However, I believe the stated hardware requirements for WP7 devices is to be DirectX9 compatible. Which, if my version memory is correct, would not have support for Direct2D and DirectWrite. So what does that mean in terms of the prospects of getting a standards-compliant mobile browser on WP7?

    *news.cnet.com/8301-13860_3-10452710-56.html

    **blogs.msdn.com/…/update-css-and-js-support-in-ie-mobile-for-windows-phone-7.aspx

  20. GPU says:

    MS are cowards for not turning on Firefox 4.0's Direct2D and DirectWrite GPU hardware acceleration as usual.

  21. C6 says:

    So it's ok to use a pre-release version of IE but not ok to test Chrome 6.0? Nice bias there.

    googlechromereleases.blogspot.com/…/dev-channel-update.html

    "The Dev channel has been updated to 6.0.453.1 for All platforms."

  22. Matt says:

    Yes, they are cowards. They should turn on D2D in firefox and experience all of the crashes like real men. And the Firefox team are weaklings for not turning it on and crashing all of their users too!

  23. Ali says:

    please html5 form validator & elements.

  24. blah says:

    Microsoft has always been disingenuous. They pulled a similar stunt on the E7 blog by comparing ClearType to no AA. Gee, it's as if a superior mode is missing somewhere…

  25. Rob says:

    As shown by most of the posts here, you can't pull the wool over our eyes Microsoft.

  26. Tired of whiners says:

    As shown by most of the posts here, fanboys and whiners hate having their worldview shaken. IE9 simply *destroys* its competition in performance.

  27. Stifu says:

    @Tired of whiners: on the other hand, it's funny. Not long ago, when IE8 was not out yet, the IE team kept saying JS benchmarks didn't matter in real life and all that. Never mind the fact that IE was clearly the slowest at the time, that must have been a coincidence. Now that IE shines in some fields (GPU acceleration and JS speed), they keep boasting about it in every article. Now that IE does better at JS benchmarks, suddenly it's worth talking about it. These tests are no longer irrelevant, for some reason.

  28. hAl says:

    Why is IE9 not using the second CPU in this test ?

  29. arash sadaghian says:

    @hAl because they are all 32bit versions.

  30. firefox user says:

    8 fps?

    Well, I get ~30 fps in Firefox 3.6.6 (pure sw rendering!) on my not-too-new laptop.

  31. firefox user 2 says:

    @firefox user

    Well, I get ~5 fps in Firefox 3.6.6 on my not-too-new desktop PC, so what's your point?

  32. Matt says:

    arash: it has nothing to do with being 32bit. The browser doesn't need to use the second core after the javascript is compiled.

    stifu: Mozilla/Google/MSFT still agrees that benchmarks like SunSpider are pointless (see the videos from the velocity performance conference). unlike artificial tests like sunspider (which encourage ridiculous optimizations like caches for daylight savings time flags), the Shelf demo shows how *real* websites will actually *use* browser features and *how* real-world performance matters.

  33. Stifu says:

    @Matt: I agree that some optimizations are stupid, just for the hell of scoring better, and that these tests get too much attention already. That's why the IE team shouldn't give them even more attention (especially since they criticized them before). But then again, these tests highlight improvements in IE, so it's good publicity, regardless of how good the tests are…

  34. so whats the real deal says:

    So ok, this is all great n all but if you turn off the GPU usage in IE9 for this JavaScript performance is IE9 still behind every other browser?

    If so, this is a very short term "win" for IE in that they happened to get their implementation out first… however one would only expect that the other browsers will follow suit and in turn IE will get whipped again in every speed/performance test.

    Furthermore we haven't heard a single word about bug fixes in IE9 that indicate that bugs that existed since IE6 are actually getting fixed.

    ie. is innerHTML going to finally be fixed? IE9 better not return CaMeLcAsE spagetti and should most certainly not fail when using it as a setter on dropdown lists and tables.

  35. Reader says:

    so whats: It's polite to actually read a blog before asking lots of snarky questions that have already been answered. IE9's JavaScript engine is significantly faster than Firefox's and scores within a fraction of an eyeblink vs. Chrome and Opera on SunSpider.

    The IE9 preview builds show tons of bugfixes (hence the ACID3 score improvement) and the IE team has blogged about them extensively here.

    Or are you just trolling here?

  36. so whats the real deal says:

    @Reader – thanks for your trolling.  I've read this post (as I have every single post on this blog since IE7 was announced).

    IE9's JavaScript engine is definitely faster (ATM) than many browsers however that wasn't the point I was commenting on.  Any browser will gain massive performance increases by offloading work to another CPU (e.g. the GPU) its a no brainer.  The question is if the GPU offloading is decoupled, how does IE's JavaScript stack up against the other browsers? (e.g. in the past, IE was always slower).  Its well known that other browsers are working on GPU offloading too, thus bragging straight up that you are the fastest, just because you were the first to "add jet boosters" but this will bite hard once the other browsers add their "jet boosters" considering they were faster to start with.

    I'm also well aware that IE has IMPLEMENTED many missing features to improve their ACID3 score and support canvas/svg (and by gosh they are all WELL, WELL APPRECIATED!) however a big part of software development is fixing the bugs… especially when your software is basically a framework for other developers to build on top of.

    As my example indicated, if you asked developers this question this would be the answer:

    Which browsers support the DOMElement.innerHTML property?

    Firefox – yes

    Safari – yes

    Chrome – yes

    Opera – yes

    Arora – yes

    Konqueror – yes

    IE6 – partial* (with exception factor)**

    IE7 – partial* (with exception factor)**

    IE8 – partial*

    IE9 – partial*

    *partial:

      The getter returns 100% invalid, incorrect markup

      The setter does not work in a myriad of scenarios including some pre, and div elements, almost all table elements and select lists (webbugtrack.blogspot.com/…/bug-210-no-innerhtml-support-on-tables.html)

    **crash:

      In legacy versions of IE certain attempts to set the .innerHTML of a table would actually throw an exception (I need to Google a reference for this it has been a few years now that this fix has been in place)

    Considering that some of these bugs have been known about for over 10 years I don't feel the slightest bit "trollish" to simply ask if there is intention to bring IE up to snuff and fix these *very* basic issues.

  37. Reader says:

    sowhat: If you weren't trolling, you'd simply try out the innerHTML case in the build and see for yourself. If you were helpful, you'd file a bug on Connect if you found a problem.

    A GPU isn't a CPU, and IE doesn't run JavaScript on the GPU. Considering how crashy Firefox 4 is with GPU acceleration, and that their Beta 1 doesn't even score as well as FF3.7 on SunSpider, I think they've got a lot of catchup to do.

  38. Stifu says:

    @Reader: "If you weren't trolling, you'd simply try out the innerHTML case in the build and see for yourself."

    He may not want to install IE9 just to check that out, or maybe he doesn't have Vista or 7 so he can't install it…

    As for the GPU/JS speed thing, it's true that pure JS tests won't be affected whether there is any GPU acceleration. However, tests that include both JS and graphics (using canvas and stuff) will of course benefit from GPU acceleration with IE9, possibly blurring results if you wanted the details.

  39. so whats the real deal says:

    @Reader – Stifu's comments sum most of it up – but for the record I have tried IE9 to see if the various innerHTML bugs have been fixed.

    Status:

    IE9 preview 1 – broken

    IE9 preview 2 – broken

    IE9 preview 3 – broken

    And yes, all these bugs have been in filed in Connect since Connect opened for IE7 bug tracking – they were re-added when IE8 bug tracking was added, and added(or ported) again for IE9 bug tracking.

    These bugs are a thorn in my side because of how frequently they crop up.  If you think about it… when are you most likely to want to dump a bunch of data into the DOM? Hmm, I don't know, say after doing an AJAX call to get a bunch of data?… ok, now what are you going to do with that data?… well I'll likely dump it into a table (paginated search results anyone?) to view or fill a select list full of dynamic options. BOOM! you've just hit 2 bugs in setting innerHTML in IE that are very common everyday, everysite scenarios.

  40. soum says:

    Speaking of performance, the images generated at w-shadow.com/css-anything bring IE9 preview to its knees, but Chrome doesn't even realize it's hit something.

  41. concerned citizen says:

    after installing internet explorer 9 i was saddened by the still sluggish feel of the browser.  Performance across the board should be the number one priority.  I don't understand why startup time hasn't been improved 10x over.  Microsoft has always outperformed when it was on the bottom and I truly hope the ie team has the fight they did during the netscape days.  Msft has some of the most talented engineers, i look forward to the release.

  42. EricLaw says:

    @concerned: You haven't installed "Internet Explorer 9"– you've installed the Platform Preview build. If the Preview build doesn't launch in under half a second, that suggests that there's something else wrong with your system. What are your Windows experience index numbers? What's your processor speed and free memory?

  43. badger says:

    @so what

    You're right, it'd be nice to see those bugs fixed. Though it's at least worthy of noticing that there have been a tremendous number bugs they have fixed in addition to those the large number of features they've implemented. I've never seen any other browser make such large strides between releases as they are with IE9.

    Nonetheless, let me offer some advice. If you're concerned about performance and are having problems with innerHTML, then you can avoid the bug *and* improve performance by using createElement, createTextNode, appendChild, etc. because these avoid extra parsing by the browser.  And technically speaking, innerHTML is not a standards-based method. Now, that being said, I'm not saying they shouldn't fix the bug. But using the standards-based methods will avoid the bug in the meantime and (if you're making a large number of calls) could improve your performance.

  44. Walter says:

    @badger, the problem is that innerHTML is faster than createElement and setAttribute…almost by orders of magnitude. If you are doing a large DOM insertion you definitely want to use innerHTML!

  45. Mitch 74 says:

    @Walter: the problem with innerHTML is that you have to make sure that every and all HTML nodes and entities in it are correct, otherwise you end up with a f**ed-up page – or, on an XHTML page, with a parse error – and the following hard stop. Using DOM methods may be slower (and even that, with recent browser versions, is up to debate), but it's also much, much safer.

    Unrelated, and my comment yesterday was removed: IE9pre3 has a problem with how box-shadow's blur is implemented, which makes the blur unusable (on top of rendering radically differently from other browsers). Examples on http://www.mitch074.fr/…/shadow.html

  46. Han says:

    How is complaining that they don't test Opera trolling? Considering that Opera gets a good 20FPS without the GPU, even more sometimes, it seems like a deliberate attempt to make IE9 appear more impressive than it is: "over 6 times faster than the runner-up" is clearly more impressive than "barely 3 times faster than the runner-up".

    What is stupid about this whole thing is that this Amazon Shelf thing has no reason to be done with <canvas> rather than normal, DOM-based DHTML at all, and it would be reasonably fast in all current browsers. The follow-your-cursor-over-the-black-box-with-fading-colored-circles demo in the previous post: That is totally <canvas>. If there was any amount of rotation, of any of the books, that would be a different story. But c'mon, the only animation is fading and translations, which current browsers are perfectly capable of doing at a reasonable speed by animating the CSS opacity, top and left properties.

  47. Kyle says:

    han, with under 1% marketshare, Opera isn't even in the competition.

  48. Anthropic says:

    Will IE9 get E4X support?

    It would be a good selling point over Chrome & Safari as WebKit has been slack in supporting this awesome feature.

    It is so important for working with xml when JSON is not an option and related systems only provide SOAP.

    PLEASE add support for it :)

  49. soap is dead says:

    @Anthropic – just in case you missed the memo SOAP is dead.  Why bother with piles of useless overhead when an HTTP1.1 JSON based gzipped REST API will absolutely scream compared to a slow legacy redundant SOAP API.

    SOAP was cool when building a Framework for everything was cool in Java but now that reality has caught up and we have a standard REST based API – SOAP is dead.

    I highly suggest you move on, and if you have old SOAP API's its time to update them.

  50. Tired of punditry says:

    Typical attitude on the IEBlog.

    "That's right folks, if you're not using the latest hotness, you should throw away all of your working code and upgrade to new technologies with marginal benefits. That includes APIs, and if you don't own these APIs, too bad, stop using them and go write your own code. Because, I mean, SOAP, that's like, sooo out of fashion. All the cool kids are using JSON. And let's make JSON sound better by implying that you can compress it with GZIP. It's not like XML compresses with GZIP or anything… I mean, JSON is magic, and XML is so old that it doesn't know how to be compressed."

    Once you graduate and go out to the real world to get a job, you'll learn what the terms "legacy code" and "business value" mean, and the important relationship between them.

  51. Infinte says:

    @anthropic:: E4X dead est. Now we need jsLinqToXML.

    Drop COM objects NOW!

    ——————————-

    AND PLEASE NOTE THIS ISSUE! SNAPSHOTS ARE INCLUDED!

    connect.microsoft.com/…/white-text-on-black-background-are-rendered-ugly

  52. Matthew says:

    Infinte: Internet Explorer uses COM heavily (it's almost entirely COM-based) so that's not going away anytime soon. And it's a pointless request anyway… Firefox is XPCOM-based and no one complains about that.

  53. Interested chrome fan says:

    I've been using Chrome for about a year now, since trying out some of the Chrome Experiments at chromeexperiments.com, and seeing how much faster it went than Firefox. I'm very interested to try out the GPU rendering on some of these same tests, since many of them seem like they could benefit from GPU acceleration. However, I was unable to open any of them in IE9. Every time I clicked the launch button, the new window was sent to my default browser, instead of opening in IE9. Is there any workaround for this?

  54. Not IE9 says:

    @chrome: You're not using "IE9", you're using a *preview* of the IE9 rendering engine.

    To try your test (which probably won't work due to webkit-specific markup) you can probably copy the URL out of that new browser window and then click File > Open in the Preview and paste in the URL.

  55. George says:

    Is there an option to disable the sending of referer header in IE? I mean something like this option available in Firefox: kb.mozillazine.org/Network.http.sendRefererHeader

    It could be of use to power users who care about privacy.

    If there is currently no way to disable this in IE8, could you please take this into account for IE9? It could be a nice addition to smartscreen filter, inprivate filtering and all.

    Thank you.

  56. arn says:

    Opera claims it's fastest browser. So, where is it?