Flash Player 10: Drawing API — Part II

In order to finish the item we left unfinished in the last post, here I present you the third parameter: winding…

Again, enjoy the post!

Source: http://bit.ly/yMloW

winding

The third parameter in drawPath, not used here, is the winding parameter. This is a string that specifies the winding or fill rule for intersecting or overlapping paths. Its values are defined in the GraphicsPathWinding enumeration class:

public static const EVEN_ODD:String = "evenOdd";
public static const NON_ZERO:String = "nonZero";

Winding refers to the direction in which a path is drawn. When paths are drawn clockwise, they””””re considered positively wound. Paths drawn counter-clockwise are considered negatively wound.

Even-odd is the standard fill rule and is the rule used by all of the original drawing APIs. This is also the default for drawPath. The alternate rule is the non-zero rule.

With even-odd, any overlapping paths will alternate between open and closed fills. If two squares drawn with the same fill intersect, the area in which they intersection occurs will not be filled. No adjacent areas will be either both filled or both unfilled. Unlike the non-zero rule, winding with the even-odd rule is inconsequential.

The non-zero rule, on the other hand, depends on winding to determine whether or not areas defined by intersecting paths are filled. When paths of opposite winding intersect, the area defined is unfilled, much like with even-odd. For paths of the same winding, the area that would be unfilled gets filled.

The names even-odd and non-zero refer to a more specific rule that defines just how these fills are handled. Positively wound paths are given a weight of +1; negatively wound paths are given a weight of -1. Given a point within an enclosed area of a shape defined by one or multiple paths, when an arbitrary line is drawn from that point extending on into indefinitely, the number of times that line crosses a path, and the combined weights of those paths are used to determine the fill. For even-odd, the count is used. When the count is odd, the area is filled. For even counts, the area is unfilled. Non-zero uses the weights. When the combined weights are not 0, the area is filled. For 0 weights, the area is unfilled.

It may seem a little over-complicated to have these fill rules, but there are situations where, when understood, they can be of use. For example, consider drawing a star shape. With the standard even-odd rule, that shape would need to be drawn using 10 different lines. With non-zero, that can be reduced to just 5.

Here is that star in ActionScript using drawPath with 5 lines and a non-zero fill.

graphics.beginFill(0x60A0FF);
graphics.drawPath(
 Vector.<int>([1,2,2,2,2]),
 Vector.<Number>([66,10, 23,127, 122,50, 10,49, 109,127]),
 GraphicsPathWinding.NON_ZERO);

So far the shapes used in these last couple of examples have been fairly simple and could have, for the most part, just as easily been created with the original drawing APIs. As you work with move complicated paths, the advantages of the new APIs (namely drawPath) will be much more apparent, especially in terms of performance.

With drawPath, you””””re avoiding much of the function overhead that results from multiple, consecutive calls to lineTo, curveTo, etc. Now, a complicated path can be drawn with a single method call. Additionally, the use of vectors streamlines the data being sent to the renderer. In fact, a new pipeline is being used to handle the drawing data more efficiently and accurately than before. That means drawPath should not only work faster, but also be more precise than the path drawn from lineTo and curveTo. These enhancements can go a long way as you begin to work with more complicated, dynamic drawings in ActionScript.

 

 

 
To Be Continued...

 

 

 

Comments