Last night we launched Flash Player 9,0,60,120, a public beta of our next update to Flash Player. There are some pretty interesting features in it, most notably an enhancement to the full Screen, and a new caching system to let you download the Flex Framework once.

Read on for some details, but also check out Tinic’s Blog and his article about Flash Player 9 Update 3 Beta.

Full Screen:
Full Screen itself is actually a few new features.

First the ActionScript API is updated to let you specify a target rectangle rather. This rectangle will be the only content shown in the full screen view. Even if you select a rectangle that is not the same aspect ratio as the screen, it will still only show your rectangle and will show the background color as bars when needed.

As the player transitions from the web page to full screen, you will notice the next feature, transition. The transition will zoom from the embedded SWF in the browser and quickly take over the whole screen. This transition will give the end user information about what is going on, and what caused the full screen behavior to occur. I like the idea of transitions a lot. This let’s your eye track any elements you are watching as you enter full screen. Otherwise there is some possibility of loss of orientation on the screen during a direct change to full screen.

Once in full screen, the fun really starts. While Flash is painting a LOT more pixels on the screen, you’ll actually see your processor levels fall. Flash Player 9 update introduces “hardware scaling,” and will very efficiently render your content to screen. I’ve seen some internal demos that are pretty amazing. There are a few caveats though.

1. This is beta software!
2. If you are using software like VMWare or Parallels, you may experience a crash. Before going into fullScreen mode, right click in the player and choose settings. In the Settings UI you will find a disable hardware scaling option. Make sure it is disabled to prevent the crash.
3. As a developer, realize that not everyone viewing your content may be seeing it in hardware scaling. If the user’s video card does not support this functionality, the processing will be done through Flash’s traditional method.

Flash Player cache

Also as part of this beta release we are introducing a new way of caching Adobe platform components like the Flex framework. The framework is going to be an externalized file that Flash Player can download, verify and store on your local machine. The next time you need this file, from the same site, or any other site using this same file, you won’t need to download it again.

For Flex users, this means that the Flex framework will not be adding to your application from now on. You can take advantage of the UI components, but still deliver very small SWF files.

Wait, there’s more!
For the rest of the features and enhancements like recursive External Interface calls, multi-core support and more, take a look at the release notes.

I’m starting a new category on my blog called “Why it Works that Way” (WIWTW). I was chatting with some of the user/community groups leaders yesterday and was saying that my favorite part of working on the Flash Player team is that I get to ask all of the questions I’ve wondered about but didn’t know who to ask. Now I just stroll down the hall and ask the person that wrote the feature something to the effect of “Why is the sky blue?”

Normally, I get an answer that makes a great wooshing sound as it goes over my head. Then in realization that I am a mere mortal, I get a really great answer that explains so much about how Flash works in general. You’d be amazed about how a question about transparency has big ramifications on accessibility. Realizing how useful this would have been when I was writing my own code for a living, I want to share some of the answers I’m learning.

So, today’s topic: Object.watch. Watch is a way of monitoring the value of a variable and if something tried to change it, a callback is invocked with the old value, new value, and property name. You can then validate, modify, or otherwise cleanup any values BEFORE they are made into values and any other part of the application can use the values. Anything you returned from the callback would become the new value of the variable.

I LOVED this method in ActionScript 2. I was horrified the first time I got a compiler error in AS3 and discovered my buddy was no longer there. Thinking that it was an oversight, I went and gave my plea/whine to many engineers. Surely everyone would recognize the inherent value of watch! (ok, so I am playing this up just a whee bit). I was really surprised to see that it wasn’t an oversight but a conscious decision and there was very strong feeling that it should never ever come back. I think the exact phrase was “over my dead body.”

Here’s why. Object.watch has a huge performance overhead.

My first reaction was, “well, what if I want to take on this performance overhead in my application to get its usefulness???” Then it was patiently explained to me that it wasn’t just my SWF that would slow down, it was player was always slower just because the capability was there. Removing Object.watch sped up overall Flash Player performance a few percentage points. Every time you set a veariable value, Flash Player was having to check to see if the variable was being watched. As that realization dawned on me I realized that my Object.watch buddy was really more of a little devil sitting on my shoulder tempting me into laziness.

Solution: The way in AS2 or AS3 to do the exact same thing in a more performance friendly way is to set up getters and setters for the variable and then do whatever operations you want. It is a little more work (typing), but actually does have some practical performance benefits. This does have the downside of not working for people that still use frame actions, but I think that is a minor trade off for an across the board speed improvement.

Future WIWTWs
If there is a question you want me to ask about the inner workings of Flash Player or ActionScript, go to this page and submit a comment. I’d like to keep comments on this post relevant to the post itself.

Last Thursday Adobe posted the version penetration data gathered from our June study. The numbers were great! For the United States, Flash Player 9 is at 91.2%. The June study comes right at 1 year of penetration for this player version.
At conferences we have started showing the data in relative comparison to the penetration of Flash Players 7 and 8. Now that Flash Player 9 has reached one year of data, it is interesting to see the curves. While this particular study put Flash Player 9 out ahead by a bit, Flash Players 8 and 9 have penetrated at almost exactly the same rate (Flash Player 7 being a fair bit slower).

The data, while always fun, should give you a good tool to plan out your own Flash deployments. For the entire history of Flash, the penetration rate has never decreased. You should be able to count on any version of Flash Player reaching 80% in 7-9 months and 90% in a year. This holds true for major versions as well as minor versions.

With the features that have been added in the Flash Player 9 dot releases, we’ve been hearing a lot of questions recently about minor version penetration data. For a good read on the subject, I’d suggest reading Emmy’s post.

Yesterday, Emmy Huang and I announced some of the new features that will be going into Astro (The next version of Flash Player). We got a great response from attendees, and I hope you will be equally excited by what is coming next. If you’d like to see the video, take a look at Aral Balkan’s recording.

So what’s new?

Text:
Astro will have a new text layout engine that will expose low-level primitives. This means that we aren’t adding a new TextField, but instead, we are providing hooks that ActionScript 3.0 components will be written on. Adobe is working on a nice set of components that support bi-directional text (also known as right to left text) and layout flows like columns, inline HTML tables, and improved inline image support.

This demo shows a simple paragraph with some not-so-simple elements. The paragraph shows 10 languages including arabic, hebrew and thai. Emmy then demonstrated that as she re-sized the window, the hebrew text break as it should with the left most word dropping down to the next line when it had to wrap. She also demoed the same example translated in to japanese which has a different line breaking rule system (oh! and it was also fully justified text).

3D Effects
Astro will also be adding support for 3D effects focusing on ease of use. Any display object will be able to be positioned and rotated in 3D space by using new DisplayObject APIs like rotationX, rotationY, and rotationZ (which is just an alternate access to existing rotation property). x and y are going to be joined by the new z property that will resize a display object to be in correct size.

The first example I showed was a video of Natzke running in the FLV playback component. By adjusting sliders, I started the video spinning in the X,Y, and Z axes. I swear I wasn’t trying to condemn Eric to to superman’s prison dimension! I also demonstrated a 3D animation tween API by clicking a button and showing the video animating from any starting orientation to a pre-defined location.

The last part of the example was showing that the playback component skin was still fully functional. I could still click on the play/pause button and even drag the seek slider while the video is transformed. Any display object will be able to be rotated with the interactivity still intact.

To show off the APIs a bit, I also showed a more creative example in the form of a galaxy animation made of three movie clips rotating in 3D space. I thought the effect turned out pretty well, but I learned a lot about even more capabilities of the feature that I am looking forward to demonstrating at future conferences.

Custom Filters
While the first two demos were pretty exciting to me, I think the big feature is Hydra. Hydra is a new programming language that Adobe is working on for pixel shading. With this you can write your own filters to be used alongside the existing built-in filters.

Emmy introduced this feature by bringing back Chris Georgenes’s monkey that we used to demo the original filter. We showed the monkey but now looking a bit warped by a new twirl filter. I then demoed the Adobe Image Foundation toolkit which was posted to Adobe labs yesterday! The toolkit let’s you develop Hydra filters and comes with several great samples. Once you compile the filter it will preview it with live adjustable parameters that will apply the filters to any image that you load into the tool.

Already we’ve recieved feedback from develoeprs that are developing some great filters in less than a day of the toolkit being available. If you develop one, post an image of the filter effect online or send it my way, I’d love to see them!

Yesterday, Emmy Huang and I announced some of the new features that will be going into Astro (The next version of Flash Player). We got a great response from attendees, and I hope you will be equally excited by what is coming next. If you’d like to see the video, take a look at Aral Balkan’s recording.

