After many years of developers asking for the feature, at Adobe is talking about adding multithreading, or at least some sort of concurrency system to the Flash Player!

I’m surprised it wasn’t bigger news at Adobe MAX 2010, perhaps putting it into the second Adobe MAX keynote. Instead, the news was slipped into the Flex Roadmap session at MAX. Which again is a bit strange, rather than to see it in the Flash Platform Runtimes Roadmap session. The MAX session can be seen online here on Adobe TV and they start talking about it shortly after the 40 minute mark.

In the session Deepa Subramaniam, the Flex SDK Senior Project Manager went over the different ways of how Adobe could implement concurrency into the Flash Player. As the Adobe Flash Player team seems to be still looking to a system that is easy enough for new developers but complex enough for more experienced developers (from scripters to developers to software engineers is how they put it in the presentation).

Speaking of new developers, if you don’t know what multithreading or concurrency is, let me take a moment to explain why this is such a big deal.

One of the issues that you might have experienced in creating Flash content, is creating something where the responsiveness of the Flash UI slows down or stops. This has been documented by Ted Patrick and others as the elastic racetrack. Basically in each frame, there is only so much time to render graphics and to handle code. Too much of either being done in each frame and the famerate slows down and the Flash content lags. Typically it’s having too much code running in a single frame, as the code keeps running until everything that it’s asks to be done in that frame is done. This especially becomes an issue when say parsing a large piece of data, or encoding a PNG file and the UI freezes until this is complete.

There are plenty of tricks and hacks to get around this issue, even a green-threading (simulating multiple threads in a single thread environment). However, ultimately, having some sort of concurrency system creates a proper solution. Then when Flash content does something very intensive, it can do this separately, in a different thread and have the rest of UI still respond to the user, then deal with the results when the process is finished. Also if it’s a multi-core system, the thread can run on a separate core from the main thread, speeding up the process than if it was running on a single core.

Now this is one of the few areas that Adobe had been really falling behind in Flash. As Siverlight has had multithreading since version 2. Also HTML5 introduced something called WebWorkers, to allow JavaScript to run background threads, however it might still be a while before it’s supported on all browsers (Internet Explorer being the one as usual lagging behind, even the latest Internet Explorer 9 betas apparently don’t support it yet). For major applications, this is a serious enough of a issue I’ve personally seen decisions to use Silverlight for a large application being made largely because of the ability to run background threads.

Now I think a good way to introduce threading to Flash that a range of developers would be able to understand and is to use a similar API as found with HTML5′s WebWorkers. Similar APIs means developers switching back and forth between JavaScript and ActionScript don’t have much new to learn and new developers can learn the ActionScript API knowing that their skills are transferable. Also from what I understand WebWorkers having read just a bit about it, is that it’s a simple model that fits Adobe’s guidelines of something that novice developers can handle. Also Jim Corbet from the Flash Player team has hinted in the past at FITC Toronto that something like WebWorkers is likely the way Adobe will.

Before I managed to publish this post, Thibault Imbert from Adobe updated the multithreading feature request on bugs.adobe.com saying the following (just a participial quote, go to the link for full comment):
“…yes bringing MultiThreading to the runtimes would be sweet. But even if the idea of having a full multithread API in the Flash runtimes looks great on the paper, I do believe that this is not hat most of the people expect and want to leverage. A low level implementation would add complexity (locking, shared memory, code marshaling with the display list, etc.) and do not fit most of the cases that people have today on web apps.

So, today we are looking at an incremental approach with a first implementation similar to the BackgroundWorker API in C# or WebWorkers in JavaScript. You want to pass content to it, have the code run in a separate thread, dispatch events (begin, progress, complete) and hide the complexity and expose something easy. This would be valuable for Flex developers (heavy data parsing, number crunching, etc) but also game developers (vector rasterizing to bitmaps, etc).”

It would also make the API similar to what other languages or platforms expose and make transition easier for everyone.”

Many have already responded quickly on the feature request, which many were tracking, that this would be a great implementation that would fit most of their needs. However, well known Flash developer Joa Ebert (one of the main developers of AudioTool) has brought up the possibility of having a low level API which a more simple framework could be built over. So the framework could be built with a WebWorkers model and if that’s not enough for any of the more experienced developers, they could dive into the lower API and even perhaps more complex frameworks could be built. This would be the more ideal solution, unfortunately going on how Jim Corbett has talked about how the Flash Player is built, this might not be possible. As I’ve asked Corbett about multithreading at FITC Toronto years ago and he’s said for proper multithreading it would require a complete rewrite of how the Flash Player works. That such a rewrite might eventually happen but is currently very far down the road. So it might be that WebWorkers model is something that can be built into the Flash Player now until that re-write comes off in the future. Also the fact that Thibault said they are “looking at an incremental approach with a first implementation” sounds like the initial implementation won’t be very advanced.

It’s also interesting, that this topic was introduced by the Flex Product Manager during the Flex Roadmap session. I’m speculating that the reason for this is because Flex Hero SDK uses multithreading. As the reason that Flex Hero SDK does not yet have nightly builds is because it is using functionality built into a future version of the Flash Player that is not yet public. Also the Flex Hero SDK has 3 main goals, one of them being improving large applications development from improving the Flex infrastructure. Currently there are a few things working towards that goal such improving RSLs, but overall not much has been done in this area compared to making the mobile framework and adding new Spark components. However, including multithreading directly into the Flex framework would certain be a huge improvement for Flex developers working on large applications.

Note I give an update on multithreading in Flash here.