I thought of this about a year ago, while implementing a dot density map in wiscMapper, but never needed to use it until recently. You see, as I noted recently here, to create a dot density map in Flash, it is typical to create random points within the bounding coordinates of the polygonal feature in question (random() * feature.width), test to see if the random point would “hit” the polygon, and place it or disregard it accordingly.
A similar technique is relevant when one needs to know the area (in pixels) of features in Flash where the geometry is not stored dynamically (that is, for predrawn features; if node information is stored dynamically, you should just use a polygon area function — see this for that). With predrawn features, I can just “throw” a bunch of random points at the feature and keep track of the percentage that “hit” (using hitTestPoint()). This percentage, multiplied by the area of the bounding box of the feature, constitutes a pretty good estimation of the feature’s pixel area.
How accurate is it? Well, I did a number of tests, using dynamic data drawn on the stage (I used dynamic data so that I would know the true pixel area of the feature in question). The real determinant of accuracy is the number of random points thrown at the feature. With 100 points, the results were typically off by about 8%.
With 1000, or 5000, random points, the inaccuracy decreased to an average of 1 or 2%.
Remember, this is only cool for features for which you do not have dynamically-stored coordinate data for the features (that is, it would be inappropriate for my recent work on loading shapefiles into Flash).
OK, so here’s some code for a function that will return the approximate pixel area of a passed-in movieclip, sprite, or shape.
