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.
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.
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.
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.
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.
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
Anonymous
July 06, 2010
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.Anonymous
July 06, 2010
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.Anonymous
July 06, 2010
> This means hardware rendering with the GPU was not enabled in Firefox. Why don't you turn it on? www.basschouten.com/.../presenting-direct2d-hardware-acceleratioAnonymous
July 06, 2010
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.Anonymous
July 06, 2010
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,Anonymous
July 06, 2010
@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.Anonymous
July 06, 2010
The Firefox 4 beta with hardware acceleration crashes a lot which is why Firefox hasn't turned it.Anonymous
July 06, 2010
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?Anonymous
July 06, 2010
If Mozilla doesn't feel comfortable enabling it by default even on a beta, why should anybody else?Anonymous
July 06, 2010
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.Anonymous
July 06, 2010
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.comAnonymous
July 06, 2010
Comparing non-GPU rendering to CPU only rendering is a completely meaningless test. Thank you for wasting all of our time.Anonymous
July 06, 2010
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.Anonymous
July 06, 2010
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"Anonymous
July 06, 2010
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 (tm). This demo falls into the category: "nice looking toy".Anonymous
July 06, 2010
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 FPSAnonymous
July 06, 2010
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.Anonymous
July 07, 2010
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.Anonymous
July 07, 2010
@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.aspxAnonymous
July 07, 2010
MS are cowards for not turning on Firefox 4.0's Direct2D and DirectWrite GPU hardware acceleration as usual.Anonymous
July 07, 2010
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."Anonymous
July 07, 2010
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!Anonymous
July 07, 2010
please html5 form validator & elements.Anonymous
July 07, 2010
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...Anonymous
July 07, 2010
As shown by most of the posts here, you can't pull the wool over our eyes Microsoft.Anonymous
July 07, 2010
As shown by most of the posts here, fanboys and whiners hate having their worldview shaken. IE9 simply destroys its competition in performance.Anonymous
July 07, 2010
@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.Anonymous
July 07, 2010
Why is IE9 not using the second CPU in this test ?Anonymous
July 07, 2010
@hAl because they are all 32bit versions.Anonymous
July 07, 2010
8 fps? Well, I get ~30 fps in Firefox 3.6.6 (pure sw rendering!) on my not-too-new laptop.Anonymous
July 07, 2010
@firefox user Well, I get ~5 fps in Firefox 3.6.6 on my not-too-new desktop PC, so what's your point?Anonymous
July 07, 2010
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.Anonymous
July 07, 2010
The comment has been removedAnonymous
July 08, 2010
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.Anonymous
July 08, 2010
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?Anonymous
July 08, 2010
The comment has been removedAnonymous
July 08, 2010
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.Anonymous
July 08, 2010
@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.Anonymous
July 08, 2010
@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.Anonymous
July 08, 2010
The comment has been removedAnonymous
July 09, 2010
The comment has been removedAnonymous
July 09, 2010
@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?Anonymous
July 10, 2010
@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.Anonymous
July 10, 2010
@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!Anonymous
July 10, 2010
The comment has been removedAnonymous
July 11, 2010
The comment has been removedAnonymous
July 11, 2010
han, with under 1% marketshare, Opera isn't even in the competition.Anonymous
July 11, 2010
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 :)Anonymous
July 11, 2010
@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.Anonymous
July 11, 2010
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.Anonymous
July 12, 2010
@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
Anonymous
July 12, 2010
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.Anonymous
July 12, 2010
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?Anonymous
July 12, 2010
@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.Anonymous
July 12, 2010
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.Anonymous
July 13, 2010
Opera claims it's fastest browser. So, where is it?