[whatwg] getImageData/putImageData comments

[Ian Hickson]

On Sun, 31 May 2009, Boris Zbarsky wrote:
> 
> 1)  It may be worth noting that if the canvas backing store is stored
>     as premultiplied rgba, then getImageData right after a putImageData
>     may well not return the values in the CanvasPixelArray that was
>     put, due to rounding when converting to and from premultiplied
>     colors.

I've added a note to this effect. I don't know how many people will 
understand it, but...


> 2)  The description of putImageData says it "Paints the data from the
>     given ImageData object onto the canvas".  It may be worth
>     specifying that this uses the SOURCE operator, though this is
>     clear later on when defining what the method _really_ does.

That's the author description, which is non-normative and trades precision 
for accessibility, so I've not added this text. I recommend not reading 
those sections as an implementor.


> 3)  It's not clear to me why imagedata actually exposes device pixels,
>     nor is it clear to me how this is supposed to work if the same
>     document is being rendered to multiple devices.  Is a UA allowed
>     to have a higher internal resolution for a canvas (in device pixels)
>     and then sample when painting to the device?  This might well be
>     desirable if the UA expects the canvas to be scaled; it can well
>     reduce scaling artifacts in that situation.  It doesn't seem
>     reasonable, to me, to expose such super-sampling via imageData;
>     it's entirely an optimization detail.
> 
>     Worse yet, the current setup means that a script that tries
>     createImageData, fill in the pixels, and then paint it to the
>     canvas, needs to fill different numbers of pixels depending on the
>     output device.  I fully expect script authors to get this very very
>     wrong, since it's such non-intuitive behavior.  It would make more
>     sense to just have the script work entirely in CSS pixels; if it
>     wishes to create a higher-resolution image it can create a canvas
>     with bigger dimensions (and scale its actual display via setting
>     its width and height CSS properties).

The long and short of this is that if we solve this problem today, the 
solution will be abused as much as the current API, and we'll have to 
introduce yet another solution when high-res backing stores are common. So 
instead I'm hoping that (a) authors won't screw this up, and (b) high-res 
backing stores will be implemented sooner rather than later. If we fail 
with (a), which is more likely if (b) is delayed, then we'll just 
introduce a higher-res API later, and designate this one a lost cause.

We definitely don't want to have people have to know what the resolution 
of the user's display is to get high res results. <canvas> should always 
be the most optimal graphics, whether the author is doing manual filtering 
or not.

Also, I'm not really convinced that the use case you describe is common. 
If you have sprite data, use drawImage(). The putImageData() API is really 
intended for filters and generated patterns, both of which would want to 
be as high-res as possible.

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