Scale 9, MXML Graphics and FXG
6/25/08 The Problem
The flash player has limited, restricted support for Scale 9. Specifically, When a scale 9 grid is applied to a display object A,
- The grid won't scale correctly for child display objects of A
- The grid won't scale correctly if A is rotated
- The grid won't slice graphics with a bitmap fill correctly.
Unfortunately Scale-9 is an important feature for Thermo to allow designers to easily define simple, high performance layout behavior on groups of graphic elements. Because we believed Scale-9 to be an important part of the feature set for designers, and because some support is defined in many of our CS tools, we added the definition of Scale-9 to the FXG interchange format.
The Scale-9 feature in FXG was designed to match the expected behavior of a Future Flash Player, rather than the current limited behavior of Flash 10. Specifically,
- A scale grid can be applied to any group.
- The scale grid applies to all descendants of the group. They should behave as though they were transformed into the coordinate space of the group, then had the scale grid applied to them as normal.
- the scale grid applies regardless of the transformation of the group itself.
- the scale grid correctly slices BitmapGraphic children of the group.
Unfortunately, the player schedule has changed; there will likely be no player release that contains scale-9 fixes for quite some time.
A complication
In Gumbo, we have intentionally abstracted away the concept of the display object from the user. Flex users author in terms of components -- controls, groups, and vector primitives -- all of which may or may not result in child display objects at runtime, depending on what features the developer makes use of. The result: A flex developer will have a hard time predicting which elements a scale-9 grid will effect and which ones it won't.
6/28/08: Cory, NJ, Ely, Jason, and Deepa meet to review possible solutions and pick a plan of action.
Possible Solutions
Option 1: Get a fix from the player.
We've sat and hashed out the details with the player team, and come to consensus on what the desired behavior of the player is, which more or less matches the defined behavior in FXG. Specifically, Scale grid should inherit through child display objects, should function independently of the trasnform defined on the target display object, and should optionally slice bitmap objects added to the display list.
However, this adds up to about 3 man months worth of work, and has no chance of making it on to any schedule any time soon.
Option 2: Correct as much functionality as we possibly can in actionscript.
Some of the problems we might be able to solve with some tricky actionscript. Specifically, when a group with a scale grid tries to resize, it should
z) make sure that every child is rendered into a display object, o
a) calculate the position of each child as though it were laid out at its measured size.
b) calculate the intersection of its scale grid with each child in the child's own coordinate space, and apply that intersected scale grid to the child.
c) translate and scale each child so that it ends up at the right size and location if the parent had been scaled to match its intended size.
Additionally...
- this process must be recursive...the resulting scale and grid applied to a child group will be instead pass on to _its_ children, etc.
- bitmap graphics must make sure to render their content as separate filled rectangles sliced along the scale-grid passed in to them.
However, limitations still exist. Specifically, this process will only work if the child elements have no rotation or scale applied to them, and the grid will still be ignored if the parent display object is rotated.
Option 3: Live with the current limitations of scale 9 in the player
Simply put, we're trying to build a lightweight framework, and writing complex grungy actionscript code to partially solve missing features in the flash player isn't aligned with that goal. A perfectly reasonable option is to accept the limitations of the feature, and try and help customers understand how to structure their content to take advantage of it.
The major problem with this approach is how difficult it will be for a customer to understand what will and won't work in a scale grid. As it stands today, a vector primtiive inside a scale grid will break whenever it is converted on the fly into a display object. Specifically, if...
- it has a filter
- it has s a blendmode
- it has any transform
- it has an alpha or color transform.
Additionally, we have separate legacy support for scale-9 when embedding bitmaps that a use to automatically slice up an embedded bitmap to match a scale grid.
Resolution
We decided unanimously that we should choose option 3: live with the limitations of the player. We'll mitigate the confusion by looking for more scenarios where we can optimize away a vector shape's display object, which would keep scle 9 relevant. Specifically,
- simply applying a translation to a vector object won't require its own display object
- applying an alpha to a vector object will manually composite the alpha down into the object's fill and stroke rather than requiring a display object.
Additionally, we'll investigate opportunities later in the schedule for Thermo to warn users when a scale-grid will fail, and help correct the situation at design time.
|
