- From: Rik Cabanier <cabanier@adobe.com>
- Date: Sun, 7 Jul 2013 22:11:39 -0700
- To: Doug Schepers <schepers@w3.org>, Jon Williams <jon@shovemedia.com>
- CC: "public-geometryapi@w3.org" <public-geometryapi@w3.org>
Hi Doug, thanks for starting the page! I agree that it would be very useful to find the intersection of 2 paths. Most often you'd like to find if a path intersects a rectangle or bounding box (ie for hit testing) so maybe this could be another function I'm not sure if we need to create a routine that does this for stroked paths. Rather, I would like to see a routine that gives you the "shape" of a stroked path and use that to find intersections. We should also start small. There's no need to tackle everything and we can always add more later. Personally, I would like to build upon the path routines in canvas and make them compatible with SVG. Rik ________________________________________ From: Doug Schepers [schepers@w3.org] Sent: Sunday, June 30, 2013 9:10 PM To: Jon Williams Cc: public-geometryapi@w3.org Subject: Re: things often done in geometrical applications Hi, Jon- On 6/28/13 4:17 PM, Jon Williams wrote: > >> Thanks for getting this going. > > Second that. Thanks! I'm glad there's interest! > I'm curious about the scope of this effort. I can think of a billion > uses for primitive geometry calculations, but I feel like this project > needs a short list of example use cases that the browser manufacturers > can't easily dismiss with "use JavaScript". I think you hit the nail on the head. To me, I think this effort will be most effective if it focuses on a cohesive set of methods that either make complex operations easier or significantly faster, or make nigh-impossible things possible. As you say, a geometry API could do any number of things, but in the end, it should just be supplemental to the code authors will have to write anyway, just as the JS Math object gives basic math primitives. In the Web Audio WG, we had good success with establishing what we wanted it to accomplish by laying out our use cases, and deriving requirements from that; we started with all the use cases we could think of that might be useful, then discussed their relative priority; for medium or high priority items, we wrote requirements that covered them. The more (and higher-priority) use cases that a particular requirement met, the more important we decided it was. I took the liberty of starting a Use Cases and Requirements page [1], based on the format we used for the Web Audio API. I also agree that we should make an effort to be disciplined in what we decide are priorities, because we need to make something that browsers will actually implement and ship! And that same discipline will help us focus and get something done in a reasonable time frame. [1] http://www.w3.org/community/geometryapi/wiki/Use_Cases_and_Requirements Regards- -Doug
Received on Monday, 8 July 2013 05:12:05 UTC