This evening the Flash Player team launched Flash Player 9 Update 3 (9,0,115,0) for Windows, Mac and Linux. Flash Player 9.0.115 is now available through all of the normal distribution means.

There is a LOT packed in to this dot release, so let me point you to our overview article. But some of the big ticket items are:

Flash Player Cache - A new mechanism for caching the Flex framework to make Flex applications small and fast.

H.264 and HE-AAC - Support for playback of H.264 content including many MP4, MOV, and 3GP files.

Hardware scaling - Using the GPU to scale any rectangular portion of the screen to fill the monitor (and fast!). David Hassoun also wrote an amazing article on H.264 support in Flash Player.

Multicore support - Getting more of those processors to pull their own weight and make Flash playback even better.

Leopard support - We official start supporting Mac OS X 10.5 Leopard with this release.

As part of the launch, we’ve updated the Flash Player homepage to make is easier to find new articles and technotes relevant to Flash development. We’ve also updated the Flash Player feature demo to show off some of the new features that are available in 9.0.115. As always, for a full list of features and known issues, please check the Release Notes.

Finally, there are some security model changes that needed to be made in Flash Player 9.0.115. To understand how this may impact your work, take a took at Deneb Meketa’s article on the Flash Player Developer Center.

I’ve had several questions since we launched Flash Player 9.0.115.0 about what new APIs need to be called to play back H.264 video. The short answer is that you don’t need to do anything to use H.264 other than have the new player and some H.264 content.

Well, that is pretty much the long answer too. The cool thing though is that you just don’t need to re-build your SWFs at all. If you have a video player SWF that is exported for Flash Player 7, it can play H.264 media files just the same as it can play FLV files. The “magic” is all in the new player.

I think some of the confusion comes in the form of just what the heck a compatible H.264 file is. There are a few topics that when I try to wrap my brain around them, I feel less informed than when I started. During the development process for 9.0.115, I added video to that list. Let me try and explain what I’ve learned so far in hopes that you can avoid some of the confusion I was suffering from.

Up until this version of Flash Player, we supported two codecs (Sorenson Spark and On2 VP6). Both of these were packaged in an FLV container (how the video bits are organized in a file). Now we have added support for a new codec, H.264, but we require that H.264 content to be in an Mpeg 4 container.

The good news is that this is a really common configuration. Many .mov, .3Gp, and .M4V files are H.264 content in MP4 containers. However, there are times where a .mov file or .m4v file may contain something different. In those cases, Flash Player can’t do anything with them. If you are encoding your files it is pretty easy to get it encoded correctly, but if you are working with already encoded content, the easiest way to see if the file is compatible is to just try playing it in Flash Player and see if it plays back.

Now, if all of that about video codecs and container types (file formats) made sense, thanks for reading, but please stop now. I don’t want to bring yopu back into confusion. For those that are still scratching their heads, let me try a metaphor.

Let’s say that I wanted to communicate the concept of “hello” from a server down to a SWF. The concept gets “encoded” into the English word “hello.” If I had chosen to speak Spanish, I could encode the concept into language as “hola.” Think of this choice as the codec. I started with a raw mental concept of a greeting and chose either an English or Spanish codec.

Now, I need to get that actual word down to a running SWF. That could be through XML or it could be through AMF (remoting). Either way I am sending the English word “hello” but for the SWF to correctly process it and use it in the application I need to serialize the data in a format like XML:

<message>hello</message>

This XML wrapper is like the MP4 file format where FLV might be something more like AMF. Both are great but you can’t use them interchangeably.

For bonus points, There are also things called “profiles” of H.264. Flash Player supports a lot of them, but if you want to extend the metaphor above, a profile is like the character encoding of the text. The concept is still the same, it is still English, and it still will be delivered in HTML, but the way the system turns the characters back into the specific characters h-e-l-l-o is different.

If that last bit lost you don’t worry, you’ll probably get a deeper dive on it should you run into the issue head first. Luckily as a Flash developer that should be a rare case since Flash Player supports such a wide range of profiles.

Its been a while since I’ve done a Why It Works That Way. My apologies, it has been a busy time working on the new Flash Player and doing lots of things for Adobe Max.

One of the questions I’ve gotten a few times has been about security and BitmapData.draw. In Flash Player there are restrictions on BitmapData.draw to prevent content theft. Recently, a “workaround” was found for the restriction on snapshotting RTMP content (streamed video). Unfortunately, one person’s workaround is another’s exploit or bug.

