<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 22, 2010, at 3:03 AM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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></blockquote><div><br></div>Just to be clear, readback is never "cheap". The cost of readback isn't so much the image size, but the fact that you need to stall the pipeline, do the read and then fill the pipeline again. So anything happening on the GPU (not just in your app, but systemwide) will slow down the readback and the readback will slow everything else.</div><div><br></div><div>Readback is just generally evil and should be avoided at all costs :-)</div><div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>-----</div><div>~Chris</div><div><a href="mailto:cmarrin@apple.com">cmarrin@apple.com</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline"></span>
</div>
<br></body></html>