[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:
> >     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.

> >     float [] getPixels (in integer x, in integer y, in integer width,
> > in integer height);
> >
> >     void putPixels (in float [] pixels, in integer x, in integer y, in
> > integer width, in integer height);
>
> I don't understand how these are supposed to work when the underlying
> bitmap's device pixel space does not map 1:1 to the coordinate space.

I'm not sure what you mean -- the coordinates here are explicit canvas
pixels, and they specifically ignore the current canvas transform. 
So, given

  <canvas width="100" height="200"></canvas>

the coordinates would be 0..99, 0..199.  Are you referring to the case
where on, say, a very high resolution display the canvas might choose
to create a 200x400 pixel canvas and just present it as 100x200, and
quadruple the physical screen space taken up by each pixel?  If so, it
would still map to the original 100x200 pixels; the fact that each of
those takes up 4 physical device pixels should be transparent to the
user.  That is, we have:

  CSS size (width/height style)   --  canvas size  --  device bitmap size

The API would always operate in terms of canvas size.  Does that make
more sense?

    - Vlad