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.
Now that you understand frames, render rates, and the execution model (you did read all those links above right?) there is priority in the Flash Player on what gets executed first. The king of execution is sound, if you are playing sound the Flash Player will spend as much energy (i.e. CPU cycles) to meet the audio rate demands. If the player can execute the audio rate properly, then the focus moves on to video. The player will attempt to get as many frames per second as the video requires. Once the video is achieved, then the remaining cycles get fed to animation and logic.
There is actually some interesting reasons on why this priority order is defined. Once again, Chris Giffith provided some great insight into this at SDFUG. Psychologically, audio is more important to us then video. Back in the day of over-the-air Television, when the reception was bad as long as the audio was clear we could deal with mostly crummy images. But, once the audio went out people would change the channel. Well, this applies today with the Flash Player. We can handle a few video frames dropping but if the audio cuts out the experience is pretty much over. To prevent this from occurring the player has defined this timing order.
Understanding this timing order is important because it can effect how an application is implemented. If you want to run high quality audio/video while attempting to perform serious time-sensitive logic, this is more then likely going to be a challenge. Moving the video quality down, or adjusting the logic system may be required to achieve the best experience for your user. Understanding what gets priority helps you make a more informed decision when trying to implement or troubleshoot these kinds of applications.
Versioning SWFs (not the Player)
You can read up all about versioning in the first post from the 2007 series, but here is the short and sweet of it: versioning of a SWF is virtual and can affect how it is executed in the player. Every version of the Player, has an implementation model of all the previous versions of the Player. So, if you made a SWF back when Player 6 was out, and try to run it in Player 10.1, the SWF will behave as it did back with Player 6, bugs and all (critical bugs in the player are fixed). That means, if Player 9 fixes a bug that you want in your old SWF, you must recompile the SWF to the new version to take advantage of that, this is all done so not to "break the web".
What's New in Player 10.1's Infrastructure?
First off, Out of Memory is now handled gracefully. In past versions, if you ran out of memory the Player just crashed. Not good, especially when you consider out of memory is potentially going to happen a lot more on mobile devices.
The other new infrastructure feature that Lee talked about was managing multiple instances of the Player. One of the challenges of limited CPU and memory availability on devices is having multiple instances of the Player running. Even if the apps running are the most well thought out, efficient programs; running multiple instances, such as how the Palm Pre allows multiple apps windows at once, will quickly kill the device. To prevent this the player team is looking at having non-browser players pause other instances of the player when not in focus, or have the other players "downclock" to lower framerates automatically.
What this would do is, as you spawn new instances of the player and they gain focus, the other instances would be aware and then either stop execution or lower their framerate to minimize CPU usage. The issue the Player team is facing is that this kind of Player "magic" can have all kinds of unwanted repercussions. For example, Local Connection between the two instances more or less breaks. If you build an app that communicates with another app on a moblie device and the Players pauses or downclocks this can ruin your experience, which is not a desired effect. Because of these potential issues, this feature is still in development and may not be complete or even part of 10.1 at launch.
Bonus round: global error handling. Lee didn't mention this, but it was brought up in one of the keynotes about player 10.1. You can now place a try/catch at the top of your application to catch all those tricky errors. This is a huge new feature for developers. The rouge root error has always been the bane of the Flash Developer's world since the new AVM2 added them. I have yet to see an example of how this works, but as soon as we do we will post examples on DevelopmentArc.
That's all for part 2, 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.