<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><html>On Feb 10, 2008, at 12:41 AM, Robert O'Callahan wrote:</html><br class="Apple-interchange-newline"><blockquote type="cite">On Jan 26, 2008 11:57 AM, Oliver Hunt &lt;<a href="mailto:oliver@apple.com">oliver@apple.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Another thing that we need is some way to determine what the device<br>pixel->css pixel ratio is. &nbsp;Currently there's isn't even a real way to<br>tell that it's 1:1 -- you would have do do a fillRect(width-1,<br> height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see<br>if they match. &nbsp;Conceivably you could do this multiple times to<br>estimate the ratio, but it would be non-trivial.<br><font color="#888888"></font></blockquote> <div><br>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).</div></div></blockquote></div><div><blockquote type="cite"><div class="gmail_quote"><div>(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 &lt;canvas> doesn't currently change its internal buffer size to match.)</div></div></blockquote></div><div><blockquote type="cite"><div class="gmail_quote"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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.</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>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).</div><div><br class="webkit-block-placeholder"></div><div>That said, basically what you're saying is that canvas should not support hidpi. &nbsp;At all. &nbsp;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. &nbsp;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.</div><blockquote type="cite"><br>Rob</blockquote>--Oliver<br><blockquote type="cite"><br>-- <br>"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]</blockquote></div><br></body></html>