Fwd: Again with the getIntersectionList()

Boris

The scenario you describe below is useful for finite integer math, in
rendering engines for example, where you are dealing with pixel sets.
In floating point Cartesian math, they all all intersect.  Euclid said
so.


---------- Forwarded message ----------
From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Fri, Nov 13, 2009 at 11:26 AM
Subject: Re: Again with the getIntersectionList()
To: Doug Schepers <schepers@w3.org>
Cc: www-svg <www-svg@w3.org>, Jeff Schiller <codedread@gmail.com>


On 11/13/09 3:49 AM, Doug Schepers wrote:
>
> A) SVGRect1 {x:20, y:20, width:0, height:0}
> getIntersectionList( SVGRect1 );
>
> This is essentially a point that will return everything that intersects
> that point, regardless of document order

I would have actually expected this to return nothing, since all
intersections are empty (zero area)...

If that's not what's intended, the spec needs to be _very_ clear on
this, and then all sorts of interesting issues are raised.  For
example, does a rectangle with x=0,y=0,width=5,height=5 intersect a
rectangle with x=5,y=5,width=5,height=5?  I posit the intuitive answer
that most people would want is "no".  How is this different from the
case above?

For what it's worth, in Gecko rectangles in the css renderer are
effectively considered closed on top and left and open on bottom and
right; so a rectangle with x=0,y=0,width=5,height=5 is described by
the inequalities: 0 <= x < 5, 0 <= y < 5.  Hence the two rectangles I
describe above do not in fact intersect, and any rectangle with
width=0 or height=0 is the empty set.

I'm not sure what Gecko's svg implementation does in this regard,
though I suspect it's similar.

-Boris




-- 
Cheers!
Rick

Received on Saturday, 14 November 2009 05:33:45 UTC