To maintain the protection on streamed content, the bug that enabled the workaround was closed as of Flash Player 9.0.115. However, the Flash Player and Flash Media Server teams recognize the benefits of the functionality and so we’ve created a way to keep the protections while allowing content owners to relax permissions when they want.

This new permissions system for RTMP snapshotting is a two-part solution. It requires a change in Flash Player and also a change in Flash Media Server. The change in player went out this week. On the same day, Adobe announced Flash Media Server 3. Content streamed through the new server can have a flag added that Flash Player 9.0.115 can recognize and then permit the snapshotting code to run.

I apologize for the inconvenience that you may experience during the time between Flash Player 9.0.115 launching and the launch of Flash Media Server 3, but I hope you agree that having the functionality as an actual supported feature is a good thing for building applications.

As a rule of thumb though, using workarounds for security or protection features is not a good idea. You can generally count on the workaround being closed in the next release of the player. The good news is that Adobe listens to its community and we try to provide new solutions that let you do what you want in a supported and safe way.

Future WIWTWs:
If there is a question you want me to ask about the inner workings of Flash Player or ActionScript, go to this page and submit a comment. I’d like to keep comments on this post relevant to the post itself.

One of the talented folks we have on the Flash Player Quality Engineering team has a theory on why some people are getting an error when they try to use BitmapData.draw on a progressive FLV that is even from the same domain.

As I’ve written about previously, there was a security exploit for streamed content that involved detaching and re-attaching the stream to get around BitmapData.draw limitations. This exploit only was relevant to streamed content, but the last piece of the puzzle was that it could be used with no ill-effect on progressive video as well.

So, when the bug was closed in 9.0.115, the fix had a side effect of making the progressive case also not work. The good news is that if you remove the detach/re-attach code that was never needed, your application will resume working as expected. The code you would be looking for is something like:

//Attach the video with netstream object
myVideo.attachNetStream(my_netstream);

// disconnect the NetStream and call draw()
myVideo.attachNetStream(null);
bmpData.draw (myVideo);

// reattach the NetStream to continue playing the video
myVideo.attachNetStream(my_netstream);

The reason you would get this error is because while the NetStream is detached, there is no URL/domain to validate the security context against (as it should be). I have a feeling that this theory is correct. In working with numerous folks that commented on my previous post, none of us were able to re-create the issue on a simple case. I hope it was just because the detach/re-attach code was not added back in that the issue could not be reproduced.

Adobe has announced security changes and enhancements that will roll out with an upcoming security update to Flash Player 9. The Adobe Developer Connection has an article detailing the changes and who is impacted. If any of the following bullets is applicable to you, please be sure to read the article as your content may be affected.

• You use sockets or XMLSockets, regardless of the domain you are connecting to
• You use addRequestHeader or URLRequest.requestHeaders in any network API call when sending or loading data cross-domain
• You provide access to content on remote domains as a web service provider
• You have SWFs that are exported for Flash Player 7 (SWF7) or below that communicate with the hosting HTML by any means
• You use “javascript:” through network APIs to communicate outside a SWF

Keep in mind that the descriptions above are meant to capture a broad group of people. The affected areas are tailored to keep normal usage as unaffected as possible. For instance, while the last bullet tries to capture anyone using “Javascript:,” the actual change only involves “Javascript:” being used in ways that I haven’t encountered before. Normal uses through getURL and navigateToURL will be unaffected.

Also, if you are asking yourself, “Didn’t I just hear about socket policies back in December?,” you’d be right. With Flash Player 9.0.115, a two phased approach was announced for authorizing socket policy files. Phase 1 was implemented with 9.0.115, and phase 2 will be rolled out in the April release. By doing a slow rollout of this new authorization process, we wanted to give developers the time they needed to make changes to affected content before their users have a player that enforces the new policies.

While you are in a security frame of mind, I’d like to point out another article that is on the Adobe Developer Connection. Peleus Uhley, senior security researcher at Adobe, wrote an article on development practices for creating secure SWFs that should be required reading for any ActionScript developer.

The Flash Player team works hard to ensure security within the player, but how you design your application is just as important. The flow of data through an application, the configuration of network and script permissions and even where you host your SWF can raise or lower the exposure to your server. Peleus’s article can provide advice that will be valuable to even seasoned ActionScript developers.