I love Adobe AIR! I think it’s an amazing platform with a huge amount of potential. However, AIR has one problem that could earn it a bad reputation before it has a chance to truly realize that potential – idle CPU usage.

Try this on a Mac: open FlashCS4. Create a new, completely empty FLA and publish it as an AIR file. Install it, run it, and examine it in Activity Monitor. On my brand new MacBook Pro, that completely empty AIR application uses nearly 4% of my CPU. Doing nothing. In the background.

Now look at the types of applications that are popular on AIR: Twitter apps, news apps, notification apps, mashups. Applications that are designed to be left open all the time. Open a few of these up at once, and you’re committing a decent chunk of your CPU to them. And that’s when they’re doing nothing. I typically have 10-20 applications open at all times. If these were all AIR applications, half of my CPU would be used just from having them open.

Expected CPU use for an idle application doing nothing is ~0%. An acceptable level is <1%. AIR must fit into this range cross-platform to be a serious contender on the desktop. This issue does not affect Windows. I haven't tested on Linux yet. It's also worth noting that this problem isn't limited to AIR, it appears to be an issue with the player itself. Try the same test with an empty SWF running in the standalone player or the browser, and you'll notice the same kind of CPU usage. I believe this may be part of the reason that FlashCS4 on the Mac eats so much idle CPU - it has at least 2 instances of the Flash player running in it, one for stage core, and one for panels. I've been in contact with the team at Adobe, and they have acknowledged that they are aware of the issue, and are actively working to address it. Despite that, I felt it would still be good to write this post for three reasons: The first reason is to create awareness of this issue, and hopefully through that awareness help to generate some external pressure on Adobe to fix the problem in a timely manner. If you feel this issue is important to you, spread the word about it, and please vote up bug #FP-2009 in the Flash Player bug system. To do so, register on Adobe’s JIRA bug system, do a quick search for “FP-2009”, and vote for the issue using the link in the left column.

The second reason is that I’ve had to explain this issue to our clients a few times recently, and I thought it would be useful for other developers to have a post explaining and validating the issue so they could refer their own clients to it.

Finally, I thought it would be good to provide a location where developers can share tips on working around this issue until Adobe addresses it. As a start to that, I have created a simple class that will automatically reduce your application’s frame rate when it is in the background, and restore it when it regains focus. You can also temporarily restore the framerate while in the background (for example, if you loaded some new data and wanted to transition it in smoothly). Reducing the framerate is the best method I’ve found so far for improving idle performance. Using the class is simple:

// this should be called as soon as your application starts up and has an open window.
// the first parameter is optional, and specifies the background fps to use (default is 1)
FramerateThrottler.initialize(2);
// set enabled to false to temporarily restore the framerate while in the background, or prevent it from reducing the framerate
// when your application moves to the background:
FramerateThrottler.enabled = false;
// you can also specify whether to only use this feature when running on a Mac:
FramerateThrottler.onlyThrottleOnMac = true;

You can download the FramerateThrottler class here.

Update:
Robert Christensen, Sr. Product Manager for Adobe AIR has posted an entry on the AIR Team Blog addressing my concerns titled “Performance Tips for Adobe AIR. I think its awesome how responsive Adobe is to issues like these! Thanks Rob!

Arno Gourdol, Sr. Engineering Manager on the Adobe AIR team just posted a blog entry on “Writing well-behaved, efficient, AIR applications“. The suggestions break down to reducing your framerate (see above), and minimizing the use of Timers and enterFrame listeners. Worth a read.

Update 2:
As a real world example, we added FramerateThrottler to an AIR application we are currently working on. It was originally using 5-10% CPU idling in the background, with FramerateThrottler it’s now using 0.5%. We also tried setting mouseEnabled and mouseChildren to false on the stage of all open windows while in the background, but that had minimal effect, dropping it to ~0.4%.

I recently decided to retest my results on uint, int and Number performance to see what had changed in Flash player 10 (more on that in my next post). I got a little carried away, and wound up building a generic performance testing harness for ActionScript 3. I’ve been meaning to do this for awhile, but hadn’t gotten around to it until now. It’s not that its very complicated, it just required a lot of thought into specifically how I would want it to work.

I think the nicest thing about the test harness is how flexible it is. You can easily use it to quickly test a couple of functions on the timeline, or you can build a full set of performance testing suites to support a project under development, similar to unit testing.

Even test suites are super simple. Point it at an instance of a class, and it will test all the public methods on it. Or, use properties or parameters to formalize the tests with names, descriptions, and specific method lists.

You can even use PerformanceTest to test the render time for complex vectors or filters.

You can also easily customize how it logs the results of tests to output them differently, save them to a file, or graph the results.

Continue reading →

Adobe just released the “ActionScript 3.0 Client Library for Facebook Platform API”, which is a wordy name for a pretty straightforward AS3 Facebook API we’ve been working on for the past few weeks.

The library is an updated version of a library originally developed by Jason Crist. We’ve been working with Adobe, Facebook, and Jason to extend it to support all of the Facebook APIs (Canvas, Connect, and Desktop), and to clean up some of the code. That’s not to imply that Jason’s original work wasn’t great, there’s just a limit to how much you can do for free as one guy on an open source project.

