20
Oct

For the last three years I have attended the Adobe MAX session put on by Lee Thomason and Jim Corbett called "Flash Player Internals".  This is by far my favorite MAX session, because its extremely advanced, fast paced and they cover as much of the player's architecture as possible.  This year at the Adobe MAX 2009 conference, Jim was not able to join Lee for the session.  Its unfortunate because Jim and Lee's interplay is half the fun, but Lee is a great speaker and he handled covering the entire session like pro.

For the 2007 session, I wrote a huge recap article because they covered the first version of the player to support ActionScript 3.  This player changed how the virtual machine (VM) worked and they showed all kinds of tips and tricks based on the VM's architecture. You can read my previous posts over at my personal blog, VivisectingMedia. The write-up is a multi-part series that starts off covering the player teams motto about not breaking the web.  I skipped writing about 2008, mainly because we where just too busy starting DevelopmentArc, prepping for MAX Europe and the impeding holidays.

Now that MAX 2009 is all wrapped up its time to write up a multi-part series that recaps all the new topics that Lee delved into.  This round, Lee looked at all the upcoming changes in Flash Player 10.1 and I feel taking the time to research and write the posts are worth the effort.  You can watch Lee's session over at the MAX video site and if you have any questions or comments please send them our way.

Building Flash Player

In the past, the Flash Player was forked for different platforms.  Actually, forked isn't really correct, it was two very different players built by different teams, that both shared a common root back in the AS2 days.  The FlashLite team (flash for mobile) was a different department within the company and had unique goals, targets, features and deadlines.  I am sure this caused a lot of tension and challenges for both player teams and due to this (and other goals) Adobe has merged the teams into one entity.  This integration means that with the upcoming release of version 10.1 the code base will now be unified.  As Lee said, "One Build to Rule Them All!".

Lee did mention that around 20% of the code base is still platform specific, i.e. targeting Palm, ActiveX, OS X, Netscape, etc.  There are too many differences on each platform for them to have a 100% unified code base, but this also means that 80% of the code is shared across all platforms.

One But Many

Having a single code base for all target platforms will help Adobe unify their player strategy for mobile, browser, device and desktop development.  Yet, this introduces some new challenges for both the player team and the development community that deploys applications using the Flash Player.

The first big challenge is that we are seeing a huge (and rapidly growing) gap between performance (CPU) and memory availability per platform.  As Lee said, the processing power of an 8 core system vs. the Palm Pre processor is pretty huge. Not only that, but browser/desktop developers have been pretty spoiled when it comes to available memory.  Having multiple available gigabytes of RAM on one platform (i.e. browser) vs. 20 megabytes (i.e. hand-held device) can radically affect how you build an application.  Note:  we are not saying that memory usage isn't an issue on the browser, its just less of an issue when you compare devices.

The next issue that player unification faces is screen size and pixel density.  As applications start to cross the multi-device bridge, understanding how the screen lays out and is used becomes more important.  Lee didn't talk about pixel density directly, but Chris Giffith chimed in at the last SDFUG meeting with some interesting side notes.

An LCD monitor pixel density (i.e. pixels per sq. inch) is significantly less then hand-held devices.  This means that a 40 pixel button on your LCD looks great, but becomes too small to use on a Pre.  Pixel density also differs across devices with the same resolution. The iPhone 3Gs has a 3.5 inch, 320x480 resolution, and a 163 pixels per square inch (PPI) screen. The Palm Pre has a 3.1 inch, 320x480 resolution with a 186 PPI screen. If we went solely on resolution, they look the same from a Player perspective so we may design a UI that works well on the iPhone but fails on the Pre due to the density difference.

Another challenge is user interactions.  Does the platform support a mouse and a keyboard?  Does it support multi-touch?  The player has to understand these different kinds of user inputs and we as developers have to understand how it impacts our applications.  A finger is not a single pixel accurate device, we have to understand that when doing development.  The player has to expose the right information to us, from the lowest level granular data to more high-level user actions such as swipe or pinch.

The final major challenge the unification brings to the table is that user's expectations change base on the device being used.  Performance and usability change based upon whether your user is using a mobile phone vs. a browser.  On a phone, your app could be closed in 10ms because a call is coming in.  If the player doesn't support this then its impacting the user's expectations and needs for the device.

The Player is Not the Silver Bullet

What this all leads to is, the Player cannot solve all of these problems.  The team is trying to provide as many of the solutions as possible, but the reality is, as developers we have to really understand our delivery platforms and understand that what works for one user/device combination will not work for another. As we start moving over to more and more radically different platforms, we must develop and design applications with all these consideration in mind.

That's all for part 1, in part 2 of the series we look at the execution model & player infrastructure, in part 3 we examine how the ActionScript Virtual Machine is being updated and in the final section we look how the Flash video and rendering system is being updated..

[ Read Part 2: Flash Player Internals 10.1 ]
[ Read Part 3: Flash Player Internals 10.1 ]
[ Read Part 4: Flash Player Internals 10.1 ]

[...] 1. SWF stands for Shockwave Flash (not Small Web Format) 2. Flash is a Platform (Flex is not. Its a Framework.) 3. Flash does not mean Flash IDE (“Flash IDE” is just another tool to create SWF, so as “FlashBuilder”) 4. SWF struture is one (FlashPlayer never goes on reading the SWF to detect whether its made with FlashIDE or FlashBuilderIDE) 5. What Flex can do is a subset of what the Flash Player can do,not a superset.(ref : Mrinal Wadhwa) 6. Flashplayer internals are not closed,anyone and everyone on Flash world should know it [...]

[...] I assume you do since you probably are since you are reading this), you need to carefully read this recap. [...]

Social comments and analytics for this post...

This post was mentioned on Twitter by stony: RT @jamespolanco: Posted part 1 of my #FlashPlayer Internals recap. Part 2 will be up soon. Its all about player 10.1! http://bit.ly/4gIUmB...

[...] This post was mentioned on Twitter by Mike Chambers and Chris Stone, James Polanco. James Polanco said: Posted part 1 of my Flash Player Internals recap. Part 2 will be up soon. Its all about player 10.1! http://bit.ly/4gIUmB [...]

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.