On Feb 11, 2008 12:51 PM, 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=""><div><div class="Ih2E3d"><blockquote type="cite"><div class="gmail_quote"><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><div> <div><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.</div>
</div></blockquote></div><div>Why would the sub/super sampling be done in a script?  one of the use cases for get/putImageData is applying filters to an image -- in that case you just process each pixel, no subsampling needed.</div>
<div>The problem comes from things like <a href="http://jsmsxdemo.googlepages.com/jsmsx.html" target="_blank">http://jsmsxdemo.googlepages.com/jsmsx.html</a> which are not using get/putImageData for image manipulation, but rather for just blitting to the screen.</div>
<div><br></div><div>In terms of performance, a simple testcase a wrote a while ago ( <a href="http://nerget.com/jstests/mandelbrot.html" target="_blank">http://nerget.com/jstests/mandelbrot.html</a> ) shows that putImageData is around 200x faster than the alternative of lots and lots of 1x1rect fills (at least in ffx), in real world terms that means you can easily get to the point that just filling the canvas takes longer than generating the data for the fill.</div>
<div class="Ih2E3d"></div></div></div></blockquote><div><br>Sorry, I wasn't clear.<br><br>I'm just saying that the cost of resampling in getImageData/putImageData would not be significant compared to the cost of script actually manipulating the image data, so "performance" is not a compelling reason to avoid such resampling.<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"><br><blockquote type="cite"><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><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.</div></div></div></blockquote>
</div>But only the first time ther imagedata methods were touched, from that point on the canvas would be permanently locked at the 1:1 ratio, so it wouldn't result in a continual flip-flop between high and low resolution that would occur if you just sub/super-sampled on access.</div>
</div></blockquote><div><br>Right, so it's not pessimal, but it's not great either. It may end up being the best of a bad set of choices.<br><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><div><div class="Ih2E3d"><br><blockquote type="cite"><div class="gmail_quote"><div><div>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.</div>
</div></div></blockquote></div>I'm not sure what you mean here?</div></div></blockquote><div><br>If, 5 years from now, most Web developers have 200dpi screens so browsers are using at least a 2:1 ratio for their canvas backing stores, then putImageData and getImageData could be safely introduced with the current spec, because an assumption that device pixels are the same as canvas units would break immediately in testing.<br>
<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]