The end result is an open source AS3 API that mirrors the documented Facebook API almost exactly. We’ve also added a few helper methods, and some samples to make it easier to get started.

You can get more info here, or grab the library from google code here.

As many of you know, the project panel in Flash CS4 is a rebuilt version of the gProject panel that Adobe acquired from us. For a variety of reasons, the project panel shipped with a few rough edges that I was never entirely happy with. So when we had some free time here at the office, we looked to rectify some of those issues. Here are the major changes:

• Skinned to match the CS4 interface (based on Library panel)
• Tightened up the actions menu
• Added a utilities submenu, which you can add your own utilities to
• Specify whether to open files in Flash or via the OS on a per file type basis in Panel Preferences > Settings
• Option to import assets to stage or library in Panel Preferences > Settings
• Shrunk some dialogs, and made them scroll to reduce minimum panel size
• Added more file type icons
• Added an API for scripting the panel with JSFL (details below)
• Minor UI tweaks

Continue reading →

We just announced the winners for round 1 of tweetcoding. There was a surprise tie for first place between @tomee6’s “diagonal snake” and @piXelero’s “Tunnel of Stripes“. Thankfully, our wonderful sponsors, Adobe and Friends of Ed, were nice enough to accommodate the tie, and both winners will be getting a copy of Flash CS4 and AdvancED ActionScript 3.0 Animation.

The two runner ups, @vectorcinco’s “the drummer” and @dickwolf’s “Ghost Marquee” will each receive a copy of AdvancED ActionScript 3.0 Animation.

All three judges (me, Ted Patrick, and John Grden) had a very difficult time narrowing down the field of almost 250 entries to our winners and runner ups. We judged entries based on aesthetics, code, interaction, and uniqueness at time of submission. It’s a testament to the high quality of submissions that with 3 of us making top ten lists, we wound up with 24 different entries.

“diagonal snake” is an amazingly functional game for 140 characters of code, even having a death sequence. “Tunnel of Stripes” is highly polished with the glow effect and even some basic interaction. “the drummer” was an awesome example of interactive sound in so little code, and “Ghost Marquee” both looks good, and has some insane code powering it.

Be sure to check out the #tweetcoding round 1 winners page to see these entries, and the other 20 entries that made our judges lists.

We will definitely be holding another #tweetcoding contest in the near future. I’m working with a couple of people to polish up the interface and automate things a little more. I also want to incorporate the language translations people graciously provided. Once that’s done, I’ll probably put out an open call for people to suggest gimme code frameworks.

Thanks again to our sponsors (Adobe and Friends of Ed), our judges, @machine501, and everyone who contributed an entry, blogged it, tweeted it, or otherwise got involved. It was a ton of fun, and I can hardly wait until the next one.

I started the #tweetcoding contest on a whim, with no real expectation of what the result would be, and I’ve been absolutely floored by the level of participation, and the quality of the entries.

The idea was simple: See what people could code in 140 characters of AS3 (the number of characters in a single tweet). The results were unexpected: Hundreds of participants and entries, some of which are simply amazing.

It was really incredible to watch ideas and themes evolve as people built on them. It was educational watching people employ new tricks to squeeze out every possible character – I even learned a few things. It was entertaining to watch people get addicted to #tweetcoding, and submit entry after entry, even after swearing this one was the last (I’m looking at you Mario).

Overall, it was one of the most active, fun, and positive community activities I’ve been involved in recently. I’m really happy to have been a part of it, and am very impressed by the Flash Twitter community – it makes me wish I had started tweeting earlier.

I’d link to some of the more impressive entries, but as a judge I don’t think that would be appropriate. You can check out all of the entries on this page, which was put together by @machine501, and was instrumental in the success of the contest.

I guess I should get back to the hard work of judging, and getting ready for the next round. Thanks again to the sponsors (Adobe and Friends of Ed) for providing prizes, and to everyone that participated!

I am @gskinner on Twitter.

“140 characters isn’t good for debugging code.”

Yesterday evening, when @kevinSuttle said that to me on Twitter it sparked a thought, that grew into an experiment, that expanded into an idea, and finally ballooned into a contest.

Kevin’s tweet got me thinking… “What could you code in 140 characters of AS3?” I spent a little time experimenting, and found out the answer was “not a lot”. Still, it crystallized the idea of building a contest around it. I spent a little bit of time assembling a simple page to outline the contest, asked for feedback, revised, and launched the contest.

You can check out the #tweetcoding page for full details, but here is a quick overview. You are provided with a framework of 140 characters of “gimme” code. To this, you can add up to 140 characters of additional AS3 code. You submit your entry via Twitter, and if your work is judged as the best, you win a full copy of Flash CS4.

The thing I find coolest is how this came together so rapidly and organically. It was about 6 hours from the initial thought to the start of the contest (including an hour for dinner), and it incorporated feedback from a handful of people. Within 24 hours there were already a number of interesting entries, a prize (FlashCS4 – thanks Adobe!), and online tools to help people track and participate in the contest.

You can check out one of these online tools, made by @machine501 that compiles entries directly from Twitter using the Flex compiler, and lets you follow all the #tweetcoding action without needing to start up Flash.

Check out the #tweetcoding rules page to enter the contest, or for more information.