[whatwg] proposed canvas 2d API additions

[Vladimir Vukicevic]

On 4/28/06, Vladimir Vukicevic <vladimirv at gmail.com> wrote:
> interface ImageData {
>   readonly attribute string format; /* only "rgba" is valid for now */
>   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.)

Then getPixels is defined to take parameters in canvas pixel space,
and returns the ARGB array in device space; if you ask for a 50x50
region, you'll get back 100x100x4 samples, with a deviceScaling of
2.0.  putPixels would take coordinates in canvas pixel space again,
but would take the appropriate device-pixel-sized ARGB array.  This
becomes tricky with non-integer deviceScaling; that is, if a 2x2
region becomes a 3x3 region with a deviceScaling of 1.5, what do you
return when you're asked for x=1 y=1 w=1 h=1?  I'd say that you end up
resampling and shifting over your 3x3 device space backing store by .5
pixels so that the region would start on a device pixel boundary. 
This would obviously not be a clean round-trip, but the spec can
inform authors how to ensure a clean round trip (only request regions
where your x/y * deviceScaling are integers).

This removes the need for a separate ImageData object and all the
extra gunk necessary there, but still maintains full resolution
independence.  Any thoughts on this?

   - Vlad