Note: On Nov. 1, 2007 I made a small change to the title of this article. The original title was “Flash Player Astro’s personality conflict…” (substituting “identity crisis” in the current title with “personality conflict”). However, I realized that “personality conflict” wasn’t the most accurate term for what I was trying to communicate, and “identity crisis” seemed like a better fit.

If you attended the North America MAX 2007 conference or tried to keep up with the news that was pouring out, you probably know that in the day 1 keynote address Emmy Huang and Justin Everett-Church demoed three new features of “Astro” (the “next version” of Flash Player):

• An improved text engine, allowing new capabilities like bi-directional text, re-flowing column text fields, and more.
• The ability to create custom graphic filters, rather than being limited to the built-in set in ActionScript.
• “Postcards in space” 3D transformations that can be applied to display objects to position/rotate them in 3D space.

I think there’s something funny about these three features and the way they’ve chosen to implement them. I didn’t really notice it when I first watched the demo video (no, I wasn’t at MAX), but later it jumped out at me as I was reading some of the responses to the demo in the PaperVision 3D email list, and even more so as I listened to the video interview that Lee Brimelow did with Justin Everett-Church later during MAX, in which Justin clarifies and expands on the three Flash Player features that were described. If you don’t want to jump away to watch the video (although it’s really good for understanding the new features) here’s a transcript of the most important statements Justin makes relating to my idea:

(:29) Justin: “[Astro’s ‘3D effects’ and PaperVision 3D] are kind of fairly different from each other…3D effects is kind of ‘3D for the rest of us’. If you wanted to try and use the 3D effects to do more complicated things there may be some APIs that might help you but you know PaperVision’s an excellent solution, you’re just not going to replace one with the other, they’re going after different objectives.”

(2:40) Lee: “There was a lot [of buzz] around filters and the ability to create your own filters, and we heard ‘Hydra’ mentioned. So what exactly is it? Is it a new programming language?” Justin: “So Hydra is a new language, it’s a pixel shader language. The Hydra language itself is very consistent with other pixel shader languages…the port between [Hydra and other pixel shader languages] is really easy.”

(4:10) Justin: “So our new text layout engine is really a group of hooks in the Flash Player that are lower level than we’ve ever had before. On top of that we’re building a series of components so they will do things like multi-column flow, inline HTML, bidirectional text, ligatures, lots of complex [?] sorts of things. But those components are developed in ActionScript 3.0 and will be deployed as part of your application. The hooks that are there are going to be exposed to developers so if you want to build your own component, if what we do isn’t exactly suiting your needs then you’ll be able to build a first-class text control.”

Notice that, based on the way Justin describes it, the idea for the improved text engine is that the actual functionality provided by Flash Player/ActionScript is very low-level, and Adobe provides components that give the higher level functionality we expect from a standard text field object (as well as additional enhanced versions).

Think about that for a moment.

Imagine if the flash.text.TextField class, the display object that’s used any time text is displayed in an ActionScript app, were actually a component on top of some lower-level API – and non-Adobe developers could freely write their own version of the TextField class, using those same low-level APIs.

By the same token, imagine if the built-in filters (the flash.filters.* classes) were actually “components” or library classes written on top of some lower-level API. (In fact, I think that’s how lots of developers see them, especially since they all derive from the flash.filters.BitmapFilter base class – with the notable issue that developers can’t create their own BitmapFilter subclasses and use them in ActionScript.) So imagine if you were allowed to create your own BitmapFilter subclass, and Flash Player would use it along with any of the Adobe-provided filters.

Yes, obviously the low-level aspect of the filters involves writing them in Hydra, not in ActionScript, and I really don’t have any idea how that’s all going to get hooked together. Just bear with me – I’m trying to describe big concepts here, not small details =)

Can you see what I’m getting at? That’s exactly what’s happening with two of the three new Flash Player features that were presented at MAX – Adobe is providing a low-level API, much lower than what most developers are going to need to use, and then they’re also providing components or libraries that will be the standard tool that most people will actually use. I think that’s an interesting approach, and one that the advanced developer community is going to really latch on to even while it doesn’t cause any pain or extra work for the typical developer.

However, compare that to the 3D (or 2.5D, as it’s often called) functionality that was shown at MAX. As Justin says, it’s intentionally a high-level API – 3D “for the rest of us” – compared to projects like PaperVision 3D that are working to provide full-fledged 3D modeling, textures, virtual world capabilities, etc. The PaperVision community isn’t so thrilled about this. Naturally they don’t think the player needs a high-level 3D API – they see PaperVision as providing the high-level API, and they’d much rather see the player provide new low-level APIs and/or improved processing power that allows them to do more, better with their higher-level APIs. (I’m paraphrasing and probably mis-describing this to some extent, since by I am by no means a 3D expert or even intermediate-level developer.)

