On Feb 11, 2008 11:37 AM, Oliver Hunt <<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;">
<div style=""><br><div><div class="Ih2E3d">On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:<br><blockquote type="cite">On Feb 10, 2008 10:07 PM, Oliver Hunt <<a href="mailto:oliver@apple.com" target="_blank">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;"> <div>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.</div>
 </blockquote><div><br>Why not?</div></div></blockquote><div>Because the purpose of get/putImageData *is* to get to the device pixels, that's their purpose, making them not do that is both bizarre, breaks the semantic that putImageData(getImageData(x,y,w,h), x, y) will leave the canvas unchanged</div>
</div></div></div></blockquote><div><br>Yeah, that makes sense...<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div>
<div class="Ih2E3d"><div> and the cost of sub-/super-sampling removes the whole "speed" thing that the API was originally added for.</div></div></div></div></blockquote><div><br>Not so sure about this. Script manipulation of pixel data probably isn't going to be faster than native, probably hardware-assisted resampling.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div class="Ih2E3d"><br></div><div>Yeah, unfortunately we all know the web authors tend to favour the "it works now, so must be correct" philosophy -- it's looking more and more like i will be forced to convert the canvas from hidpi to 1:1 the moment any of the imagedata/toDataURL routines are used.  *sigh*</div>
<font color="#888888"><div></div></font></div></div></blockquote><div><br>That would break your sensible invariant that putImageData(getImageData(x,y<div>,w,h), x, y) leaves the canvas unchanged.<br><br>It would really suck to lock canvas into a 1:1 device-to-CSS pixel ratio forever. Seems to me putImageData/getImageData isn't worth that risk. Maybe we should introduce it later when developers are more likely to encounter the DPI issues for themselves.<br>
</div><br></div></div>Rob<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]