David’s review was really enthusiastic and he concludes by saying “All in all, the session was amazing. To say I’m now excited by Flex 4 is probably the understatement of the year.” What made this so satisfying to me is that he is a hardcore C#/.NET developer which is a group that I've felt is important for Adobe to reach.

On the Yahoo Blog, Steve Webster liked the talk but also had a question that I thought would be good to answer. The question was:

“I can't help but wonder why Adobe created FXG and retrofitted all their creative tools to read and write the new format, when SVG is already here and supported by all those tools and more.”

The First Flex Graphics Prototype

The effort to add graphic tags to Flex actually began over 2 years ago when I created a series of prototypes to demonstrate how it could work and what it would look like. The goals of what became the initial prototype were to change people’s perceptions as to what Flex could be, to demonstrate that we could make it into a framework for both design and development, and to try to convince Adobe upper management that there was a need for a new tool for designers working on RIA that leveraged the Flex framework. This is what became Thermo.

The first prototype for the graphics tags was in fact a partial implementation of SVG in Flex. I showed this off at a 360 Flex conference in March 2007 and blogged about it here. The way it was built was that I created a set of Actionscript objects whose class names and properties were such that when they were mapped into MXML, they looked like SVG.

I based it on SVG for a number of reasons. First and most importantly, it was a standard that was supported by a variety of tools and by using it as a spec, I could focus on implementation rather than having to dream up a new object model.

Problems Using SVG

In the course of building the first prototype, I ran into a number of issues, some small, some large.

The most serious were those things things that were impossible to do, given the approach I was taking. For example, on all shapes and containers, SVG defines a “transform” property that is a string. However, on DisplayObjects, Flash already defines a "transform" property, and it's not a String. As a result, I had to rename my svg property to be "transformer", because I could not override a property with one of the same name but different type.

A number of properties and objects required implementations that were unlike other things in Flex and Flash and inefficient. For example the SVG transform is a string that is an expression such as:

<g transform="skewX(30)">

This required parsing at runtime, is not efficient and makes integration with other Flex features such as databinding, states and transitoins more difficult.

The style property on a number of objects defines another of these "micro langauges" that requires runtime parsing. For example it's common to see something like this:

style="font-family: 'Super Sans'; font-weight:normal; font-style: italic"

SVG also exposes a way to essentially bind one object to another such as:

<rect fill="url(#XMLID_8_)"/>

While this had to be parsed at runtime, what was worse is that Flex doesn't provide a DOM of the MXML document so there's no way to look up an object with a specific ID. As a result, I had to build a lookup table of these at runtime. Flex has a different method of doing this same thing, which is to use databinding, so I also supported it in a more Flex native way like this:

<rect fill="{myFill}"/>

Of course, doing this was non-standard and made those graphics incompatible with SVG.

Another class of issues around was around consistency. The Flex and Flash teams have done a ton of work to make all of the API consistent. I myself spent days reviewing every Flash Player and AIR API, looking for any violations of the myriad of design rules we have established.

The first thing you notice when you start looking at some even as basic as SVG names is that there is absolutely no consistency. Here are some SVG tags:

<svg>, <g>, <defs>, <ellipse>, <linearGradient>

Because in MXML each tag maps directly to a class name, I had a classes named "svg", "g", "defs" etc. This violated a number of design rules for Flash and Flex. For example, we have tried to name all classes with complete, descriptive names, and classes such as "g" don't meet that criteria. Of course, the most basic rule of class naming is that all ActionScript class names begin with an uppercase letter and every SVG class begins with a lowercase one.

Attributes are also named inconsistenly. For example, the main property of a path that people use is named "d" while gradients have a property called "gradientTransform". There is a property on gradient stop called "stop-color", which would be an illegal name in ActionScript.

Probably the biggest challenge I had was when the imaging models were just completely different. For example, Flash objects support a "filters" property, as do SVG ones, but the models are not even close. SVG has very low level filters for things like "ConvolveMatrix" and "SpecularLighting". These can be composited together to create higher level effects. Flash on the other hand has high level filters such as DropShadow and Glow and what I implemented was based on the Flash model.

In the end, what I had was nowhere near complete. There were so many issues with supporting even the limited amount of SVG that I implemented that it wasn't worth finishing. While a number of the more advanced features were never implemented, the prototype could display the type of SVG that you get out of a tool like Adobe Illustrator, and you could modify everything at runtime, including control points, fills, strokes, and filter paramenters, so it served its purpose.

From Initial Prototype to Implementation

After I was done, I reviewed the results with a number of people, including Ely Greenfield and Glenn Ruehle from the Flex team and NJ & Sho Kuwamoto from the Flex Builder Team. What we concluded was that being compatible with SVG would be impossible if we maintained consistency with Flex and the rules of MXML, and that that there was a lot we could do to provide a better, more consistent, and higher fidelity format for Flash that also solved real problems for designers, developers and us in our role of building tools for Flex.

We also realized that, given what was going to be coming down the pike with Flash Player 10, with features like 3D, the Vellum text components and Pixel Bender, that getting locked into SVG would make it more difficult to support these new capabilities.

With that knowledge, I created 2 other prototypes. Both cleaned up large portions of the object model to be more consistent with Flex and the Flash imaging model. But they also diverged from SVG in other functional areas.

For example, one thing I ran into is that rotating objects programmatically is actually kind of diffcult. While SVG has a rotation transform convenience method, this rotates the objects around the origin of the shape, which is often not what is desired. To get a shape to rotate around a given point you actually need to do 2 matrix operations which SVG doesn't make easy to do.

So what I did was to add a transformX and transformY proprerty to the shapes. That way, you could easily rotate an object around a given point without having to do math with multiple matrices. This also more closely matches how Flash presents graphics at design time.

With the prototypes done, I turned the work over to Ely, Glenn, and Deepa Subramaniam, who did the actual design of what became FXG and Flex Graphics. While I don't think any of my actual code survived, a number of the names, designs, concepts, as the lessons we learned by experimenting with SVG did.

I should also note that as word of what we were doing with Flex Graphics and FXG circulated around Adobe, we were asked about why this wasn't just SVG on a number of occasions. At that point, however, we had a lot of data as to why we made the design choices we did, and so we were able to do what we had concluded was the right thing to do.