In part one of the Flash Player Internals recap we covered how the player is built, in part two we talked about how the player infrastructure works, in part three we examined how ActionScript and the Virtual Machine (VM) are improving in Flash Player 10.1.  Now, in the final segment (looking at my notes this will be the longest segment) we will look at how the Flash Player rendering system is being improved and how you can leverage it for multiple devices.

Shake Your Movie-maker

One of the biggest changes in player 10.1 is that all video will now be GPU decoded.  This is huge for you video buffs out there because GPU decoding is sick fast and allows lower power devices, like netbooks, to play 1080p video smoothly and efficiently.  In the current player, video is decoded using a software based decoder (except in fullscreen, when GPU may be used, but not guaranteed) which is fine when you are on a big 8 core beast, but little machines just can't handle the data.

Now, with a change this big there has to be a few caveats.  Well, there is.  First, your GPU has to support H.264 decoding in the chipset.  If your GPU (ex: video card) doesn't support that, then you are out of luck and the Player will fall back to software decoding.  Next, your GPU and GPU drivers have to be certified for the Player to use it.  If you have an older driver that is not certified it won't matter if your chipset supports H.264 or not, the Player won't leverage it.

In part one of the Flash Player Internals recap we covered how the player is built, for part two we talked about how the player infrastructure works.  In part three, we will examine how ActionScript and the Virtual Machine (VM) are improving in Flash Player 10.1.

What's New, Player-cat?

First off, Lee announced that the ActionScript VM has been updated to use the newest version of nanojit, which is the same VM backend that is used by Firefox 3.5.  This is an important update not only for performance, but because it supports many different processors.  Processor support is critical when you are looking to run the VM on as many devices and platforms as possible and nanojit helps the Player team do this.

The Player now has a much improved internal String class.  Strings have always been a bit of a bottle neck in Flash and the player team has updated the new class to allow better caching, faster string comparison, and most importantly lower memory usage.  This kind of low level update is great because it improves how our applications run without having to change a line of code.  Of course, you need to republish existing applications for 10.1 when it comes out (recall how the player versions SWFs), but the gains should be worth it.

On the memory front, the Player team has spent a lot of time focusing on how to use less of it more efficiently.  The first step they took is to have the VM take up less of a memory footprint.  Lee didn't get into any details but I would assume nanojit helped with this.  The other area they looked at was Garbage Collection (GC) and how it could be tuned for mobile devices.  What they have found is that memory usage has dropped anywhere from 10-50% for existing applications.  The GC tuning wasn't the sole update for this huge improvement, we will look at some other updates in part four, but this was a big one.

In the first part of our series we discussed how the player code base is being unified and how that will impact future development on the Flash platform.  In part two, we will dive into the infrastructure of the Flash Player and how this affects us as developers.

Understanding The Execution Model

The execution model is all about how the Flash player performs its actions every cycle (i.e. frame).  The first thing is that the Flash Player is actually extremely multi-threaded under the hood, its just not exposed to developers.  This means that conceptually we have to look at the player as single-threaded.  There is a huge debate about the benefits/limitations of this concept, one that I am not going to even try to comment on in this post.  For now, this is the way the player works... 'nuff said.

Lee's explanation of the execution model is pretty much a recap of what has been said in the past, so read up on the 2007 presentation here and also check out how the elastic racetrack model works.

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.

We are happy to announce the release of Adobe's newest application: WorkflowLab (public Alpha release). WorkflowLab was built by DevelopmentArc for Adobe and was designed, developed and deployed in under 6 weeks.  This new AIR application allows users to view and construct project workflows to demonstrate how their products, applications, and/or technologies are built using Adobe Technologies. The tool allows user to define project tasks and assign Adobe tools and technologies to those tasks to help illustrate how Adobe's products and services assisted in completing the project. Inside of the tool Adobe has provided a core set of workflow starting points that can be used to help guide the workflow of new project or as a starting point for your own workflow. Download it here.

This year James and I will be involved in three separate sessions at the Adobe Max conference in LA.   Adobe Max provides a collaborative arena for the communities of designers, developers, project managers, executives and any other project participators to gather and  share ideas, real-life experiences, theories, secrets, and best practices.  Over the past year DevelopmentArc has been involved in a wide variety of projects and we are excited to share our  experience with the community the best we can.   Below is breakdown of the three sessions we are involved in. Two involve a secret (shhhh) project that is to be released next Monday.  Follow James (@jamespolanco) or I (@aaronpedersen) on twitter and we will share as soon as we can.