The lack of globalCompositeOperation in IE9's Canvas implementation is a pretty serious limitation.
It seems to come down to the limitations of Direct2D, which doesn't seem to support any other compositing operations except source-over, a.k.a. "normal alpha blending". This is fairly surprising when taking into account that Direct2D is a very new graphics API (it shipped in Windows 7)...
I think the root cause is that Microsoft's graphics APIs have long evolved in a different direction compared to everyone else. Make no mistake, Microsoft is a very important force in graphics because they control Direct3D, and that has placed them at the vanguard of high-performance accelerated 3D graphics.
Direct2D seems to mostly take design influence from Direct3D. One of its explicit goals is to provide 2D utility graphics for Direct3D games -- stuff like HUD displays for games. The traditional "Porter-Duff" compositing operators (i.e. the blending modes missing from Direct2D) are not very useful in this environment, so instead Direct2D concentrates on "game-like" stuff like high-level geometry objects.
In contrast, the other major browsers use graphics APIs that fundamentally derive from the Adobe school of print-oriented graphics, where an image is built from low-level immediate mode operators. Think PostScript and PDF.
The original Canvas JavaScript implementation shipped in Mac OS X 10.4 to support Dashboard widgets. Canvas was just a paper-thin wrapper over Apple's Quartz API, which in turn was essentially a royalty-free implementation of the PDF graphics model (before Quartz, Apple/NeXT were licensing Display PostScript from Adobe).
I think Mozilla's Canvas implementation uses Cairo, which is an open-source library heavily modelled after PDF and Quartz. Chrome uses their home-grown Skia, which is also very similar.
Poor Microsoft. If they had taken the opportunity in 2004, they could have easily dictated a simple web graphics standard that would have played to the strengths of the accelerated graphics API that they control. But instead they were busy building giant fortresses of proprietary APIs like the dead-end Windows Presentation Foundation, and now they're having trouble implementing something as superficially simple as Canvas.
Direct2D is an odd API, which I'm not an expert on. So maybe it's great, but I can't tell from messing with it.
But with that said, it is built on Direct3D, which can do this type of compositing, at the very least with shaders. I'm sure they could add that support into D2D, or IE can go directly to D3D to do it.
I'm kind of surprised IE didn't just use D3D for most of canvas anyways (and D2D for some things like text rendering).
Sorry to deviate from the topic at hand, but in what ways do you think WPF is a "dead-end"? I've been mucking about with it in preparation for my first desktop app in a few years. It seems to work well enough but maybe I'm not deep enough yet.
IMHO, most of the Porter-Duff compositing operations are fairly useless. There is a nice mathematical purity to the model from which these operations are derived, but that's also their weakness: they are based on an ultra-simplistic abstraction instead of real world use cases. Punching out alpha mattes in various ways just isn't very interesting in practice.
Porter and Duff can be forgiven because the "real world" didn't exist when they designed this model in the early '80s. At the time, a frame buffer add-on to a computer could cost as much as a car...!
When designing a modern graphics API, I think it would be more useful to look at the operations that people are actually familiar with, e.g. Photoshop blending modes, and design the interface to match those expectations.
I wonder if he has the same issues with the latest platform preview (which came out nearly two months ago).
Now, all this fairness aside, I'm extremely curious why MS isn't adopting the rapid release cycles that the Chrome team have used. As a (potential) consumer of the Internet Explorer line of products, I feel like I'm left out in the cold when I see that the last release was sometime last September. In the meantime, Chrome has added a major enhancement to their JavaScript engine, WebGL support, and more. More importantly, they've added this stuff incrementally so I, the (current) user of Chrome don't have to wait for months for the next major release.
Or perhaps more to the point, I'm curious why the IE9 marketing team don't see the promotional advantages of rapid releases as compared to the old major release model. As the Chrome team have said...market features, not releases.
Big enterprise customers don't like change, and rapid release would frustrate their IT guys to no end. That's why we still have IE6 in lots of big companies, why I still see IE7 in my visitor stats even though IE8 has been out for years, and why all of these versions will be sticking around probably long after IE9 is dead.
Sure I recognize that, and I see it as a highly valid point. But if it is in Microsoft's interests to maintain enterprise users, I don't quite see why it must be done at the expense of the non-enterprise users.
Please call me out if my naïveté is showing, but couldn't MS fragment IE into consumer and enterprise versions? Surely something must be done to appeal to non-enterprise users to halt the increasingly rapid deterioration of IE market share.
To expound on this idea a bit...imagine IE adopts the multiple channel approach like Chrome has. They could have the four typical channels (canary, dev, beta, stable) and add another one called "enterprise" or something like that. The first four would receive silent automatic updates while the "enterprise" channel would only be updated when the administrative user requests to do so. Furthermore, they could perhaps choose exactly which release they want. So theoretically, they could upgrade or downgrade the browser without being subjected to automatic updates.
Just an idea, I know. It's probably much harder to implement in reality, but something must be done, and this sort of setup would probably be a one-up on Chrome (something I think they desperately need at the moment).
I'd guess that IE is too gargantuan a project with too many people involved and too much history (read: compatibility baggage) to be able to say, "welp, let's just fork it." Doubtless internal politics and MS's own corporate shortsightedness also have a big say in it. But that's just my guess.
I get that Chrome is fast, but do you hear what you're saying. They did a tech preview in October and it's only been three months, which includes Thanksgiving, Christmas, and New Years.
There's rumors that the RC is coming on the 28th. And RTW is probably a few months after that. Not Google like speed, which is ridiculously impressive, but a beta and 7 tech previews in this time isn't bad.
IE8 came out in March of 2008. By the time IE9 is out, it'll be close to 3 years between major browser releases from Microsoft. That is too slow. The Internet is moving much faster than Microsoft understands. (Or perhaps if they understand it, the Web is moving much faster than they can handle.)
Chrome went from a state of non-existing to very popular in the same time. Microsoft's web browser development speed is abysmal for such a powerful and large software company. They either don't care, or they want it to be slow and have poor performance. I can think of no other reason for such slow development of their web browser, especially in an era where everyone knows how important the web is.
Actually it came out in March 2009. So it's two years between major browser releases. In that 22 months they've dropped 7 tech previews and beta. So at about a clip of every 3 months they've released a new build.
But I do agree that it's too slow. They really do need a Chrome like schedule.
[OT] I am pleased with the features in the IE9 Demo, even if a couple of features are fully matured (like the ones mentioned in the article) but what about their upgrade strategy? Are they planning on forcing IE users to upgrade? If there isn't some sort of push for people to upgrade then all these changes are for naught.
From a personal perspective, I find it highly impressive that their dev team can get stuff pushed out that quickly. Please don't get me wrong in that respect. But what you and I think is cool and impressive matters very little in a highly competitive market.
And I think it's also important to note that I'm not talking about speed of feature releases. I'm talking about speed of general releases. New Chrome features often go from conception to stable release in 2-3 months because of the development structure in which they are released. I wouldn't at all be surprised if the IE team have worked out these canvas issues already, but they just haven't released it (which is why I mentioned that the last beta release was in September).
It's possible that there's a lot of organisational momentum behind it - MS have been doing slow releases of major versions for the last few decades and that mindset could be quite entrenched by now. It might be that they haven't seriously considered doing rapid incremental releases.
So it just continues on. You implement something and it's going to work in all browsers but will require specific tweaks and workarounds for IE.
Business as usual.
The only thing that changed is the nature of the needed workarounds (fix broken canvas instead of fix missing canvas), so that IE9 just brings more frustrating work to the table. One more special case to handle.
In the application I'm maintaining, we have CSS and JS to make the thing work in real browsers and then one file for each version of IE to handle their specific bugs.
As it's looking now, IE9 won't improve on the situation, but just require two more files (CSS, JS) to fix the new, IE9 specific issues, thereby increasing the development time of any new feature because one more special case must be handled.
Why can't Microsoft just get their act together. This is so dammed frustrating
In my defense, Chrome, Firefox, Opera, and Safari did an amazing job of coding to the HTML5 spec. I don’t know why Microsoft couldn’t as well.
I feel like this has been, and is, said about a lot of things that Microsoft should be kicking ass on. Why is Microsoft either unwilling or unable to lead the charge on these kinds of things? Can they say that it's not in their best marketing interest to have a crappy, slowly developed product?
While that is true, I think the chart is misleading in that it doesn't properly weight the tests. Failing to have any sort of globalCompositeOperation is a huge thing, but IE only lost one point for it. I would say that some of the things that the other browsers got dinged for are much smaller in comparison.
You could argue about the weightings all day though. Will people actually use every single one of those composite operations in real life? Shouldn't the important ones be weighed more? etc.
These tests are more involved. Last I checked, no browser gets much more than 80% (though I don't have or want Windows so I can't personally check IE9)
Anybody care to comment on how good the SVG implementation in IE9 is? I've found, somewhat counterintuitively, that you can get better rendering performance from SVG than Canvas if your application is a good fit for certain techniques, and I'm hoping that we can use them in IE9 too.
"If your application is a good fit" is the operative phrase here. SVG does some things very well, but lags in other ways. They really are different tools made for different purposes (though they do have a little bit of overlap). It is like Illustrator and Photoshop, which both can make pictures, but a good designer will use both depending on the circumstances.
It seems to come down to the limitations of Direct2D, which doesn't seem to support any other compositing operations except source-over, a.k.a. "normal alpha blending". This is fairly surprising when taking into account that Direct2D is a very new graphics API (it shipped in Windows 7)...
I think the root cause is that Microsoft's graphics APIs have long evolved in a different direction compared to everyone else. Make no mistake, Microsoft is a very important force in graphics because they control Direct3D, and that has placed them at the vanguard of high-performance accelerated 3D graphics.
Direct2D seems to mostly take design influence from Direct3D. One of its explicit goals is to provide 2D utility graphics for Direct3D games -- stuff like HUD displays for games. The traditional "Porter-Duff" compositing operators (i.e. the blending modes missing from Direct2D) are not very useful in this environment, so instead Direct2D concentrates on "game-like" stuff like high-level geometry objects.
In contrast, the other major browsers use graphics APIs that fundamentally derive from the Adobe school of print-oriented graphics, where an image is built from low-level immediate mode operators. Think PostScript and PDF.
The original Canvas JavaScript implementation shipped in Mac OS X 10.4 to support Dashboard widgets. Canvas was just a paper-thin wrapper over Apple's Quartz API, which in turn was essentially a royalty-free implementation of the PDF graphics model (before Quartz, Apple/NeXT were licensing Display PostScript from Adobe).
I think Mozilla's Canvas implementation uses Cairo, which is an open-source library heavily modelled after PDF and Quartz. Chrome uses their home-grown Skia, which is also very similar.
Poor Microsoft. If they had taken the opportunity in 2004, they could have easily dictated a simple web graphics standard that would have played to the strengths of the accelerated graphics API that they control. But instead they were busy building giant fortresses of proprietary APIs like the dead-end Windows Presentation Foundation, and now they're having trouble implementing something as superficially simple as Canvas.