[whatwg] More random comments on the putImageData definition

[Oliver Hunt]

On Feb 10, 2008, at 12:41 AM, Robert O'Callahan wrote:

> On Jan 26, 2008 11:57 AM, Oliver Hunt <oliver at apple.com> wrote:
> Another thing that we need is some way to determine what the device
> pixel->css pixel ratio is.  Currently there's isn't even a real way to
> tell that it's 1:1 -- you would have do do a fillRect(width-1,
> height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see
> if they match.  Conceivably you could do this multiple times to
> estimate the ratio, but it would be non-trivial.
>
> I think we have to be careful exposing that ratio to Web developers.  
> With the current ImageData spec it seems too easy for developers to  
> assume a 1:1 ratio, notice that everything works in their tests, and  
> deploy lots of content which breaks when a browser tries to Do The  
> Right Thing on some other device, so we'll all just end up having to  
> fix the ratio at 1:1 (or at least do something equivalent for  
> ImageData).

> (Gecko 1.9 allows the ratio to vary in general for Web content,  
> either due to a high-DPI display device or due to user zooming, and  
> things work pretty well because there is no way for Web content to  
> detect, or depend on, the ratio. Unfortunately <canvas> doesn't  
> currently change its internal buffer size to match.)

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

My original question was due to a mis-understanding of the spec, and i  
am completely happy with the way put/getImageData behave with respect  
to hidpi devices as currently specified (ignoring the issue of  
webdevelopers who blindly assume that just because it works now it  
will always work).

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.
>
> Rob
--Oliver
>
> -- 
> "He was pierced for our transgressions, he was crushed for our  
> iniquities; the punishment that brought us peace was upon him, and  
> by his wounds we are healed. We all, like sheep, have gone astray,  
> each of us has turned to his own way; and the LORD has laid on him  
> the iniquity of us all." [Isaiah 53:5-6]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080210/93c9f181/attachment-0001.htm>