On Sat, May 22, 2010 at 10:12 AM, David Levin <span dir="ltr"><<a href="mailto:levin@google.com">levin@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
There are a few issues here:<div class="gmail_quote"><div><ol><li>This only applies when you can accelerate with a GPU. Not all devices may support this.</li><li>This only applies to browsers that implement the acceleration with a GPU. When Mike Shaver mentioned this, he referred to a Windows version of Firefox. It is unclear if Firefox supports this on any other platform nor does it seem that all other browsers will support the accelerated canvas in the near-ish future.</li>

<li>The gpu results are due to the fact that the operation is done async from the call (which is great as far as not hanging the UI until you try to get the data out of the canvas, which leads to...).</li><li>Even with gpu acceleration, in order to use the result in an xhr, one has to get back the result from the gpu and this is a more expensive operation (because getting the data out of the gpu is slow) as indicated by the indirect copy results from Firefox  and forces the completion of all of the operations that were being done async.</li>
</ol></div></div></blockquote><div> </div></div>1. Phones have GPUs now. You won't see new devices being built that can run real Web browsers but don't have some kind of GPU, because the limiting factor on hardware now is not silicon but power.<br>
2. Your proposal depends on browsers that implement your new API. As a browser developer, I would rather make canvas faster across the board than implement new API.<br>3. The GPU results are largely because GPUs are massively parallel.<br>
4. The Firefox results include time to unpremultiply data and premultiply it again, all on the CPU. They don't indicate how long readback from the GPU actually takes on that machine. Also:<br>4a) the cost of readback is proportional to the size of the scaled image, so if your use case is scaling down images to small sizes, readback is cheap.<br>
4b) you can easily read back and send one chunk of the scaled image at a time<br><br clear="all">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]<br>