Default Blend Modes

Closed: 8/22/08

Issue A - Overlapping translucent elements

The default blendMode in FXG is "normal", meaning graphic elements appear in front of their parent Group's background, the pixel values of the graphic elements override those of the Group's background, and whenever the graphic element is translucent, the Group's background is visible. This means that in Thermo/Flex, objects living in a translucent Group show through each other as per the Flash Player rendering model, but in CS tools like Illustrator and Photoshop, alpha is applied to the correct elements but intersecting areas do not show through. For example, the following code:

<Group alpha="0.5">
<Rect height="60" width="110" x="0" y="0">
<fill>
<SolidColor color="0xff0000"/>
</fill>
</Rect>
<Rect height="60" width="110" x="45" y="30">
<fill>
<SolidColor color="0x0000ff"/>
</fill>
</Rect>
</Group>

Results in this rendering in Flex/Thermo:

While in Illustrator, looks like this:

As a way to address these rendering differences between Flash/CS tools, the player introduced a new blendMode value, "layer". When a "layer" blendMode is set on a Group, each object in such a Group is rendered into a separate, temporary surface (per-scanline) and these are then composited together into the Group. So, to get Illustrator fidelity in Flash with regards to the example above, you would simply add a blendMode="layer" to the Group tag:

<Group alpha="0.5" blendMode="layer">
<Rect height="60" width="110" x="0" y="0">
<fill>
<SolidColor color="0xff0000"/>
</fill>
</Rect>
<Rect height="60" width="110" x="45" y="30">
<fill>
<SolidColor color="0x0000ff"/>
</fill>
</Rect>
</Group>

Note, these fidelity issues only come up in the case of translucent elements.

Issue B - Filled/Stroked translucent elements

A similar issue is in the case of translucent filled and stroked elements. In CS tools, alpha is applied to filled/stroked elements as a whole so that code like this:

<Rect x="5" y="5" alpha="0.5">
 <fill>
  <SolidColor color="#0000FF" />
 </fill>
 <stroke>
  <SolidColorStroke color="#ED1C24" weight="10" />
 </stroke>
</Rect>

Appears like so:

In Flash, the fill and stroke are treated as two separate objects, so applying per-object opacity means the fill appears behind the stroke like so:

This is an annoyance to Thermo users who create their content in FXG, especially in the case of 1-pixel strokes (since thick strokes are not as common) because the blending of the fill and stroke color creates some unusual new color in the areas that overlap.

Proposal for Issue A

Change the default blendMode value in FXG from 'normal' to 'layer' since CS tools are not exporting a blendMode="layer" value when needed, but are assuming the rendering change is occurring in FXG processors. This change is basically a no-op in most rendering procedures, except in the case of translucent elements that do not have any other blendMode applied to them. This will require pushing through a change to the FXG 1.0 specification, or adding it as a change to the FXG 1.1 specification. Note, when a blendMode value is set explicitly on a Group (to any of the possibilities enumerated here), that blendMode will be respected.

SDK Details

Though the default value of blendMode is being changed to 'layer', in the SDK implementation of FXG, we will keep blendMode as 'normal' until a change occurs which would result in a rendering difference. This "change" can occur in 1 of 2 ways:

1.) A Group has its alpha value set such that 0 < alpha < 1
2.) A Group has a color transform applied to it which results in a change in alpha channel, where the resulting alpha value is > 0 and < 1.

When case 1 is encountered, we will change blendMode of the Group to 'layer' and switch it back to 'normal' if/when the alpha of the Group is set back to 1. This is in order to minimize the player performance hit that comes with blendMode="layer".

TBD on whether deciphering when case 2 is encountered is even possible (under investigation), though its important to note that CS tools and Thermo do not provide a UI to set color transforms so it would need to be done programmatically.

Proposal for Issue B

We have decided to deal with this issue as a Flash Player rendering limitation and leave it as-is in the Flex SDK. A workaround is available for users to hand-code, where they can add a Group around the filled/stroked/translucent element and hoist the alpha value to the Group, like so:

<Group alpha="0.5">
 <Rect x="5" y="5">
  <fill>
   <SolidColor color="#0000FF" />
  </fill>
  <stroke>
   <SolidColorStroke color="#ED1C24" weight="10" />
  </stroke>
 </Rect>
</Group>

Since we auto-set blendMode to layer when the alpha is applied to the Group, the Rect will appear as it does in AI. The Group will appear in Thermo's Layers panel.

Concerns

1. Need to make a change to FXG spec
2. Performance implications, especially when 'on the fly' modifying of alpha values occurs (ex: Fade effects). Need to run further tests to evaluate the performance hit. The performance hit occurs because when a node with blendMode='layer' is encountered during Player rendering, the Player creates a separate bitmap object per-scanline per-node to render layer mode cases.
3. Normally, FXG represents the Flash Player rendering model 'to a tee'. We are averse to adding ActionScript to workaround Player limitations/idiosyncrasies, and instead let the Player fix it and incorporate the new behavior into a future iteration of FXG. In this case, we felt that blendMode="layer" encapsulates rendering the way people would expect, even though it is a departure from the current Player rendering model.