[whatwg] More random comments on the putImageData definition

[Ian Hickson]

On Sun, 10 Feb 2008, Robert O'Callahan wrote:
> 
> So for ImageData, how about making the image data array have, by 
> default, one pixel value per canvas coordinate unit? If we really need 
> to expose a higher-resolution underlying buffer, then add an API to get 
> the device-pixel per canvas-coordinate-unit ratio, and extend 
> createImageData and getImageData so the ImageData array dimensions can 
> be given as optional extra parameters. Then it would be hard for an 
> author to be surprised by an unexpected ImageData array size.

On Sun, 10 Feb 2008, Oliver Hunt wrote:
> 
> That said, basically what you're saying is that canvas should not 
> support hidpi.  At all.  There is no need to request the dpi of a 
> canvas, but (and here's the critical bit) you can't have 
> get/putImageData work at a different resolution from the backing buffer.  
> Their sole purpose is to be a 1:1 mapping to the canvas backing store, 
> so saying get/putImageData should work in canvas pixels and not device 
> pixels seems to defy the whole reason for this API existing.

Indeed.

The problem with having the current API not give you 1:1 data is the 
future:

If we have one API, high-res only:

   People who use it correctly:
      get good results both today and tomorrow.
   People who use it wrongly:
      get good results today.
      will get cropped or visibly wrong results tomorrow.

If we have two APIs:

   People who use it correctly:
      get good results today.
      may get either ugly results tomorrow, or good results tomorrow.
   People who it wrongly:
      get good results today.
      get ugly results tomorrow.
   More people will use it wrongly, since it's more complex.

So we trade cropped or visibly wrong results for ugly results, and good 
results for possibly ugly results.

I don't think it's a good trade. It raises the level of "bad" to be 
slightly less "bad", but lowers the likelihood of getting perfect 
results, while simultaneously increasing the API complexity.

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