FlashCanvas is modeled after ExplorerCanvas which means it is a turn-key solution for adding Canvas support to IE. You can code away, happily using open standards and then use FlashCanvas to forcefully and silently upgrade IE to also being standards compliant.

There are two main components in FlashCanvas: the base FlashCanvas.swf flash file (a mere 688 bytes), and the FlashCanvas.js wrapper. I’ve used the excellent swfobject.js to embed the Flash into the page.

The FlashCanvas.js file implements a fake-canvas object and converts all existing canvas element into a flash object. The javascript intercepts canvas commands and forwards them to the FlashCanvas.swf movie file using the ExternalInterface provided by the flash player. The flash movie clip then interprets the command and draws accordingly.

Aza originally thought that this would also solve the performance problems other fallbacks to VML have but found out that sadly enough this is not the case because of the lag between ActionScript and JavaScript via ExternalInterface.

Each call via the ExternalInterface is taking approximately 0.5 ms. Since we know the time it takes to call an actionscript method from javascript, we can deduce the amount of time it takes for Flash to render. For the example1.htm page it takes ~24 ms to render 20 anti-aliased lines. In Safari a call into actionscript takes roughly 0.4 ms — this is only the call time, it doesn’t include the time to render anything. For example1.htm a single “particle” calls actionscript 3 times with the commands: [lineStyle,moveTo,lineTo]; each particle takes 1.2 ms in JS-to-AS calls; to take 1 second to render the frame ~833 particles need to be rendered.

There are few more ideas in the comments to the article and this might be an interesting concept to take further. Somehow it seems ironic to go back to Flash to make IE render standards, but then again VML is proprietary, too.

* Hat tip to Scott Schiller for pointing out this older, but somehow forgotten post.

What about Silverlight. Isn’t that was MS want us to use instead anyway. Can’t we just make a SVG to XAML converter, a few XSL files and your done. ;) Don’t know if the JS bride between the runtimes is faster.

I happen to believe that using Flash, or SL, or VML, or even Java (ugh) is a perfectly valid “shim” approach to creating fallbacks for misbehaving browsers (like IE). It allows developers to continue to consolidate on a single API, which makes all our lives easier, and it holds off the “problem” until such a time as browsers can implement better approximates to the almighty “standards”.
.
Performance can suffer, yes, but that’s a better/lesser cost (IMHO) than poor dev behavior (that is, different coding for different browsers), or even worse yet, flat out lost behavior for certain users because of their unlucky bad browser environment. Again, shims are specifically intended to prop up the site/app experience until such a time as a better thing can be brought along. So, we know it’s a tradeoff right?
.
In fact, this is exactly the approach I took with flXHR [ http://flxhr.flensed.com ], which implements the identical API to native XHR, but does so with a javascript+invisible flash solution as the shim. This “solves” the problem of having a consistent API for cross-domain Ajax calls.
.
I think it’s the same logic that makes flXHR successful which can make a Flash or VML backed canvas hack a viable solution for now. Keep up the good work.

The problem is, it’s nearly impossible to replicate 100% of the CanvasRenderingContext2D API on VML in a way that looks correct, and performs reasonable. Most of the excanvas implementations are missing features for this reason, and a shim that’s missing a bunch of functionality and performs poorly can also encourage bad dev behavior.

If its just the ActionScript call that has a price, why not ‘caching’ all canvas API calls and send the flash object a whole batch of instructions every x-amount of API calls or using a context.updateForFlash()….

“You can code away, happily using open standards and then use FlashCanvas to forcefully and silently upgrade IE to also being standards compliant.”

If I am not mistaken, canvas tag is not part of any open standard (yes, it is part of an attempt to develop and standardize on HTML5). So blaming IE for not being standards compliant here is actually at least a little bit premature…

Well this is another ‘fix’ to make something work on IE. Ok it’s not really a standard so far (@SergeyIlinsky), but that doesn’t change that fact that once again, we need a fix to make something work for IE.

Using alternative communication techniques (like calling fscommand from flash and using swfRef.setVariable from javascript), might actually be faster than using ExternalInterface, which actually serializes everything into XML, and sets callbacks (and waits for them), rather than just sending strings, like setVariable and fscommand.

Of course, where you do need a return value, ExternalInterface is the way to go, but where you don’t, there can be performance gains through setVariable and fscommand.

CaptainN is right; use fscommand and setVariable/play/stop on IE for Flash communication. It is extremely fast, but a pain to program for. Another alternative is to hook deeper into the ExternalInterface architecture to avoid an eval() statement, which the ExternalInterface does on each call and which slows things down. More info on overriding ExternalInterface to get more control on an old blog post on my blog here: http://codinginparadise.org/weblog/2006/02/how-to-speed-up-flash-8s.html

@CaptainN i think that’s a very smart idea. It seems like a good portion of the canvas api might not need return values.
.
@Brad good find on the EI overriding. I may use this (or captainN’s idea) for flXHR to speed it up.
.
The question is, will anyone care enough about IE to put in this extra work.

There is always the option of just don’t caring about non-standard conforming browsers. I think the way bespin and timepedia are going here is pretty brutally cool to be honest … ;)
.
In fact I invented a word a couple of years ago for this (which I haven’t dared to speak out loudly) which is “lock-out”…
.
But hey, anything that can prove that ActiveX2.0 (Flash, Silverlight and JavaFX) are slower then pure JS, DOM and Canvas must be good, right…? ;)

I personally believe the way forward with IE (and other legacy browsers) is to write JS libraries (utilizing bits of proprietary tech, like Java, Flash and Silverlight – perhaps even utilizing other browser enhancements from Mozilla, like screaming monkey), that extend IE with standards based features (like DOM events, and canvas support) in a transparent way.

The reality of the way browser support evolves even among the standards based browsers, is that you always need a way to apply the new technology (like html 5 video tags) to the legacy browsers, at least in the short term, while the newer browsers take up market share.

I’d love to see the focus of many of these “Ajax” libraries to basically add new standards based features to old browsers, in a very opt-in and modular way. John Resig did this with Sizzle, a small JS library that adds the Selectors API to old browsers (including IE), and uses the native support where available (and enhances it, where necessary to add smaller subsets of features?).

Another example would be that it should be currently possible to implement audio tag support (with ogg vorbis support) using a combination of Flash and Javascript to browsers that don’t currently support ogg vorbis, or the audio tag, and could even be used to enhance those browsers that support the audio tag but not ogg vorbis.

Oh, all that was to answer the question of “would anyone care enough about IE” – I think the answer is unfortunately yes – out of a need to be concerned more than a desire. Microsoft’s position with IE seems to put the effort of supporting their browser on developer’s shoulders, instead of on their own initiative. I wonder if they understand the effect that has on their perception from web developers, and the community in general.

It’s fairly easy to get any of these up and running, so it would just be a matter of wrapping them in an interface, and then you’re done. They are pretty light on the CPU usage too – though, obviously they’ll never be as efficient as Flash’s built in mp3 decoder…