Re: Method for finding intersection points

Interesting!
It seems that this library only works on polygons and not on paths.
The library that the skia folks are developing should not have that
limitation.


On Thu, Jun 20, 2013 at 4:36 PM, Dmitry Baranovskiy <baranovs@adobe.com>wrote:

> I agree that this is important improvement. This is why I add it to
> Raphaël. Just like operating with matrices, it’s a vital part of API if you
> actually use code for graphics generation and manipulation. But if we want
> to look at good example, instead of rough solution that Raphaël provides I
> would point to JavaScript Clipper[1]. As a developer I would love to see
> this functions available in browser alongside with matrix commands and
> offset calculations. Would be awesome if I can do it on path string instead
> of the given element, this will give ability for better optimisation, such
> as Web Worker use, asynchronous API, etc.
> I would love to participate in this spec development as much as I can.
>
> [1] http://sourceforge.net/p/jsclipper/wiki/Home/
>
> On 21/06/2013, at 5:21 AM, Rik Cabanier wrote:
>
> If you just want to find the intersections, it's actually trivial to
> implement. It seems Raphael implements this.
> The hard part is to optimize path (= remove path segments that are painted
> on both side), making paths impervious to winding rules and doing
> operations like union and xor
>
> On Wed, Jun 19, 2013 at 12:05 PM, Stephen Chenney <schenney@chromium.org>wrote:
>
>> It's a very hard thing to implement correctly for all cases, and a call
>> might be rather expensive. I worry that different implementations will give
>> different answers under surprisingly simple situations.
>>
>> Still, I think we will reasonably soon have the ability to do this in the
>> Chrome back-end (Skia) so for us it might be a fairly easy thing to
>> implement.
>>
>> Thanks for providing motivation for the change.
>>
>> Stephen.
>>
>>
>> On Wed, Jun 19, 2013 at 9:19 AM, Doug Schepers <schepers@w3.org> wrote:
>>
>>> Hi, Nikita-
>>>
>>> I strongly agree.
>>>
>>> In writing apps with SVG and JS, I've wanted to have an easy way to get
>>> intersections for many different things. I'm currently using Kevin
>>> Lindsey's intersection library on a personal project.
>>>
>>> I actually believe that we should work on a more comprehensive API for
>>> point, vector, and matrix math (including intersections), which could be
>>> used for both SVG and Canvas (and possibly CSS); JS libs like Sylvester [1]
>>> and mjs [2] are a good start, but would have better performance if
>>> implemented natively in browsers. I don't have the math skills to do this
>>> myself, but if we could find someone to help spec it out, I could
>>> facilitate the spec production.
>>>
>>> [1] http://sylvester.jcoglan.com/
>>> [2] http://webgl-mjs.googlecode.**com/hg/docs/files/mjs-js.html<http://webgl-mjs.googlecode.com/hg/docs/files/mjs-js.html>
>>>
>>> Regards-
>>> -Doug
>>>
>>>
>>> On 6/19/13 6:27 AM, Nikita Vasilyev wrote:
>>>
>>>> I propose to implement a method for finding intersection points for
>>>> basic shapes and paths.
>>>>
>>>> svgElements.**getIntersectionPoints( svgElement )
>>>> -> Array of points, e.g. [{x: 1, y: 120}, …]
>>>>
>>>> There are JavaScript libraries for this
>>>> http://www.kevlindev.com/**geometry/2D/intersections/<http://www.kevlindev.com/geometry/2D/intersections/>
>>>> http://raphaeljs.com/**reference.html#Raphael.**pathIntersection<http://raphaeljs.com/reference.html#Raphael.pathIntersection>
>>>>
>>>> There is a getIntersectionList method which calculates intersection
>>>> using bounding boxes of the elements
>>>> (http://dev.w3.org/SVG/**profiles/1.1F2/publish/struct.**
>>>> html#__svg__SVGSVGElement__**getIntersectionList<http://dev.w3.org/SVG/profiles/1.1F2/publish/struct.html#__svg__SVGSVGElement__getIntersectionList>
>>>> )
>>>> It does NOT return intersection points.
>>>>
>>>> Motivation
>>>> Finding intersection is commonly used for drawing and prototyping
>>>> applications such as Adobe Illustrator to "snap" objects.
>>>>
>>>
>>>
>>>
>>>
>>
>
>

Received on Friday, 21 June 2013 00:04:31 UTC