One of the little known features that we added to Flex 4 was the ability to use more blend modes in your mxml graphics. Flex supported blend modes in previous versions, however, the only ones supported were those that were natively supported by the Flash Player. This list of blend modes included: add, alpha, darken, difference, erase, hardlight, invert, layer, lighten, multiply, normal, overlay, screen and subtract. A good description of these blend modes can be found in this article on InsideRIA. Adobe Illustrator supports many other blend modes that Flex 4 added support for including colorburn, colordodge, softlight, exclusion, hue, saturation, color and luminosity. Since these blend modes are not supported by Flash Player APIs, the Flex SDK is using wrapper classes for pixel bender filters to recreate the blend modes. If you are curious and want to look at the code for these pixel bender filters, you can find them in <flex_sdk>/frameworks/projects/framework/src/mx/graphics/shaderClasses/ wherever your SDK is installed.
To specify one of these blend modes in Flex 4, you would do something like:
<s:Group x=”580″ y=”400″ blendMode=”normal”>
<s:BitmapImage source=”@Embed(‘ks95553_s.jpg’)” x=”0.5″ y=”0.5″ blendMode=”colorburn” width=”90″ height=”124″ />
Here is a view of what various blend modes in Flex will do.
Blendmode sample: BlendModes.swf
Download source: BlendModes.zip
Flex 4 offers you some new tools to draw graphic primitives like lines, curves, ellipses and rectangles. These new classes are all found in the spark.primitives.* package. They all subclass GraphicElement rather than UIComponent (like all of the other Flex components), therefore, they are more lightweight.
However, there are actually two different ways to include graphics in a Flex 4 application. You can include graphics in your application or skins using “optimized FXG” or MXML Graphics. Optimized FXG refers to the use of .fxg files as mxml components. These .fxg files can be exported from Fireworks, Flash Catalyst (when this product is available to the public), Illustrator and Photoshop. For example, here is a simple png that I created in Fireworks:
If you use are using Fireworks CS4, you can use the menu option Command -> Export to FXG.
This will produce an FXG file like: Star.fxg
Then, in your Flex application, you can simple use this as a custom component.
<g:Star id=”fxg_star” x=”10″ y=”10″ xmlns:g=”*” />
There are some limitations to using optimized FXG, however. While, you can scale, resize and move it, you cannot change any attribute of the graphic. For example, if you wanted to change the colors in the LinearGradient of this star, you would not be able to. The base class that wraps .fxg is spark.core.SpriteVisualElement.
If you want to create graphics where you can change attributes at runtime, then, you will want to use MXML Graphics. Here are the mxml tags that you would use to create the same star:
<s:Graphic y=”20″ horizontalCenter=”0″>
<s:Path winding=”evenOdd” data=”M 50 13 L 65 33 L 90 39 L 74 58 L 75 82 L 50 74 L 24 82 L 25 58 L 9 39 L 34 33 L 50 13 Z ” blendMode=”normal” alpha=”1″>
<s:RadialGradient x = “56” y = “52” scaleX = “81” scaleY = “81” rotation = “0”>
<s:GradientEntry id=”gradientColor1″ color=”#666666″ ratio=”0″ alpha=”1″/>
<s:GradientEntry id=”gradientColor2″ color=”#339999″ ratio=”1″ alpha=”1″/>
<s:SolidColorStroke color=”#ffff33″ weight=”2″/>
Now, that this is defined in an application, you can edit any of the colors of the fill or stroke or the data for the Path at runtime.
In this sample, you can change the gradient colors of the star at runtime using the ColorPickers.
Sample Application: MXMLGraphic_Star.swf
Sample Code: MXMLGraphic_Star.mxml
As of last week, the Flex SDK removed support for the ‘verbose’ syntax for creating Path data. In the past, you could create a Path using two methods:
short syntax, just using the ‘data’ property:
<s:Path data=”M 9 0 L 9 55 L 70 55 z” />
and the long “verbose” syntax which was more readable:
<MoveSegment x=”9″ y=”0″ />
<LineSegment x=”9″ y=”55″ />
<LineSegment x=”70″ y=”55″ />
The long syntax is no longer supported. Here is more information, if you want to know the reasoning behind this change:
Also, here are additional changes that Deepa mentioned in her check-in notes for svn 8589.
1. Path.segments property removed. In its place, there is private variable (segments) which holds the path data parsed into the correct segment objects.
2. Path.segmentChanged() removed ?\226?\128?\147 Segments do not need to notify the parent path when their properties have changed since they are now not individually accessible.
3. PathSegment.segmentHost property removed ?\226?\128?\147 Segments do not need a pointer back to the parent Path since now they are now not individually accessible.
4. PathSegment.notifySegmentChanged() removed ?\226?\128?\147 Segments do not need to notify the parent Path they have changed since they are now not individually accessible.
5. PathSegment.dispatchSegmentChanged() removed ?\226?\128?\147 Path segments do not need to dispatch propertyChange events since they are now not individually accessible. As part of this, I have removed the [Bindable] and [Inspectable] metadata from all PathSegment properties.
6. PathSegment no longer extends EventDispatcher, instead it extends Object.
7. All of the PathSegment and derivative classes no longer have getters/setters for their properties (like x, y, etc) since these properties are now not dispatching property change events.
8. A variety of checkintests/sparkTest project files have been updated to use the compact syntax as they are drawn/transitioned between state changes. Refer to sparkTest/AddItemsTest.mxml and RemoveItemsTest.mxml for examples on how to use states and transitions to transform Paths through the data they are bound to (as opposed to modifying individual segments).