Polygon's share of its rectangle inconsistent?

[Dar Scott]

Yeah, the lineSize idea doesn't get far (at this point) when the function is looking at the entire rectangle and returning 100% in my case

I don't know if this is a function bug or a dictionary issue.  From the dictionary...

	If the point is within the clickable area of the object, 
	the within function returns true, 
	even if another object is layered on top of the object.

	If the object is a graphic, 
	its interior is considered to be within the graphic 
	only if the graphic's filled property is true 
	or the graphic is selected.

Since the entire rectangle seems to be the clickable area of the graphic, the entire rectangle in my case, the second paragraph makes no sense.  Also, it is not clear to me why filled is considered and not opaque.  I'm missing a lot here.

(There are two coordinate systems used in pixel graphics (for whole number coordinates).  One puts the coordinate grid between the pixels.  This makes sense when looking at the rectangle of things and even when looking carefully at rectangle graphics.  The other looks at the points as being in the middle of the pixel.  It is off (.5,.5) from the other.  If fractional pixel coordinates or pixel-less coordinates come, the differences will be minimal.  When these concepts are mixed we get mixed results.)

Now, I'm surprised.  Why are you getting about 50% when I'm getting 100%?  I'm using LiveCode 5.5.4 on OS X 10.6.8.  I think somebody else was getting 100%, too.  

Because of that, or until we figure out why that is, within() might work on your system but not on others.

I'm not sure what "singly connected" means.  Does this mean a graphic can work like several graphics?

If this does not have to work in the field, you can put your graphic on the appropriate contrasting background and get an image of the bounding rectangle and analyze the pixels.  

Dar



On Jun 8, 2013, at 5:45 AM, David Epstein wrote:

> Thanks to Dar Scott, Craig Newman, and Jim Hurley for thinking about this.  I don't know why the coverage function would yield 1.0 (except for a very small graphic; see glitch described below).  The Dar Scott amendment to my function--subtracting 1 from the right and bottom of the rect that I survey--is, I learned, equivalent to testing whether "pt is within the rect of grcLID"; in other words the pixels on the bottom and right edge of a graphic's rect are not counted as "within" the graphic's rect.
> I tested Dar's suggestions about lineSize and borderWidth.  Perhaps because I have showBorder set to false borderwidth had no effect.  LineSize did affect the results of my "coverage" function, with results that are peculiar but do not solve my original puzzle (that reported "coverage" should not, but does, vary as I scale a shape).
> I resorted to careful study of a very simple polygon, an isosceles right triangle with its hypotenuse toward the bottom left.  This is a case where I would want my "coverage" function to return 0.5, since half of the rectangle is covered by the visible graphic.  Rather amazingly, the "within(graphicLID,point)" function returned true not only for the points I expected, but for 5 additional diagonal "lines" of pixels forming a kind of border extending left and down from my visible hypotenuse.  This was true both for a 10 x 10 rectangle and for a 50 x 50 rectangle.
> This makes it easy to see why "coverage" seems to decline as a graphic gets bigger, since these false positive pixels are a much larger share of a small rectangle.  But why is "within" returning all these false positives?  I tested the "margins" property to no avail.
> One further source of difficulty:
> If I define a grapic’s “points”, LC seems to impose a lower limit of 8 x 8 on its width and height. Thus while a triangle with points 0,0 <cr> 10,0 <cr> 10,10 <cr> 0,0 has 100 pixels within its rect, defining a triangle with points 0,0 <cr> 5,0 <cr> etc. results in an object with 64 -- not the expected 25 -- pixels within its rect.  And almost all of those extra pixels also register as "within" the filled graphic itself, so that "coverage" gets close to 1.0.
> 
> Jim Hurley’s function is very useful, but I was hoping to use “within()” so that I could handle graphics that are not singly connected and closed.  Is there some way to script a test for those cases?
> David Epstein
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode