Bespoke App development for the Web and Devices

Don’t break the Web!


11.11.07 Posted in Actionscript, Flex Development by admin

As I mentioned in my first post, I attended Max 2007 this year and I attended many interesting presentations.   Lee Thomason’s presentation on  Flash Player Internals was particularly interesting (so much so that I attended both sessions!). He delivered a very informative overview about how the Player works, as well as some great tid-bits to help inform Flash development decisions.

Here are a few of the things that I took from the sessions;

No breaking the web!

Bugs are not fixed in older versions of the Flash player. The rationale for this is that bug fixes may result in breaking something else and, by not fixing these old bugs and effectively freezing development on older versions, it ensures that our older Flash applications will still run as intended (i.e, preserving the web!).  

The official advice from Adobe for developers who encounter a bug when publishing to an older version of the Player is to publish to the latest version of the Player. (Experience has taught me that it isn’t always as simple as this and there are a lot of old Flash apps out there that clients want to reincarnate but that is a whole other story!).

How do new players display old swfs?

 Lee explained that new players ‘virtually emulate’ older players when displaying swfs that are published to older players. Problems may occur for swfs that load other swfs that are published to different player versions. The reason for this is that the Flash Player can only emulate a single older player at a time. I came across a series of interesting benchmark tests that compare different versions of the Player. One of the tests compares how a swf published to fp7 performed when run in fp7, fp8 and fp8.5. This is a test of the old Flash Virtual Machine (AVM1). It’s interesting how performance differs across different test sets. AVM2 leaves it for dust though!

AVM1 and AVM2; from plugin to platform

The Flash Player contains 2 virtual machines since Player 8.5. The original, AVM1, executes code written in AS1 and 2 as interpreted byte-code. It is frozen and will always be there (to preserve the web :-) . AVM2 executes AS3 code using a Just-in-time (JIT) compiler. The first pass runs through the actionscript to validate it, checking that the code is non-malicious. A second pass turns it into native machine code. An advantage of JIT (also used in C# and Java) is that it takes advantage of the target platform for optimisation and can take advantage of new Intel chipsets.

Performance is said to be 10x better in AVM2 (and in some cases much more than this – check the benchmark tests again!). The question of moving to AS3 development is a no-brainer for this reason alone as far as I am concerned. Other benefits include silent failures, a hallmark of AS1 and 2 development (or ‘the good old days’ as Lee describes it!), being replaced with exception throwing and the old onload handlers being replaced with proper loading classes with a proper security model around it.

It’s also worth pointing out that Adobe has open-sourced AVM2 and it is now a Mozilla project called Tamarin. The implication here is that AS3 developers will have a head start on learning Javascript 2 when it is released. This is because AS3 is an implementation of ECMA Script 4, which will be what Javascript 2 will be based on. This is a smart move, especially with Silverlight appearing on the horizon. ECMA-4 has not been finalised however so AS3 will have some minor differences. One issue relating to this fact is that, in the interests of not breaking forwards compatibility, class constructors in AS3 can only be set to public. I’ll be exploring this issue via Design Pattern exercises in later posts.

Post to Twitter



Leave a Reply

You must be logged in to post a comment.