As another aside, it occurs to me that the idea that Flash Player APIs are “high level functionality provided by the Flash Player team written in ActionScript” isn’t actually new. It’s a well-known fact that a notable amount of the Flash Player functionality is actually written in ActionScript and not in C++ or C or assembler code. In those cases the only difference between the built-in functionality and an external ActionScript library that you or I write is that the ActionScript code comes pre-installed in Flash Player and doesn’t have to be part of a SWF file download. An interesting historical note related to this is the history of the XML class (the old-school one that lives on as flash.xml.XMLDocument). The XML class was introduced in Flash Player 5, and in that release it was written entirely in ActionScript and consequently suffered from some speed issues in how it parsed XML. The ActionScript developer community (Branden Hall, I believe) wrote an alternative implementation known as XMLNitro that was faster than the built-in one. Back then in ActionScript 1, it was fairly straightforward to “redefine” methods of the built-in classes so that the player used your own ActionScript code instead, so that’s what many people did to get faster XML parsing. Funny, isn’t it, that with the newer constructs added in ActionScript 2.0 and ActionScript 3.0, we’ve also lost some functionality – namely the ability to overwrite built-in functionality with our own code. That was definitely a low-level capability that was previously available in Flash Player.

Interestingly, even in modern (i.e. post Adobe-Macromedia merger) history this idea of “low level APIs with higher-level components on top for normal use” isn’t completely new in “Astro”. One obvious precedent is the Flex framework; however, the example I’m thinking of is part of the Flash authoring tool. Historically Flash authoring was released simultaneously with new versions of Flash Player, and consequently there were always new authoring tool features that corresponded to new player features (obvious example: the filters and blend modes that were added in Flash 8 to Flash authoring as visual tools and to Flash Player as ActionScript APIs). Interestingly, however, in Flash CS3 there were some authoring tool features that were added that didn’t have a corresponding player API. Specifically I’m referring to the “copy motion as ActionScript” feature that allows you to select a tween sequence on the timeline and copy it “as ActionScript” – the animation becomes ActionScript code that you can paste somewhere and use to re-create the animation programmatically. What I think is notable about that authoring tool functionality is that the pasted code doesn’t work as-is via a player API – rather, it requires some external ActionScript libraries that were included with Flash CS3 (the fl.motion. and fl.transitions. packages). So the functionality underlying that feature of Flash CS3, one of the headline features of the product (created by none other than Robert Penner), was completely independent of the core Flash Player APIs and was instead provided by an external library.

Think about it this way: the Flash authoring tool team wanted to include functionality that wasn’t provided in core Flash Player ActionScript. It was specifically a “high level” type of functionality – simple scripted animation. Other people have written their own APIs to do the same thing, using the ActionScript “low level” APIs (display object properties, enterFrame events, etc.) and the Flash authoring “high level” approach does the same thing – it provides a library of code to simplify a certain task, so that users can easily create the effects they want, within the limitations of the high level library. I see this as another existing example of this idea of core ActionScript providing low-level functionality, with third parties and also Adobe providing high-level functionality in the form of ActionScript libraries that build on top of that low-level functionality.

Now, going into the future, there is a new Flash Player feature that allows the player to cache certain Adobe-approved code libraries, so the user downloads them once and then they’ve got them for every future site they visit that uses the same library. We’ve heard that the Flex framework is going to be the first such “cacheable” library. However, if this feature had existed earlier it could obviously have been used for the ActionScript classes that are used to support the Flash CS3 simplified animation (“copy motion”) functionality. For that matter, the Flash CS3 UI components could be given the same treatment and be available as a cacheable library, although that might be less necessary by virtue of their “intentionally lightweight” design.

While I really can’t say for sure, it seems like it’s not a stretch that the new text components would be distributed this way, especially since, as Justin points out, “those components are developed in ActionScript 3.0 and will be deployed as part of your application.”

I think that, going into the future, this is a potential direction I can see Flash Player and ActionScript moving in:

• Flash Player/core ActionScript provides low-level APIs
• Adobe provides components or libraries written in ActionScript that provide high-level-enough (“medium-level”?) functionality such that most common use cases and functionality are provided for. Probably these components/libraries are external, player-cacheable code libraries rather than part of Flash Player itself.
• Third-party developers can likewise create their own components and libraries that either build on the Adobe-provided components/libraries or provide alternate implementations.

Of course, the obvious exception to this way of working is the new 3D effects, which are very high level and are essentially the end user functionality, rather than providing low-level building blocks on which Adobe and/or third party developers can build more robust libraries.

What do you think of this future? Does it sound good, or scary? I’d love to hear your thoughts on this one…

Disclaimer: While I am an Adobe employee, I actually had very little knowledge of these “Astro” features until watching the MAX keynote presentation. I had heard general descriptions of some of them, but certainly nothing like the level of detail that was given by Emmy and Justin in the keynote and follow-up interview. Likewise, since then I haven’t gotten any additional “insider” information about these or other future Flash Player features. Obviously some of what I say in this post is speculation about the future, and I readily admit that it is indeed speculation and nothing more – I don’t have insider knowledge on this, and I might be completely wrong about all of it. =)