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.

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.