- What a Difference a Day Makes
- Testing Processing.js
- What Works & What Sucks
- Feature Tests
- Comparing Speed
- Bugs Submitted & Re-Opened
If you have not yet heard the big news, Internet Explorer 9 is shipping with Canvas support! Also with the Video and Audio tags, WOFF Fonts and tons other other HTML5 goodness. Being a huge fan of Canvas, I jumped straight in to the IE9 Preview to take the IE demos for a test-drive. For some unknown reason, the first of the Microsoft script demos I tried threw me a wonderful: “Script Error”. “Oh great!” I thought, “IE9’s Canvas is going to suck!”
Frustrated, I hit CTRL+F5 to refresh. “Whoa. Déjà vu.” I could have sworn a black cat went past us, and then another that looked just like it… the demo started working.
Boxes… all over my <M$canvas>! I could almost not believe what I was seeing, and checked the Title Bar of the Window. Yes… it really was Internet Explorer, was I dreaming? (pinch-test) No! In my excitement, I hit the notoriously dangerous streets of South Boston, on a mission to find a can of Tab Clear with which to celebrate the arrival of the year 2003.
Not everyone was excited about IE9 supporting Canvas, but then the performance gains of lower-level architecture and the rich synthesis of such closely complimentary web technologies are not going to be everybody’s cup of tea. Sure, but I was excited: I had been loving the blogging, emailing and filing bugs on Microsoft Connect long-time.
And the IE Canvas has been a long-time coming, it was originally unleashed by the Borg… oops I mean… “Apple”… back in 2003. Seven-ish years (if you can really call it like that) is a big hunk of time for a browser vendor to keep the people waiting, even if you do take into account the patent & spec issues that slowed the whole process down. While it may have been a slow step forward, such a colossal mass of corporate-browser-dom being beaten into shape by the Open-Web is certainly a giant-leap forward for Web-kind.
To all the IE developers who have clearly worked so hard over the past year, I think congratulations are in order. In my opinion… you done good. I have been futzing around with the IE9 Preview-3 for the last 24 hours, and while there are definitely some things that are not quite hammered out yet… gosh-darn it – it’s really starting to feel like a bona fide HTML5 web-browser!
The first thing I tried after the Microsoft Canvas-Pad Demos was Processing.js. I used the awkward “Page Open” address bar/box/thing to navigate to ProcessingJS.org. Remarkably the page ‘just worked’.
The interactive banner animation and the pulsing blue-grey circle did their thing without any issues what-so-ever. Surely a testament to John Resig’s clarity of mind: the number of things that were working, compared to the number of potential IE gotcha’s I well-know are in the code… was pretty impressive.
Even the Cloudkick Server Visualization we put together last year ran without too many issues. Unfortunately the newer Processing.js releases were hitting a few snags in the parsing department, but the quick work of Yuri from the PJS development team, had the library back on trace within a couple of hours.
A surprising amount of the Canvas spec seems to work very well. The following two lists are a quick break-down of the good, the bad and the really freekin’ stupid. Even though the “Sucking” list is two times as long as the “Working” list… the 85% delivery on the Canvas spec more than makes up for the problems, most of the issues being fairly minor.
- Processing.js 😀
- 85% of The HTML5 Canvas Spec 🙂
- 2D Hardware Acceleration, appeared to be a micro-tad faster than Minefield Trunk (off trace), but no way near… “Chrome Fast“
- Deep Zoom: WTF?! But OK, I guess that’s cool.
- Burst Engine SVG Parser
- 15% of The HTML5 Canvas Spec, 50% of which no other vendor bothered to implement anyway, so who cares?
- Miter limit calculation seems to be a fraction off
- arcTo: Opera are still the only guys that got that one right
- Multiple IMG.onload Firring for when requesting one source multiple times seems to collect onload callbacks and fire them on a per-source basis rather than a per-call basis.
- Video to Canvas was a little “jerky” compared to other browsers
- No Composite operations 🙁
- No “right-click save-as image” :'(
- No canvas.toDataURL(“image/[type]”) ?!
- Turning off ShadowBlur does not behave as expected.
- Microsoft Connect: It’s a labyrinth to get started, and you can’t post symbols like “<" & ">” which makes things super-awkward. I could have filed my bugs quicker with the postal service.
I knocked out a basic set of cross-browser canvas tests in order to make a comparison of where Canvas is at in mid 2010. I tried to use as many of the functions as possible, though you should be aware that this is in no way an exhaustive test-suite. You can click on the image to the left to expand the screen-capture I took of these tests running in Internet Explorer 9 Preview 3 on Win7.
I ran these simple tests on the five main-stream browsers (Firefox, Chrome, Safari, Opera & IE) and captured the images to disk. I dropped then into Photoshop to get a visual-diff between each browser. When I say “a visual diff” I am referring to the process of blending a source-image with a destination-image using a an “Difference” blend. I then invert the result for visual clarity.
The resulting images reveal all the places in which the browser rendering engines differ. When comparing these visual-diffs, we can see that IE9’s canvas rendering engine is closest to Safari’s.
You will also notice at the top right how the Miter Limit value is off by a couple of pixels. This is true when comparing IE9 to all the other browsers, so it is probably safe to assume that there is some kind of miscalculation going on–on Microsoft’s part.
Another interesting feature to note, is that all the other browsers capable of rendering text, will insert a space where a newline character is used: “EarthnMoon”. The “n”, for some unusual reason does not break the line in any of the canvas implementations. A space is always added instead… but not in IE9.
To compensate somewhat for this overlap in my tests I have run the test with and without the Canvas API calls, and calculated the difference.
I built a quick Spirograph style visual that changes the number of strokes points while rotating the Canvas. The test runs through a for-loop 20,000 times before alerting the result. You can click here to run the visual test or click here to run the test without Canvas API calls.
|Browser||Seconds||Without Canvas||Time spent in Canvas calls|
|IE9 Preview 3||92.009||79.880||12.129|
Opera Wins! I am very surprised that Opera has beaten Chome in this test. Congratulations Opera. These tests were run in Win7 x64. One thing that has to be said, is that we are testing a small set of features and so it is unlikely that this result accurately represents the full spectrum of results. I also chose a stroke() example because I know that certain browsers should perform strokes faster in this test, but are mind-bogglingly slow. Notably: IE9 has problems turning off shadowBlur.
- Multiple IMG.onload Firring
- Bad MiterLimit Calculation
- Newline “n” Canvas Text Inconsistent
- Undefined shadow color still renders
Canvas in IE9, too good to be true?
The Canvas in IE9 is actually pretty decent. It is a little less feature-complete than it’s rival UAs but its speed comes remarkably close to Firefox, and in some cases it appears to come out ahead. (@mrdoob points out that he thinks the hardware acceleration is only for the drawImage() functions) I can only hope that the IE development team finish what they started. If so they do, it will help the Canvas will become a useful cross-browser commercial tool soon enough, perhaps even in the corporate environment of the next decade. 🙂
The IE development team have proven that they are listening to their users, paying attention to standards and making internet of the future a richer experience for everyone.