Adobe to ARM mobile devices with Flash 10


Adobe_flash_1470_1470This coming February will see the first anniversary of Adobe AIR, the company’s cross-platform bridge between computer and web. And when I say computer, I don’t just mean the traditional desktop or laptop. At this week’s Adobe MAX conference, attendees will get a taste of the latest and greatest, Flash Player 10… running on a smartphone.

You can bet that smartphone will be powered by an ARM processor, because the chip designer is a major partner in the OpenScreenProject that’s led by Adobe. What’s the goal of the project? Here’s a big hint in their vision statement: "enable consumers to engage with rich Internet experiences seamlessly across any device, anywhere".  Sounds like the computer experience when on a non-traditional computing device to me and the closest that I’ve seen so far in that realm are in some of the Google tools.

This bodes well for ARM-based netbooks, which I expect we’ll get a good few first looks at when the Consumer Electronics Show rolls around in January. We’ll be checking in with Freescale, NVIDIA, Samsung and Texas Instruments there, as all of them offer ARM-based chipset solutions. However, Adobe says that the joint technology for Flash 10 on ARM11 and Cortex processors won’t be available until the second half of 2009, and that means regardless of smartphone or netbook, we’ll be waiting a bit for that seamless experience. While wait, I have to wonder: we’ve been talking about the browser as our link to the cloud for some time. Should we be giving Adobe AIR a little more emphasis or will it aways be an add-on that we use here and there?


Mark H

I’d love to see Adobe AIR on mobile devices. Imagine using one development environment to create (basic) desktop and mobile applications. Though Java already provides this but support is a bit patchy on Windows Mobile and I believe doesn’t exist yet on the iPhone.

Brian E

The problem with Flash now on ARM processors isn’t that it isn’t optimized for ARMs. The problem is that Flash isn’t optimized for anything. You can offload as much of the video processing as you like, and while that will get you YouTube, it won’t get you acceptable performance on other Flash-heavy web sites.

One part of the problem is in the ActionScript language that’s used to drive Flash interactivity. It’s an extended variant of JavaScript, and like JavaScript it wasn’t designed to be compiled. When you’re just using it to do a little bit of event processing magic, using an interpreter makes perfect sense. When you’ve got it driving your animations, then it starts to break down. Unfortunately the language has picked up a lot of cruft that makes running it fast very, very difficult. The browser vendors are throwing lots of smart people at improving the JavaScript performance situation, and all of that work is applicable in some form to ActionScript, but it will never really be fast. Microsoft has a much better starting point in the CLR (Common Language Runtime) that’s built into Silveright 2.0, but I really doubt they’re going to get much traction here.

Another part of the problem is in the Flash canvas itself. Flash 10 has done a lot to improve this situation, but developers will need to adopt the new features before they have an effect. Right now, even text is done as a set of curves, which prevents the type of glyph-caching optimizations that are typically done in a device text renderer to make antialiased text rendering possible on a small device. Scrolling a Flash text widget can be painful for this reason.

Everything adds up. Like HTML and HTTP and JavaScript, Flash will always be a waste of processor power and bandwidth. I’d like to see a cleaner starting point built around the idea of energy efficiency on the device itself, but that’s a losing battle as compatibility trumps all.

The good news is that it is possible to make Flash several times faster, and Adobe does seem to be on the right track. Between this and the Canonical joint venture for Ubuntu, ARM seems to be heavily investing in optimizing software for the ARMv7 architecture in the Cortex processors. Since the ARM instruction set has undergone rapid evolution, they’d like to see more software optimized for the latest processors rather than built in a compatibility version that runs on processors in five-year-old cell phones. In particular there are instructions in ARMv7 which are designed to improve the performance of dynamic runtimes like Flash. This processor extension was derived from the Jazelle instructions for accelerating Java 2 ME applications, but broadened to make it more applicable to other languages. I suspect that taking advantage of these instructions is on ARM’s agenda here.

Comments are closed.