The Architecture of Full Hardware Acceleration of All Web Page Content
We’re excited that other browsers have started to use hardware to accelerate graphics performance. With different implementations starting to become available, now’s a good time to blog about the difference between full and partial hardware acceleration.
In November 2009, developers had their first look at hardware accelerated graphics in a browser at the PDC. In March 2010, we released the first IE9 Platform Preview with “GPU-powered HTML5” turned on by default. In that release, hardware acceleration applied to everything on every Web page—text, images, backgrounds, borders, SVG content, HTML5 video and audio—using the Windows DirectX graphics APIs. With Platform Preview 3 in July, IE9 introduced a hardware-accelerated HTML5 canvas.
Understanding Hardware Acceleration
Browsers can use hardware to accelerate none, some, or all of the steps in rendering an HTML pages. The diagram below illustrates the major steps in HTML page rendering in IE9.
Content Rendering. IE9 accelerates the first phase, Content Rendering, using Windows’ Direct2D and DirectWrite subsystems. As shown back in November, the results here include much smoother text and vector graphics. Accelerating this phase using the GPU (Graphics Processing Unit) improves the display performance of the most common HTML elements: text, images, backgrounds, and borders.
Page Composition. IE9 uses Direct3D for the next phase, Page Composition, giving IE awesome performance in image-intensive scenarios (like Flying Images and FishIE Tank). Accelerating this phase takes advantage of one of the GPU’s most significant features: the ability to draw bitmap images at very high speed. Moreover, because the GPU’s private memory retains images, redraw of pages heavy in images is very fast.
Desktop Composition. After a browser renders content and composes pages, Windows Vista and Windows 7 use the GPU to compose the final screen display via the Desktop Window Manager (DWM). Because IE9 uses DirectX and only DirectX, there is better interaction between IE9 and the DWM, using less GPU memory and resulting in better stability than browsers that mix different subsystems.
Full vs. Partial Acceleration
With IE9, developers have a fully-hardware accelerated display pipeline that runs from their markup to the screen. Based on their blog posts, the hardware-accelerated implementations of other browsers generally accelerate one phase or the other, but not yet both. Delivering full hardware acceleration, on by default, is an architectural undertaking. When there is a desire to run across multiple platforms, developers introduce abstraction layers and inevitably make tradeoffs which ultimately impact performance and reduce the ability of a browser to achieve ‘native’ performance. Getting the full value of the GPU is extremely challenging and writing to intermediate layers and libraries instead of an operating system’s native support makes it even harder. Windows’ DirectX long legacy of powering of the most intensive 3D games has made DirectX the highest performance GPU-based rendering system available.
When you run other browsers that support hardware acceleration, you’ll notice that the performance on some of the examples from the IE Test Drive site is comparable to IE9 yet performance on other examples isn’t. The differences reflect the gap between full and partial hardware acceleration. As IE supports new, emerging Web standards, those implementations will also be fully hardware accelerated.
Hardware acceleration of HTML5 video is a great example. At MIX10, we showed the advantage of using hardware for video. In March, IE9 played two HD-encoded, 720p videos on a netbook using very little of the CPU while another browser maxed out the CPU while dropping frames playing only one of the videos. Because of full hardware acceleration of the entire pipeline, you experience great performance playing these videos while moving them around the page and styling and compositing them with opacity, using web standard markup.
Measuring Graphics Performance
A typical measure of graphics performance is frames-per-second (FPS), which indicates how many times per second a browser can update the screen. Be skeptical of demos that show frames-per-second rates greater than 60 fps. The reason is simple: most computer screens refresh at 60 hertz. While it’s possible to render and compose page content faster than 60 frames-per-second, most users will not see it. The extra CPU and GPU cycles spent to render at rates above the refresh rate of your monitor are simply being wasted. This is why the graphics performance demos on the IE9 Test Drive site explicitly limit their frames-per-second to 60—to avoid wasting cycles rendering content you won’t see.
More interesting than simple frames-per-second measurements is looking into what your PC is actually doing. Using the Windows Performance Analysis Tools, developers can see that other hardware-accelerated browsers take anywhere between 20% and 500% more CPU time than IE9 to render a single frame. Depending on the graphic operations required to render the Web page, the actual difference in CPU time will vary. If this additional CPU consumption occurs between visual updates (16.7 milliseconds on a typical 60 hertz display), the difference may not be visible to the user but it does affect how much of your PC is available to do other tasks. Less CPU usage means better overall system responsiveness.
Remember, Real World Performance is Multidimensional
As Jason Weber described in a recent post, display rendering performance is one of 11 core subsystems in modern browsers. While GPU-accelerated page display can improve the performance of every Web page, it is particularly important on graphics-intensive pages (and demo pages designed to highlight graphics performance). All browser subsystems need to be fast individually, and work well together, to make the overall browsing experience of the real world Web fast.
Better Browsing on Windows
We’re excited that other browsers are starting to optimize for the Windows platform. Taking advantage of the PC’s hardware through the Windows APIs makes browsing on Windows better than browsing on other systems. Since that first demo last November, other browser vendors have begun to work on hardware accelerated rendering using the DirectX family of Windows APIs. Hardware acceleration is an important part of delivering great HTML5 performance. Keep in mind that not all hardware acceleration is equal. Today, IE9 is the first and only browser to deliver full hardware acceleration of all HTML5 content.
—Ted Johnson, Program Manager Lead for Web Graphics
Comments
Anonymous
September 10, 2010
What happens when the DWM is disabled?Anonymous
September 10, 2010
The comment has been removedAnonymous
September 10, 2010
Really? I've been running platform previews of IE9 since March. Seems kinda beta to me...Anonymous
September 10, 2010
> display rendering performance Does this include image decoding? This is something still done in the CPU, does IE make use of SSE2 and similar? What about sites with very large images where clogging the memory should be avoided and therefore caching the raw bitmap is not advised?Anonymous
September 10, 2010
And talking about FPS, are there any plans for an API to give the user control over this, e.g. so that an advanced web app will burn less cycles when in battery mode?Anonymous
September 10, 2010
Firefox had hardware acceleration some time last year, at least before November or September.Anonymous
September 10, 2010
To be clear, I'm talking of the beta, of course.Anonymous
September 10, 2010
Nice! Keep up the good work! I'm enjoying watching the other browsers spin, and their small flocks of sheep bleating across the web.Anonymous
September 10, 2010
Platform preview != end user betaAnonymous
September 10, 2010
Microsoft Should listen to the users of Internet explorer. Just to see what New stuff and features that the users want to see in Internet Explorer. (Like They did with windows 7)Anonymous
September 10, 2010
And this is the biggest problem that faces anyone trying to build web applications that are leveraged outside of the enterprise - there are now more "standards" that have to be complied with. Say WebDev1 builds and HTML5 compliant app (whatever HTML5 compliance means - as it is not yet a standard...) and builds this app ontop of IE9, taking full advantage of the capabilities to provide a fabulously rich and interactive experience. Then user1 tries to run it in his HTML 5 compliant browser and finds it's unusable... now Dev1 needs to include a bunch of user agent detection code to scale up and down the experience and target HTML4, HTML5, unaccelerated browsers, etc. Widely different performance characteristics are going to be as much of an issue as varying degrees of compliance with the Editors Draft of the HTML 5 specification. Of course, there's huge cool factor in having "the best, fastest, browser" running on your platform - and I don't deny that the performance I see in the preview is impressive. Unfortunately I see the negatives of trying to build solutions with reach.Anonymous
September 10, 2010
Great work IE team! Can't wait for IE9!Anonymous
September 10, 2010
What happens to the XP users ???? Is IE is going to be slowest browser for me ?Anonymous
September 10, 2010
@Santosh Yes, if you use IE8. But Opera, Chrome, Safari and Firefox all still support Windows XP. And to make some operations faster if you decide to stick with IE you could try a solution like Google Chrome Frame. If for whatever reason you need Windows XP for some sort of compatibility purpose consider using the Windows XP Mode under Windows 7; then you can use IE9 on 7 and whatever application you need under XP. Though, generally, I've found few pieces of software that won't run on the 32-bit version of Windows 7 that ran on XP -- the 64-bit will cause some issues, however, especially with really old 16-bit software, or 32-bit software that uses a 16-bit Setup stub. They won't run at-all. People here can appreciate if you don't wish to upgrade from Windows XP, but ultimately it cannot be supported forever. After all, just because it's the most in-use OS currently doesn't mean for that reason alone it should be fully supported. There's more PlayStation and PS2 consoles out there (130 million PS1 and 145 million PS2, according to Wikipedia) -- so one could equally argue Sony and their partners should still be making games for these. (Those figures are more than PS3 (38 million), XBOX 360 (42 million) or Nintendo Wii (74 million) !). Reality is we'd all be paying a fortune for products if companies never discontinued products. That said, perhaps an IE 8.5 could be created backporting the new standards work but without the rendering features that require at-least Vista with Platform Update and Microsoft could charge users for it, and treat it as standalone software?Anonymous
September 10, 2010
Excellent points, Debbie. It's nice to see that there are still some thoughtful comments here that include research and consider multiple points of view.Anonymous
September 10, 2010
@Rob to be completely accurate, Firefox put a prototype hardware acceleration in a nightly build after Microsoft demo'd an internal build of IE 9 with it at the PDC last fall - not really a full beta and it didn't return to Firefox until the recent beta. It's kind of leapfrogging as everyone works out how to do this, I think.Anonymous
September 10, 2010
@Debbie: did you mean to propose that people would have to pay for this "IE 8.5"? It's just not going to happen. No one is going to pay for a desktop computer web browser anymore (especially if the superior IE9 is free, although not available for XP).Anonymous
September 10, 2010
@Juliana Peña IE9 runs without any issues when DWM is disabled - the GPU is still used to render content.Anonymous
September 10, 2010
In all this talk of GPU acceleration, I should have noted that IE9 will fall back to a software rendering mode if, for some reason, your GPU is not capable of running Direct2D (perhaps 5% of GPUs on Vista and Windows 7 machines). This software mode is also used with remote desktop sessions, in virtual machines, or if you boot Windows in "Safe mode." The software mode is not Windows' GDI but a software emulation of DirectX with all the features of Direct2D and Direct3D and higher performance than GDI.Anonymous
September 10, 2010
"Today, IE9 is the first and only browser to deliver full hardware acceleration of all HTML5 content." Context2D compositing ist not hardware accellerated yet. and with "As IE supports new, emerging Web standards, those implementations will also be fully hardware accelerated." you surely must be talking about WebGL. just kidding... jokes aside: in response to"Remember, Real World Performance is Multidimensional": That 'real world' means the existing web, a world of websites that were developed based on pre-html5 technologies. In the 'real world' of the future, there will be new scenarios of how the new technologies are combined and applied. this in consequence will expose new bottlenecks that are not visible from todays benchmarks and not from the simple html5 demos (e.g. from apple, google, microsoft) that showcase single aspects, but no real world scenarios. I am co-developing a 'same markup' html5/css3/ES5/SVG application (several KLOC), and while it runs in IE9pp, I am afraid to say that it feels the slowest of all competing browsers. Safari 5 for windows is the second slowest, then come opera 10 and chrome 6. Surprisingly firefox 3.6 shows the best overall performance (FF4 is even better) albeith it is positioned further back in popular browser benchmarks. There are aspects where the 'old' firefox is outperformed by other browsers, but those browsers are signifficantly slower at some other things that are more noticable to the user, and not in a good way. For IE9pp (and safari) it appears to be the layout and/or compositing subsystem/s that is/are a major weak point, but that is just a guess and it has not been further investigated yet, as currently available final versions of firefox, opera and chrome all perform well in this concern, and IE9 is not available as final version yet, so it is believed that this is a subject to change. I am sure it is html5 content that i am referring to, and i believe you that all of it is hw accelerated. however in that case for example it still is slower than the rest. So yes, "Real World Performance is Multidimensional", but the axes are not scaled yet, which makes it difficult to maximize for its volume... nevertheless, thanks for bringing IE closer to other web browsers. maybe the web now can finally evolve out of that big mess that is is today, where the client side part of webpage, -site, -app content doesnt consist of 95% cross browser abstraction (library) code written by people that didnt have time to learn javascript because they were busy identifying the 'implementation specialities' of different browsers. nice weekend everyone, gAnonymous
September 10, 2010
The comment has been removedAnonymous
September 10, 2010
MS is too prideful to use a standard like OpenGL. They obviously want to divide the web along acceleration approaches.Anonymous
September 10, 2010
The comment has been removedAnonymous
September 10, 2010
@Leith: "The reason is that as far as I can tell it is going to a mission to emulate al of Direct2D's font rendering etc in pure OpenGL" FreeType/Pango…Anonymous
September 10, 2010
GPU acceleration is great and we are glad to see Firefox 4 embracing it (at any level, partial or complete) because Firefox, Chrome and other non-IE browsers can also handle basic JavaScript and CSS that IE can't - not even IE9. Poor IE9 is still not capable of setting innerHTML properly even though MSFT has known about their bugs for over 12 years. Its always the little things that make developers face palm every day when developing for the web and testing in IE. Oh yeah, this won't work in IE6. Oh yeah, IE7 can't handle simple DOM methods, Oh yeah IE8 can't do rounded corners or W3C events, Oh yeah IE9 still can't do innerHTML. IE9 has to stop this insanity and "Just work"... and by recent tests it is still a long way off.Anonymous
September 10, 2010
You are unfortunately incorrect about what Firefox 4 provides, even in today's tree, and I suspect that testing our publicly-available builds with the D3D and D2D debug layers would have let you find that out for yourself. (Or reading the many public discussions of our features and plans.) Firefox implements Direct2D acceleration of content elements, including text via DirectWrite, borders, and canvas -- including globalCompositeOperation, which IE9 PP4 doesn't implement at all. We also accelerate compositing, using D2D and D3D10, and can implement WebGL in the absence of effective operating system and driver support via the ANGLE project. We would definitely appreciate it if you could get the Direct2D team to implement support sufficient to handle the canvas LIGHTEN operator without requiring expensive readback, though, since you seem to work quite closely with them! On Windows XP, Firefox 4 will provide compositing-only acceleration to ensure that the majority of our Windows users -- and probably the majority of Microsoft's as well -- who are on that operating system can still benefit from their graphics hardware. If you find yourself in the future with questions about what Firefox can do, please feel free to contact me (Dean has my address :) ). You need not rely on mere interpretation of blog posts, since we provide runnable nightly builds, full source code, and extensive public discussion. It's true that taking advantage of hardware acceleration requires architectural investment, and certainly a lot of debugging. (As an example, some WHQL drivers have problems under D2D if the IE9-bundled hotfix is installed. It's our hope that installing IE9 won't cause problems for other browsers that take advantage of Direct2D capabilities, perhaps through improved testing of Direct2D behaviour in the WinQual process.) DirectX itself is an abstraction layer over software and multiple-vendor userspace drivers (and, given the Xbox, multiple operating systems), but if you find that you are seeing a lot of performance loss due to abstraction overhead, I'd be happy to see if we can help. We're very interested in the web being fast, including for those users who remain with their operating system's default browser. Mike Shaver VP Engineering, MozillaAnonymous
September 10, 2010
The comment has been removedAnonymous
September 10, 2010
Somebody hit a nerve with this blog post. :-D I wonder whether Microsoft execs will now go troll the Mozilla blogs in return? What a show this is turning out to be!Anonymous
September 10, 2010
Internet Explorer 9 will have a timer on it?Anonymous
September 10, 2010
Im tired of internet explorer not supporting webkit.. Why not support that when all the other "Bigger" browsers does? Just because of that im not going to spend my time to optimize my site for Internet explorer.. Its time consumeing. I have alot of friends and I have asked people on my school what browser they use at home and its not internet explorer.Anonymous
September 10, 2010
@Andreas Nilsson >> What do you mean ? Webkit is a rendering engine - you can't "support webkit".Anonymous
September 10, 2010
The comment has been removedAnonymous
September 10, 2010
The comment has been removedAnonymous
September 10, 2010
@meni: Link to WebGL being standard. Nothing is on W3C nor it seems to be standard. I expect to be WebGL to be ignored by majority as useless while they'll wait on W3C. And I am sure they won't use single technology based upon vendor-extendable standard. (And instead of signle techology they will release sort of API with implementation being browser dependant) You may teach that all you want,but don't be suprised if it will be wasted effort. IE won't fail/be marginalised just because your favourite technology is not supported. Forget nonstandard techology and you save yourself and your students(?) a lot of time.Anonymous
September 10, 2010
The comment has been removedAnonymous
September 11, 2010
@Klimax, Aethec: OpenGL is definitely an open, multi-vendor standard. It's managed by the Khronos Group, many vendors have contributed to it over many years, and there are many implementations on almost all platforms, including Windows. If we're going to have 3D graphics on the Web, it makes total sense to base that on OpenGL. WebGL is also an open, multi-vendor standard. It is also being developed in the Khronos Group. Microsoft has chosen not to participate, but every other major browser vendor is involved, plus other interested companies. Once every browser but IE has WebGL (which will happen soon), I believe Microsoft will be dragged into WebGL whether they want to or not, just like they have been with HTML5.Anonymous
September 11, 2010
Reading mozilla guys claiming the irrelevant here is quite funny.Anonymous
September 11, 2010
The pixel-blending(compising) can be done with D3D shaders? And text-shadow? even -ms-shader (using .shader files)? Some -ms- prefixes are great.(for "compacity") And where are the OpenType features(like LIGA or CALT)? As for 3d... Can you provide something "has the same feature" like canvas.getContent("MSD3D10")?Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
WebGL is not even finished. It dictates technology. True web standard (and be carefull with this statement as it can be logical fallacy - not that somebody cares) should define API with all behaviour defined. Nothing less,nothing more and what techology is used shouldn't matter. That way those platforms benefiting from OpenGL will use that while MS wouold use DirectX. (And this would make more sense as OpenGL is not directly over GPU drivers in Vista and 7 AFAIK) It is interesting idea,but should be reworked into techology-agnostic standard. Better outcome for all.Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
@era/@all: OpenGL is a way different graphics acceleration standard than DirectX. It's based on other technologies and it's implementation on a system that uses the way better and faster DirectX is a waste of time. DirectX has been the best since its first release showing doom on W95. Now, we've got a long support and there's no graphics card in the last ten years that didn't had an DX api and an optimized layout for best performance on Windows. So WHY should anyone be interested in destroying an industry standard that is better any version?Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
Jones111, VML is 10 times better then SVG, IPX is 20 times better then TCP/IP, and yes, who can forget, Betamax is way better then VHS. [And may I add a more controversial one: Win32 Api is way cleaner then POSIX. As far as .net vs Java, the way I see it Microsoft will open the entire stack one not very far day] All this is water under the bridge, as is this 3D one. Will just have to wait and see how this will play out. :-)Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
@Ted Johnson [MSFT]: How can I check whether my GPU supports Direct2D or not? And will there be a way to know if IE9 is running Direct2D or if it is emulating it? (Maybe something like about:direct2d?) Thank you.Anonymous
September 11, 2010
OK. You were the first to offer full acceleration. But telling us that other browsers are not currently supporting it, while knowing full well that it will be extremely soon supported by other browsers too, is dishonest. Your words might be correct but what it can be infered from them is intentionally missleading. I would have liked you to be more honest and mention in your post the fact that Firefox and Chrome both intend to add acceleration perhaps even before IE9 RTMs. Your post currently sound like other browsers will either be slower because of the abstraction layers or will implement only partial acceleration. This is not true and implying this is dishonest. Alsoo, don't forget that other browsers have had many many features that IE9 only now is trying to catch up to and yet in their blogs they do not bost about it.Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
<<yet in their blogs they do not bost about it.>> Clearly, you don't read very well.Anonymous
September 11, 2010
@Anon: My post is about the state of the world as it is today. I cannot predict if or when other browser vendors will enable full hardware acceleration by default. “On by default” is a valid measure. Turning a feature on by default means the engineering team has confidence that the hundreds of thousands or millions of users who install that software will not encounter severe problems. Having an experimental feature in a build but not enabling it by default is—for the vast majority of users—the same as the feature not being there.Anonymous
September 11, 2010
@Ted Johnson [MSFT]: thanks!Anonymous
September 11, 2010
Ted, D2D and D3D are enabled by default on Firefox trunk today, and have been since September 4: hg.mozilla.org/.../fd13b6ce36bd D3D wasn't enabled in beta5, which was made just before that, but it will be enabled for beta6 of course.Anonymous
September 11, 2010
Normal humans don't download the trunk and compile it themselves, nor do they run nightlies.Anonymous
September 11, 2010
www.conceivablytech.com/.../google-activates-chrome-gpu-acceleration Still faster than IE9 even without GPU acceleration, now with GPU acceleration, Chrome is even faster and embarasses IE9 in standards support, 262 points in beta.html5test.com vs IE9's measly 96 points. Try again when you got real substance, MSFT.Anonymous
September 11, 2010
@No one cares: I'm a normal human and I run Firefox 4 nightly builds. @Ted Johnson, Chris Blizzard, Mike Shaver: Arguments over architecture are far less interesting than arguments over outcomes. In his IE Blog post on the 3rd of June Seth McLaughlin wrote, "Like each other browser tested, we ran Minefield in its default configuration (which means hardware rendering with D2D was not enabled). We will post comparisons with Firefox’s hardware acceleration when it’s on by default in their beta." Well, rendering acceleration is on by default in Firefox 4 Beta 5 and compositing acceleration will be turned on by default in Firefox 4 Beta 6. Why not benchmark Beta 5 against IE9 PP4 now and then benchmark IE9 Beta 1 against Firefox 4 Beta 6? It would be more productive than vague, hand waving arguments over which architecture is better. Show me the numbers.Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
@Google Chrome: Please a) read what you are linking to (they explicitly say both FF4 and IE9 scored better than Chrome 7) and b) think hard before posting results from html5test.com...Bonus points for PCM audio? Points for WebGL? UA-sniffing to give some browsers points they wouldn't get otherwise? Ridiculous. @Robert O'Callahan, Reinhold Hoffner: Last time I used FF nightlies, they corrupted my profile, created 2500 "places.sql.corrupt" files, and threw RPC errors when I tried to open Windows Explorer. (I don't blame Mozilla - it's quite obvious that nightly builds have bugs) Sorry, but a nightly build can't be compared to what the IE team calls a "Platform Preview". They are confident enough to release something to everyone in an official website, talk about it, and even give presentations about it. Mozilla is not. But I agree we should compare IE9 Beta 1 to FF4 Beta 6 when they're out.Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
@Google.Chrome I notice that that html5 beta page has increased its vastly increased points for forms support and fgives points for non html5 webgl. I guess when IE does not support something more point should be given to it. The page gives point to supproting specs which are stil a total mess. One of the biggest part of supporting html5 is the embedded use of SVG which in itself is a huge spec but I guess the html5 test page gives 1 or 2 points for supporting embedded SVG. However the test does give extra points for supporting Theora which is likely been the worst codec to have appeared in the last ten years and which should preferbly be banned from ever being used again. I would prefer negative point given for supporting terrible codecs like that.Anonymous
September 11, 2010
@Aethec I've been using Firefox nightly builds for daily browsing for a few years now. IE 9 Platform Preview is hardly suitable for that. Remember that you need to use CTRL+O to open a new site! So, yes, let's compare IE9 Beta 1 to Fx4 Beta 6 when they're out.Anonymous
September 11, 2010
IE9 is also the first and only browser to ignore 70% of the web (10% OS X, Linux) and 60% XP and target only 30% of web users. Microsoft just doesn't get it that hardware acceleration is secondary to delivery standards compliance to all Windows customers. Maybe IE10.Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
IE9 is a slap to the very essence of the open standards-based web. Targeting a select few with Windows specific new technologies that aren't mainstream. I say this even as I like, upgraded and am posting from Windows 7.Anonymous
September 11, 2010
I think it makes perfectly sense to make a browser that only support the newest in graphics technology. And because the IE9 team can concentrate on making it only for Vista and 7 they can hopefully spend much more time on making a great browser instead of spending a lot of time making a browser that works on every OS in the world. Looking forward to the beta! :-)Anonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
@ D3D vs WebGL I wonder if some of you need to be told by gartner first before they see that a lot of web browsing will happen on CE devices instead of desktop computers. TVs, mobile phones, gaming consoles, car infotainment systems, etc. Looking at D3D vs WebGL under this light, it should be noticed that there are already a lot of OpenGL ES hardware accelerated devices amongst them. WebGL basically is a subset of OpenGL ES with a different ('ecmascript friendlier') api, and some additional data types for ecmascript (cvs.khronos.org/.../TypedArray-spec.html). I see a clear advantage for WegGL. gAnonymous
September 11, 2010
The comment has been removedAnonymous
September 11, 2010
@FFFan Dude, switch to decaf. Honestly, what are you talking about? The fact that IE9 is for windows? ppffft. whatever.Anonymous
September 11, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
If you bother to read, XP, you'd know that the quotes you're citing out of context refer to GDI performance. GDI isn't used by games, WPF apps, or (at the risk of making this discussion relevant) hardware-accelerated browsers.Anonymous
September 12, 2010
Ha ha, some Luddites are finding it very difficult to accept the reality that the pathetic XP OS is going out of favor by everyone throughout the world! Times are indeed very tough for the Luddites of the world!Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
Full Hardware Acceleration is great but will someone please think of the children! the innerHTML children! do they not deserve love too! In IE World the poor HTMLTable and HTMLSelect parents are unable to bear children easily due to Dr. innerHTML being unable to deliver. Please think of the children! and fix Dr. innerHTML.Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
Where is WebGL support Microsoft?Anonymous
September 12, 2010
@Killmax and @Badger: Creating a true abstraction layer around current 3D graphics APIs is nearly impossible, because all current shader languages are tied either to the API (GLSL, HLSL) or specific hardware (Cg). In order to create a practical abstraction layer over the API, you'd have to create a layer that translates a completely new, neutral shader language into a platform specific one. This problem has already been demonstrated. Opera implemented an API-neutral 3D context, but no one uses it because it doesn't support shaders. Meanwhile, Mozilla implemented a 3D context that was essentially a thin wrapper around OpenGL, and it evolved into WebGL. (I'm actually surprised that people are arguing for a neutral context API when the parent article talks about how developers using abstraction layers "inevitably make tradeoffs which ultimately impact performance and reduce the ability of a browser to achieve ‘native’ performance". And wouldn't WebGL essentially serve as API neutral when used with ANGLE or some other emulation layer? How does that not achieve the same goal?) Furthermore, why incur the cost of API abstraction to avoid using a cross-platform API that will continue to be supported on Windows, and which will receive improved support on older platforms with the use of ANGLE? Note that OpenGL 4.1 has full support for the OpenGL ES 2.0 APIs, and since WebGL is based on OpenGL ES 2.0, it can be directly accelerated on any OpenGL .41 hardware. As someone else already pointed out, OpenGL ES is currently the most common 3D graphics API on phones and other mobile devices. (Considering all the cell phones out there, it may be the most common 3D API in existence.) So which would make more sense if you were a browser developer, abstracting all 3D graphics APIs (which is pretty much just Direct 3D and a subset of OpenGL, and exclusively OpenGL on anything not Windows or a game console), or basing a standardized Javascript interface around the already-standard OpenGL ES and using libraries like ANGLE on Windows when the integrated graphics hardware lacks proper driver support? (I'm looking at you, Intel!) BTW, it wouldn't surprise me if Microsoft already knows this, which is why I very much doubt that they'll offer a competing Canvas 3D context API. Any 3D context they could come up with would have one or more of the following issues:
- It would be viewed as proprietary, because Microsoft would initially be the only vendor supporting it.
- Assuming either the overall API or the shaders are based on Direct 3D, it would go largely unimplemented on non-Windows platforms because it would require an emulation or translation layer.
- Assuming a neutral API, it would very likely be slower than WebGL and would either not have shader support or would require a whole new "neutral" shader language (again, initially only supported by Microsoft).
- It would undercut Silverlight for 3D applications. No, I expect Microsoft will exclude WebGL support in IE 9, saying that the standard isn't complete. This gives them time to use their position as majority browser vendor to slow down the OpenGL adoption by developers as much as possible until WebGL becomes popular enough that they have little choice but to include it in IE 10 or 11. They'll then differentiate then version of Direct 3D as a "premium" graphics API, while painting OpenGL/WebGL as a APIs for simpler, lower power hardware.
Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
How come Google within only two years come up with a browser that is more advanced than even IE 9? Or, if you do not agree that Chrome is more advanced then at least it is comparable, or perhaps at least very very good. With a plug-in, Javascript and add-on architecture that is superior and with a security model that is also superior. How come Firefox implement hardware acceleration and enable it by default in full browser builds before IE9 comes out with a full browser beta, even though the IE team came up first with the idea of hardware acceleration? How come Firefox and Chrome release innovations so fast and so much sooner and do it across many platforms like the Mac, Linux and older versions of Windows that IE9 will not support? How come Firefox 4 and Chrome 6 come out perhaps with full hardware acceleration and many more innovations before the end of 2010 whilst IE9 most probably will take another 6 to 9 months? Why is the IE team so slow? Why does it lack vision? I mean why haven't you come up with one new and interesting feature except hardware acceleration and do it faster than your competition? You say that you have an advantage because you work only on Windows. Well, the results do not prove that. Other vendors do a much better job, support more standards, do it on many more platforms and do it faster than you. And at least Firefox has millions of users as IE, so number of users cannot also be an excuse. So, what is the problem with you people. The last 10 years were only catching up. Google continuously thinks of new things, like syncing of add-on settings across computers. You are slow in innovating and slow in executing.Anonymous
September 12, 2010
Well enjoy using an OS that in 4 years won't get any updates, then. ^^ As for me, I'll use Win7 on a 1.73 Celeron M processor computer, and rarely have problems.Anonymous
September 12, 2010
@Badger OpenGL and WebGL have nothing to do with DirectX. They're not implemented in DirectX, they're implemented in the GPU drivers. They're designed to replace DirectX. You ever notice how other platforms that don't have DirectX still have OpenGL? If anything, WebGL needs to be implemented on top of OpenGL, and that got a lot easier with the latest version.Anonymous
September 12, 2010
This development of IE 9 is so Microsoft. Delusional and irrelevant. A single platform Internet Explorer is irrelevant to the open web of tomorrow. Who cares if you are adding acceleration to IE, when users are only using IE on mass as a conduit to install and use safer and faster web browsers instead of Internet explorers. Who actually cares if your Internet explorer product can render accelerated canvas elements for a standard that hasn't even been published yet when it cannot even render pages validated to today's published standards??? Surely this "We have a new irrelevant feature" means more ignorant bliss for you guys, when in reality, web developers all over the entire world are becoming even more sick and tired of your Internet Explorer product's lack of security and inability to render currently published and widely used web standards correctly. Learn to walk before you can run and if that's too much to ask, then I'm sure the Mozilla, Chrome or Opera developers can teach you how to build a web browser instead of an Internet explorer, should you ask them nicely.Anonymous
September 12, 2010
Any acceleration in a browser is great, especially as the US lags the rest of the developed world in Internet speed delivered to the home. But I have had to rewrite (or purchase) special code to have to deal with Microsoft's long-standing decisions to go their own way when standards (now ten years old) are developed. Microsoft says they sell software that makes you more productive. But if you are developing for the Internet, you are less productive because of Microsoft decisions. I'm happy they're writing good code they can crow about, but it fails miserably if I have to edit and modify code due to incompatibilities due to IE being non-compliant with W3C standards (both current and proposed) and doing everything they can to hold up consensus on new ones. It's past time for Microsoft to start playing well with others. I have been urging all of my clients to use modern standards-compliant browsers that show off their websites as they should look. I have no hope that Microsoft will write an HTML5 and CSS3 - compliant browser. Ever.Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
@tigerhawkvok: I don't think you understand what a Nyquist rate is. Speaking simply, if you have an ANALOG (that is, continuous) signal with a frequency f, in order to reproduce it perfectly you have to sample it a rate of 2f. Sampling is just an act of recording current amplitude as a number. This doesn't have anything to do with fps. Nothing. Your post makes absolutely no sense.Anonymous
September 12, 2010
Microsoft IE developers: the world does not want or need your browser! I don't care how fast you make the page render. You have cost me (as a web developer) countless hours in lost productivity due to the absolute lack of concern you have always demonstrated when it comes to actually making IE (any version!) standards compliant. Every month I look at browser stats from around the web and exclaim "hurrah!" for every percent IE loses to FF, Chrome, Safari - any modern browser will do, just not IE! So please, do the world a favor and just cease and desist. Go home. Spend some time with your family. Look for a new job somewhere else. Forget about this embarrassing, demeaning time of your life that you have spent developing this cancer tumor of a program that is known as IE.Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
Bold talk from the company behind the lamest web browser of the last decade. Let's hope you get it right this time for the sake of those who don't know they have other options. Not trolling, just calling like it is.Anonymous
September 12, 2010
"Not trolling..." That's called denialAnonymous
September 12, 2010
Most IE Blog post fall in to at least one of these categories:
- Relevant question; These post ask the IE Team and/or MS to explain something they said in the post, or they change it in a respectful manner.
- Positive thinkers; These posts are from people who see that IE is taking some giant leaps and praise the IE Team for admitting they may have made mistakes and are correcting them. Also may be combined with #1.
- Bashers; Theres post are from people who either hate some browser for no other reason then it exists. Whether it's IE, Opera, FF, or Chrome they will bash it, with at best out of date information.
- Complainers; Similar to Bashers but they have one little thing that they will harp about IE having/doing/not-having/not-doing.
- MS Haters; Similar to Bashers but the hate is at a company, most often MS (hence the name).
- Random; self explanatory. Which are you? (I like to think I'm a bit of 1, 2, and 6)
Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
Strange,those who are bashing Windwos 7 never provide proof. YT videos are not proof. Hard numbers with entire methodology explained with all relevant info disclosed is (like apps installed,changes to default settings,...) Even stranger are those who bash IE and IE team. I doubt they'll be ever right about change in browser market. And to those "web designers" who complain: Use small libraries like PIE and shut up. You get IE6+ compatibility withóut effort.Anonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
The comment has been removedAnonymous
September 12, 2010
It is easy to see for people using Windows 7 that on the example Youtube video with a performance comparison between XP and W7 the W7 installation has issues particular to that installation. I have much more fluent GUI performance even on fairly old hardware. I also notice that the comparison video uploader switched of comments. Probalby because the uploader knows his comparison is bogus as it seems releated to him having issues with drivers or even him faking the example. @ AntiLuddite You are probably right that it is only one person or mayby just a few trolling this blog with changing nick names.Anonymous
September 12, 2010
@Anon: Different project management styles. I believe MS generally uses their own agile model called Microsoft Solution Framework (MSF). Also I heard that they use some awful versioning software, somewhere in the intertubes there is a blog post of an ex-MS employee describing it and how he worked on the start menu in Vista.Anonymous
September 12, 2010
@tigerhawkvok: I thought this was only the case for CRTs, not LCDs.Anonymous
September 13, 2010
The comment has been removedAnonymous
September 13, 2010
I thought there was even little to no performance problem with OpenGL on Windows. OpenGL also does a large amount of things DirectX does. Isn't there pretty much only two types of operating systems? (Unix/Unix-Like and Windows) So is it really that hard to use DirectX on Windows and OpenGL on everything else? As long as OpenGL can do the same things as DirectX (or even the other way around), it really shouldn't matter. Don't the web browsers already have to be compiled for each operating system/type? I agree with what you are saying Mark with the idea to base a standard around OpenGL for the reasons you stated.Anonymous
September 14, 2010
The comment has been removedAnonymous
September 14, 2010
@Ted Johnson [MSFT]: You made a comment about what happens when GPU acceleration isn't available (it's emulated). Is not supporting XP a decision based on principles or technology? If the former, I find that aweful.Anonymous
September 14, 2010
John, it's both. GPU acceleration is emulated using code that doesn't run on Windows XP. Graphics is only one area where IE9 uses APIs not available on the ancient xp codebase. And Windows XP isn't supported because that's what "out of support" means. All products have an end-of-life, and XP reached it.Anonymous
September 14, 2010
@Mark OpenGL apps generally run fastest on Windows since the video drivers there are the most mature. OpenGL and Direct3D are both basically lightweight interfaces, there's not a lot of meat there. The implementation of both is provided by your video drivers.Anonymous
September 15, 2010
The comment has been removedAnonymous
September 15, 2010
The comment has been removedAnonymous
September 16, 2010
@Badger: Your argument is nonsense. An "agnostic" Javascript API has no benefit for the following reasons:
- It does not allow Web application developers to choose the best API. They have to develop for the "agnostic" API. Only browser implementers would get to pick the underlying API used for implementation.
- It requires Web application developers to learn an additional graphics API. If you already know OpenGL and Direct3D, you actually have to learn a third API to do Web applications.
- It provides no benefit to browser implementers, because they'd have to create an ANGLE-like "thick" abstraction layer for the underlying operating system APIs regardless of the platform. WebGL, by contrast, is merely a thin API wrapper for OpenGL ES, and can be implemented on top of existing libraries like ANGLE or Mesa if the local platform doesn't support OpenGL or OpenGL ES.
- Application performance would suffer because of the abstraction layer the "agnostic" API would require to communicate with the underlying operating system APIs. In no scenario would such an API outperform WebGL, because ANGLE proves that OpenGL ES can be implemented on top of APIs such as Direct3D, and the "agnostic" API would have to encompass WebGL's feature set for it to be even remotely usable.
- The standard for an "agnostic" API would duplicate years of standardization efforts already performed by the Khronos Group. OpenGL ES and WebGL already exist as standards within that standards body. This would delay 3D support in browsers by years.
- An "agnostic" API has already failed in the real world. Opera had an API-agnostic 3D Canvas context, but no one uses it, and they now support WebGL. If Microsoft really wanted to give people the freedom to use what ever 3D graphics API they wish, it would make more sense for them to implement a sort of "WebDirect3D" Canvas context API as a thin wrapper around Direct3D. That way, a programmer could perform a simple check for WebDirect3D support and fall back to WebGL if support isn't present. Of course, all the major browser vendors except Microsoft already support WebGL and have no reason to support another competing API, and Microsoft will likely want to avoid the bad PR from exclusively supporting a rival, proprietary, platform-specific API.