FlashCanvas

Download FlashCanvas 0.1
Released under the same Apache License as the exlorer canvas project.

What is FlashCanvas?

FlashCanvas is a canvas tag to flash bridge for browsers which do not support the canvas tag like Internet Explorer. FlashCanvas is an experiment to see if any performance improvement could be realized by using flash technology. The javascript code is a fork of the ExplorerCanvas project:

Firefox, Safari and Opera 9 support the canvas tag to allow 2D command-based drawing. ExplorerCanvas brings the same functionality to Internet Explorer. To use, web developers only need to include a single script tag in their existing web pages.

This FlashCanvas release only implements lines and fills. This is enough to support example1 and example2 from the ExplorerCanvas project.

FlashCanvas was put together in one day of hacking so it is pretty basic and has many bugs/quirks.

How does it work?

FlashCanvas is modeled after ExplorerCanvas which means it should be a drop-in module which provides canvas support. There are two main components combined together: the very basic FlashCanvas.swf flash file which compiles down to 688 bytes and the FlashCanvas.js wrapper/controller file. swfobject.js is used to embed flash into the page.

The FlashCanvas.js file implements a fake-canvas object and changes the existing canvas element into a a flash object (using swfobject.js). 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.

note: you must serve the files remotely. There exists a flash player bug which does not allow local connections to communication with actionscript from javascript using ExternalInterface even if permission is granted. (AS to JS does work with local connections however). A python script for running a SimpleHTTPServer instance is provided for testing purposes.

Why is ExplorerCanvas slow?

Although I'm not an expert on ExplorerCanvas, it is clearly not designed to do motion graphics. Almost everything ExplorerCanvas does is string manipulation to construct markup which is re-interpreted by Microsoft's Vector Markup Language. This method works sufficiently for static graphics but does not work well for motion graphics.

Does FlashCanvas provide better performance?

The short version: not really.
The longer version: All drawing commands are being forwarded from Javascript -> ExternalInterface (down into the browser) -> ActionScript -> Flash Drawing commands. This is a lot of overhead for drawing code. Doing something simple like a moveTo and lineTo would result in at a very minimum 8 separate levels of indirection.

FlashCanvas performance is discussed further here.

What other approaches could be taken?

Some other ideas:

• Stop using broken browsers like internet explorer - We can dream...


• A separate canvas plugin for internet explorer - this wouldn't be too difficult if the cairo graphics library were used as a starting point.


• a more practical approach would be to abstract the canvas interface away by writing code targetted at the Processing language and then implement a processing flash interpreter (if one doesn't exist already)

How do I build FlashCanvas.swf?

The FlashCanvas.swf file is compiled using the MTASC and swfmill compilers.
Once those are installed run:

make

latest webkit build

Safari Version 3.1.1 (5525.18) vs. WebKit r34153

Both running the same UFWS development page which contains lots of canvas and javascript code (in a loop to animate).

Ep16

Episode #16 is release, getting closer to something resembling a game -- with an opponent and nifty spell graphics and all. Bumped up the update rate, which makes everything seem much smoother but also increase CPU load.
In a previous post I talked about anti-aliasing in firefox vs. safari. This turned out to be caused by the location the image was being drawn at was not an integer position. Which means the the pixels were being split across multiple pixels when rendered onto the canvas. The HTML5 specification does not really talk about this case and how it should be handled, maybe it should?

Ep15

Episode #15 is out, I completed the background on Friday, added a combat log on sat., on sunday I was rushed again to get something playable out. Players can now target things by clicking in the game and then perform actions via the buttons below the game. No spell animations yet and probably won't be until Friday. Once more of the framework is in place I'll have more time to finish update some actual gameplay with continuity between episodes, which is my ultimate goal. The flash version was nearing the point where it was strictly content development not tools and code development. CPU usage has jumped up almost double which is concerning will need to look into what is causing that.

Development shot showing the simplified collision map.

Ep14

Episode #14 introduces a newer - RPG style system that will eventually add player vs. computer combat. This means the player now has health and an available "energy" bar. The concept of failure has also been added via dying from low health points. This was the direction I have been planning to take the game.
The gameplay suffered again for this episode because I generally work on the background first and then work towards fitting the gameplay around the scene. In the end, because of the new additions, I simply ran out of time and had to push out whatever I had completed.

ufws canvas transition

My last flash version of UFWS (Episode #12) went up on Monday morning. The rest of Monday was spent transitioning all the actionscript code to javascript (and writing some notes down). Tuesday was spent finishing up and recoding some parts which basically meant cleaning up the original code a bit. The rest of the day was spent making the background and updating the three widget graphics used. I was a bit crunched for time to get some decent gameplay in unfortunately. Overall, though the transition was much smoother than I imagined; there are some things I still don't have figured out. Today Episode #13 is released and is now using the Canvas tag.

The rest of my notes:

• There are some anti-aliasing differences between the Safari on OS X and Firefox on windows - The "game-over Congrats!" image has rendered text in a PNG displays on major blurrage in firefox for some reason, on OS X this text is crisp


• no text rendering is a problem, will need to get creative when I want to display any signage (like popup menus I had in the previous flash episodes)


• No native IE 7 canvas (or SVG) support continues to sadden me.

Canvas tag a Flash killer?

I'm mid-port of my Untitled FWS project to make use of the canvas tag. Here are some notes:

• Since I'm cheap and haven't pirated Flash I use MTASC + swfmill to create my flash stuff which means my source is written in ActionScript version 2. Porting this code to javascript doesn't require a whole lot of changes.


• Performance of the canvas tag isn't bad, considering the rendering loop is coded in an interpreted language. In my case I am creating an animated scene and the canvas tag is probably (don't know for sure) redrawing the whole thing every frame; Flash would limit redraws automagically based on what parts actually changed.


• Firefox version 2.0.0.14 on OS X clearly has a very large memory leak dealing with the canvas' drawImage function that causes it to eventually crash after eating all available memory up. (This can be seen by simply setting an interval and continually drawing an image into a canvas element)Update:This appears to be just for OS X, the Windows version of Firefox 2.0.0.14 doesn't explode.


• Firefox version 3 Beta 5 has plugged the leak and decreased CPU usage overall


• Limited No text support in canvas elements in common browsers. however the HTML5 draft teases us with talk of rendering HTML and CSS into a canvas... THAT would be nice


• No real IE support means this is basically not an option -- yes, there is an emulated canvas library from google but from the CAKE demo page it sounds like it doesn't work very well.


• javascript intervals get called more regularly by Safari than their actionscript interval equivalents in my experience -- I think this is caused by some weird interaction between the flash plug-in and the safari browser


• Blend modes are available and actually work without a huge performance penalty. this is better than current SVG blend mode support which relies on filters which aren't implemented (meaning there is only source-over fallback)