Ãë´óµ¶ ²©¿Í

First off, let me explain my background for those of you who may not know. Way back in the day, when Flash 4 was the latest and greatest, Macromedia decided to ¡°open up¡± the Flash file format. They released documentation (which was poor at best) and an SDK (which was horrible at best). I saw the potential here. Finally, the format third party developers could unleash their creativity and usher in all kinds of amazing tools. Unfortunately, the documentation was full of errors and the SDK was so riddled with bugs that you spent more time debugging it than using it. 

Nevertheless, debug I did. I came up with quite a list of fixes to the SDK, fixes which would render it near complete and bug free. I signed up for a free hosting account and promptly placed a list of the updates you had to make to the SDK in order for it to be bug free online. Macromedia¡¯s response: cease and decist. Rather than integrating the changes themselves or acknowledging that they solved a serious problem, they told me that it was a violation of the license agreement to be posting that kind of information¡­. Some definition of ¡°open¡± they have there. 

Not to be dismayed, I determined that the source code license was just far to restrictive then and I would create my own SDK. As familiar with the spec as I had become, it didn¡¯t take long for me to put something together. In a few short weeks, I had an SDK that was far more complete, far less buggy, and far easier to work with than the Macromedia SDK. It wasn¡¯t long before hundreds, then thousands of developers were downloading the SDK and posts to Macromedia¡¯s own open-swf forum turned from questions about the Macromedia SDK to questions about this new alternative SDK. It wasn¡¯t too long before Macromedia completely discontinued their SDK (rumor has it that product teams internal to Macromedia even considered using the SwfSource code for their own projects).

Ever since then, I've been working with the Flash File Format. I've helped put together some award winning tools that are arguably some of the most successful SWF generation tools outside of Macromedia. This gives be a unique perspective on the differences between the two formats and how these formats enable developers to create tools that work with each of them.

Admittedly, my view point isn¡¯t the same as  a lot of people, who are perfectly content just buying the Flash IDE and can do everything they will ever need to do from there. I create tools that work with the File Format itself, tools that export their content into the Flash Format. So, if you are a software developer like myself (which is probably a good chance if you are reading this blog), then you would almost assuredly come to the same exact conclusion as myself if you knew the details of the two formats.

Animation

The Flash format itself has no notion of animation other than transformation matrices. You can apply a matrix to an element on a per frame basis to move it around. Want to move something across the screen in 3 seconds? Calculate how many frames 3 seconds will take, then calculate the matrixes required for each frame along the way. Oh, and don¡¯t forget that the player won¡¯t actually maintain any frame rate unless you embed blank audio tracks, so that 3 seconds might turn out to be 2 or 6 or 5, it just depends what kind of mood the machine is in.

Silverlight supports the WPF animation model, which is not only time based instead of frame based, but lets you define the start and end conditions and it will figure out how to get there for you. No need to deal with matrixes. No need to calculate positions on various frames. It just works. 

Shapes

Flash stores its shapes using binary shape records. In order to write shape definitions, you will need to either license a 3^rd party Flash file format SDK, or build your own. It isn¡¯t too difficult, but it does require a bit of a learning curve and the ability to manipulate things at the bit level, since shape records don¡¯t align on byte boundaries. Needless to say, it isn¡¯t the kind of thing most people can write and have all debugged in one afternoon.

Silverlight uses XAML. XAML is text based and can be output using a simple XML object. No need to buy special libraries to write files. No need to write your own libraries. Just stream some text to a file and you¡¯re done--easily the type of thing that can be debugged and finished in an afternoon. 

Text

Flash stores its fonts glyphs using the same exact shape definitions that are used for any other shape. The player itself does not understand TTF files, so you¡¯ll end up digging deep into the Win32 APIs and the fairly vague definitions in the Flash file format documentation to come up with something that sort of does the trick. You¡¯ll probably spend ages trying to deal with all the intricacies of fonts, because it turns out that typography is actually fairly complex¡­ and you will have to deal with all those complexities yourself.

WPF/E lets you embed true type font information directly into your projects, and download that information with the downloader object. No need to do anything special. No need to handle anything yourself. It just works.

Video / Audio

Flash supports multiple video formats. The latest codec is really high quality and the bandwidth usage is nice. There is one problem though if you are creating a tool that outputs Flash content¡­ the formats it supports aren¡¯t really used by anyone else. The original video codec, Sorenson¡¯s proprietary H.263 implementation is a mutant version of H.263. The compression follows the spec fairly closely, but there are a bunch of features dropped out and you can¡¯t exactly just go find a complete spec on how to build your own encoder. The later codec from On2 puts you in an even worse position. Licensing Sorenson¡¯s codec isn¡¯t that expensive, but On2 will rape you with fees. They are relying on revenue from licensing the codec used by Flash to revive their $2 a share stock price. It is also a completely proprietary format (where at least the Sorenson one was loosely based on a standard). The audio formats Flash supports are all proprietary, except for ADPCM, which no one uses because of its horrible compression, and MP3, which is decent but dated, and still requires licensing fees and 3^rd party conversion libraries.

Compare that to the Silverlight story. Silverlight implements industry standard VC-1 codec for video, as well as offering support for WMV and WMA. Just about everyone already has Windows Movie Maker, but if they don¡¯t it¡¯s not a big deal. Why? Because Microsoft makes available a free Encoder SDK for producing WMA and WMV. So, not only are you using formats that people are more likely to be able to encode themselves, but Microsoft also provides your product with SDKs if you want to do the encoding yourself. The best part about it is that Microsoft doesn¡¯t rely on WMA/WMV licensing revenue to keep themselves alive, so not only is it easier to integrate, but it¡¯s also cheaper.

Scripting

You can reuse C# classes from your tool inside your exported content. There is no development environment out there for creating real desktop applications which is based on ActionScript. If you go the Flash route, this means that all your classes and objects have to be written twice. You need .NET classes to handle the author time experience and Flash classes to handle the run-time. If you have server components, once again you need to switch back to .NET and throw out all the classes that the run time is using. For example, let¡¯s say you are creating a tool that outputs rich media quizzes. With Silverlight / .NET, the same entity classes you use to deal with results in the player could be reused on the server side. With Flash, you¡¯d have to write all that logic 2x and keep it in sync as your tool changes.

Tools

You can create Silverlight content with the same tools you use on a daily basis. Visual Studio.NET is by far the most powerful and most popular IDE. You can potentially have all the code for the server components, the authoring tool components, and the runtime/player components inside the same project. No extra skills required. No needing to hire some special Flash guru to do the graphics junk. Every developer can contribute to every part of your application.

The bottom line: about the only thing Flash has going for it from my perspective is adoption. Adoption isn't hard to achieve, especially for the people that ship the operating system 90% of the world uses. As such, it's just a matter of time till that is no longer part of the equation. Adobe has a lot of work to do in the mean time, and the clock is ticking. Open sourcing Flex is a really good start in the right direction... unfortunately, Flex was built on top of the wrong platform from the start (something I told the Flex team while Flex was still in Alpha), so this last effort, while a good one, still might not be big enough to turn the tide that is coming. Now, this isn't to say that Flash isn't a great format and doesn't enable a lot of scenarios (like I said, my job is working with Flash and I'd be doing something completely different if it wasn't for Flash). So, Flash is great. Silverlight just solves a lot of the major problems that I've run into with Flash.

²é¿´Ô­ÎÄ¿ÉÒÔ¿´µ½¸ü¶àÓÐȤµÄÆÀÂÛ£ºhttp://weblogs.asp.net/jezell/archive/2007/05/03/silverlight-vs-flash-the-developer-story.aspx