[whatwg] proposed canvas 2d API additions

[Ian Hickson]

On Fri, 28 Apr 2006, Arve Bersvendsen wrote:
> 
> I would suggest that we do not use floats for the color values.  While 
> the choice of floats versus integers hardly matters on the desktop, it 
> is a big deal on mobile devices, where you (often) may find that there 
> is no FPU, so any floating point operations are performed entirely in 
> software.  The performance implication of this is huge, and we should 
> not sacrifice performance for theoretical perfection.

This seems like a valid argument.


On Fri, 28 Apr 2006, Vladimir Vukicevic wrote:
> > 
> > How about:
> > 
> >    interface ImageData {
> >      readonly attribute long int width;
> >      readonly attribute long int height;
> >      readonly attribute Array data;
> >    }
> 
> I have a nagging feeling that this is a bad idea, but I can't explain 
> why, because I do like the idea.  If we do this, let's advance it a bit:

I'd rather keep it as simple as possible in the first version.


>  readonly attribute string format; /* only "rgba" is valid for now */
> 
> format would specify the type of data that is in data; only "rgba" would 
> be valid for now, but we this gives us a way to extend that later on.

We can always extend it in the next version by adding "format", there's no 
reason to add it now that I can see. In fact we might (on the long run) 
want to add it to the context instead of the ImageData object, e.g. to 
make the entire API use CMYK or 16 bit RGBA instead of 8bit RGBA like 
today. I think until we have clear requirements on the issue we should 
just avoid adding features to handle it.


> ImageData createImageData(in string format, in string width, in string
> height, in Array data);
> 
> for creating "ImageData" out of an arbitrary set of generated data (e.g. 
> evaluating some function, drawing the results).  This would be 
> especially needed because you can't assign to data in an ImageData 
> structure (since you have it readonly); can only change the values of 
> its members.

You could always create an arbitrarily sized ImageData structure by 
creating a blank <canvas> and using getPixels on that canvas. This would 
let you initialise the array to white, transparent black, or whatever is 
necessary.


> >    ImageData getImageData(in float x, in float y, in float w, in float h);
> >    void drawImageData(in float x, in float y, in ImageData d);
> 
> I would keep x/y/w/h as integers, and explicitly specify that they're 
> not affected by the CTM.  If they are, you can't guarantee a lossless 
> round-trip (since if you shift over by half a pixel you have to do lots 
> of resampling, etc.).

I agree that they shouldn't be affected by the CTM, but I disagree that 
they should be integers. e.g. in cases like:

   HTML                          CSS
   <canvas height=1 width=1>     canvas { height: 100%; width: 100%; }
   </canvas>

...where the JS then uses the coordinate space 0..1,0..1 the author might 
want to grab the top corner by grabbing the 0,0,0.25,0.25 rect.


On Thu, 4 May 2006, Vladimir Vukicevic wrote:
>
> > interface ImageData {
> >   readonly attribute long int width;
> >   readonly attribute long int height;
> >   readonly attribute Array data;
> > }
> 
> Actually, let's step back a second; this may be massive
> overengineering.  What if we simply had:
> 
>    readonly attribute float deviceScaling;
> 
> on the 2D context, which would give the scaling factor between
> canvas-space pixels (that is, the space that the <canvas> width/height
> attributes are in) and device-space pixels (the pixels of the actual
> backing store).  So if <canvas width="200" height="200"/> was
> represented with a 300x300 backing store, deviceScaling would be 1.5;
> if 400x400, it would be 2.0.  (If necessary, we can have
> deviceScalingX, deviceScalingY.)

You'd still need the object if you wanted to extend it in some other way, 
e.g. with your suggested "format" attribute. Your proposal basically just 
moves two attributes from that object to the canvas, and the author now 
has to keep track of the height and width separately all the time when he 
passes the array around to mutate it.


> Also... should the RGBA data be returned with premultiplied alpha or 
> not?  Premultiplied tends to be better for the math, non-premultiplied 
> tends to be easier to understand.  (That is, 50% opaque green is 
> (0,255,0,128) if non-premultiplied, or (0,128,0,128) if premultiplied.)

For consistency with the rest of the API I'd say non-premultiplied, but I 
have no strong opinion on this.

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