[whatwg] proposed canvas 2d API additions

[Ian Hickson]

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.

(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.


> > >     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?

Yes, except it doesn't have to be a high-resolution display:

   <canvas height="10" width="10"/>   canvas { height: 100%; width: 100%; }

...should, per spec, work perfectly fine, but each coordinate space unit 
pixel is likely to map to many device pixels, and thus many colors.


> 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?

I understand what you are proposing. What I don't understand is what 
colour should be returned when the many device pixels represented by the 
given coordinate space pixel have different colors.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'