Group Scale Grid

Problem

The support for scale-9 resizing is confused between Flex SDK, FXG, and the CS tools, and needs to be resolved.

Flex current supports scale-9 only on embedded bitmaps, as it did in Flex 3.  When a bitmap is embedded with scale-9 parameters, those parameters will be respected, regardless of whether the embedded asset is used as a display object inside a UIComponent, the source for an Image, or the source for a BitmapGraphic.

FXG supports specifying a scale-9 grid as properties of a Group instance.  When a scale grid is defined on a group, it is defined to control the way content of the group is rendered when the group is scaled.  The scale grid should apply regardless of whether the content is graphic elements nested directly inside the group, or graphic elements nested inside of sub-groups.  It should apply regardless of how those graphic elements and sub-groups are configured.  MXML Groups do not currently support scale-grid correctly.

Support for group based scale grid will be difficult for a few reasons:

Groups are generally resized, rather than scaling.  A group that resizes simply repositions and sizes its children, rather than applying a matrix based scale transformation. The player's scale-grid support relies on scale transformations, so a naïve implementation of scale-grid on groups would have no effect in most situations.
The player's scale-grid implementation does not work correctly on nested children of the DisplayObject with the scale grid applied.  This means it would be prohibitively difficult for us to support scale grid on Groups with nested sub groups.  
In order to implement many of the features of FXG, graphic elements (rects, paths, etc) often need to create nested display objects. This means that certain features of these elements would 'break' FXG, in a seemingly random manner.  Setting an alpha on the fill of a rect would work fine, while setting an alpha on the rect directly would break any scale-9 applied to the parent group.    Setting transforms, alpha, color transforms, blend modes, filters and ??? Would all break scale grid support.

Why it matters   

For some cases, customers can mimic scale-grid resizing via constraint based layout.  But when using Path elements defined by arbitrary control points, the only reasonable method for resizing them is via the scale-grid feature.  Illustrator and Fireworks both export paths, even for rounded rectangles.  Thus, without scale grid support, content exported from those tools will be prohibitively difficult to make resizable.

Other Possible Solutions

ScaleGrid on Path (and others) directly

    Rather than supporting scale-grid on Group, we can define it on Path, as well as any other GraphicElement where we think it adds value.  This would avoid the error states where scale grid is defined but not functioning correctly, but introduce additional code in Path and others to support resize by scaling, and performance problems when multiple objects are being scale-gridded at once (1 display object per graphic element rather than 1 per group). It also presents the feature in a way not compatible with FXG.
   

enhance the player to eliminate the limitations of Scale Grid support.

    This is clearly an optimal long term solution (and was the basis for putting the feature into FXG), but won't be possible in the Gumbo timeframe.
 

Questions

Should we support Scale grid on Groups, regardless of the confusing usability issues it might raise?

Proposal: Yes.

Can we minimize the usability issues without building fragile and non-performant solutions?

Proposal:  We might have the resources to correct one or two of the things you can do to a group to break scalegrid in Gumbo, but not any of the things you can do to the content of the group.  

Should we consider supporting Scale grid on Paths directly, regardless of the performance issues it might raise?    

Proposal: No. We believe the usability issues with scale-9 on group are preferable to the performance and compatibility issues with scale-9 on path.

Could we solve the problem by removing display-object backing from our graphic elements, and the associated features that rely on it (transforms, alpha, color transforms, filters, etc)?

Proposal: Design use cases make this a non starter.  Designers will expect to be able to control these properties on individual graphic elements, and forcing them to wrap in Groups is unweildy and has worse performance problems.

Should the SDK throw errors when scale-9 will not function correctly?

Proposal:  it should be easy for the SDK to detect when a scale grid will not function correctly, and throw an error.  We should implement this, as it doesn't seem like a likely use case to use scalegrid when only certain content will be scaled correctly.

Proposal

• Scale-grid will be supported on Groups, as per the FXG spec.
• No effort will be made to correct for the limitations of the player when a display object appears as a child of the group.
• We will optionally correct for changes made to the group itself that breaks the scale grid. THis requires further investigation, and is considered B feature.
• Group will throw an error when scalegrid is used and will not function correctly. It will not provide specific information as to what feature caused the malfunction (i.e., there won't be code to determine if it was an alpha property that triggered the display object creation).