On Fri, Sep 21, 2012 at 2:12 AM, Ian Hickson wrote:
> On Thu, 20 Sep 2012, Dirk Schulze wrote:
> >
> > The interface of CanvasRenderingContext2D currently has a function
> > called isPointInPath() with a Path object as input [1]. I wonder why
> > this needs to be on the context interface. Wouldn't it make more sense
> > on the interface of Path object itself? If an implementation really
> > needs a context to get a point on a path it, it can create it on it's
> > own.
>
> I don't think it would make _more_ sense, but I agree that it would make
> equal amounts of sense.
>
> In practice you're pretty much always going to have a context around when
> you want to check this, because the reason you'd use it is to see where I
> mouse click landed on a canvas. And you're going to want the Path object
> transformed as per the transform on the canvas, generally speaking.
>
Not necessarily
The path object makes sense outside of canvas as well. You don't need a
context to create it so we are thinking of integrating it with SVG.
It would increase interop and simplfy the API's if you could ask SVG
elements for their path, or create them with one.
Maybe if there was a 'currentpath' property on the 2d context, you can move
'isPointInPath' to the path object.
This would let you get rid of the extra 'isPointInPath' that takes a path
too.
so:
myContext.currentpath.isPointInPath(...)
Most of the time you don't want to know if a point falls in the current
path in the canvas. You want to know after you finish drawing and the user
clicks on the canvas if he hit a region. By then the path in the canvas is
long gone (unless you want to go through the trouble of redrawing
everything).
>
>
> > The only situation that might be reasonable would be a transform on the
> > Canvas that an author want to cover in the Path. But for the rare case
> > where this matters, you can create a new Path object, add your path with
> > the transform and call isPointInPath.
>
> Yeah, you could do that too.
>
>
> > Furthermore, a transform() function that applies to a Path object seems
> > to be useable as well.
>
> You can create a new Path, then add another Path to it while applying a
> transform, using the addPath() method.
>
I agree with Ian that there shouldn't be a method that changes the current
points in a path.
However, if there was a 'transform' function that took a matrix and
returned a transformed path, it would do what Dirk wants.
In addition, the path API's could be simplified since you can take out all
the 'transform' arguments.
Rik
