[whatwg] proposed canvas 2d API additions

[Vladimir Vukicevic]

On 4/21/06, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 21 Apr 2006, Vladimir Vukicevic wrote:
> > On 4/21/06, Ian Hickson <ian at hixie.ch> wrote:
> > > On Fri, 21 Apr 2006, Vladimir Vukicevic wrote:
> > > >
> > > >     boolean pointInPathFill(in float x, in float y);
> > >
> > > This sounds fine to me (though it means you have to spin through
> > > creating many paths for hit testing, instead of just hanging on to a
> > > particular path and hit testing a list of paths, which seems silly).
> >
> > Hm, I'm not sure what you mean -- we have no way of holding on to a
> > "Path" as a retained object.  If we did, then you could hit test through
> > this object; there would be a speedup for some paths, but not noticable
> > for most, I would think.  Adding support for retained path objects would
> > be an additional chunk of work, though, and isn't really necessary.
>
> I was suggesting that we may wish to add that code.
>
> Consider a <canvas> implementation of a board game with many little
> pieces. You get a click and want to find out which piece the click was on.
> With the API above, you basically have to redraw the entire board, except
> instead of calling .fill() on each one, you call .pointInPathFill(). That
> seems painful. Then again, you have the same problem with .fill() in the
> first place, so maybe it's not a big deal.

I don't think it's a big deal either; creating the path itself is
typically not the expensive part of those operations, and not having a
retained-path mode simplifies the API.  There are things we can borrow
from OpenGL that can help here if we want a more complex picking API;
specifically, you would enable a special picking mode, and then before
drawing any object (as complex as you want), you would assign it a
tag.  You end up building up a scene with regions "filled" with these
tags; then you submit x,y queries and you get back what tag is at the
given coordinate.

Note that with getPixel(s) you can do basically that right now -- use
an offscreen canvas, draw each pick-shape in a different color, and do
picking queries against that offscreen canvas.  Would be quite fast,
especially if your base scene that you want to pick to doesn't change
all that often.

> (Incidentally, I would prefer isPointInPathFill() or isPointInPath() for
> this method name, since it is a test that returns a boolean.)
>
> Assuming nobody has any problem with:
>
>    boolean isPointInPath(in float x, in float y);
>
> ...then I'll add that to the spec when you reply to this mail.

Sure, isPointInPath sounds fine.  We can always add
isPointInStrokedPath if we ever want to bother with that (which is
where the "...Fill" bit came from in my API, because the region
covered by a stroked path and that covered by a filled path are
different, even though testing for a hit against a filled region would
by far be the common case).

> Incidentally, what JS type did you mean float[] to map to? A simply Array
> instance?

Yeah; there's some JS2 stuff that might help optimize this in the
future, but a simple Array for now.

    - Vlad