<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 12, 2010, at 6:20 PM, Jonas Sicking wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Fri, Mar 12, 2010 at 4:19 PM, Jonas Sicking <<a href="mailto:jonas@sicking.cc">jonas@sicking.cc</a>> wrote:<br><blockquote type="cite">On Fri, Mar 12, 2010 at 3:38 PM, David Levin <<a href="mailto:levin@google.com">levin@google.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking <<a href="mailto:jonas@sicking.cc">jonas@sicking.cc</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt <<a href="mailto:oliver@apple.com">oliver@apple.com</a>> wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm not saying that the proposed API is bad. It just doesn't seem to<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">solve the (seemingly most commonly requested) use case of<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">rotating/scaling images. So if we want to solve those use cases we<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">need to either come up with a separate API for that, or extend this<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">proposal to solve that use case somehow.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Just for reference I think one thing that people are forgetting that<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">there is a difference between<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">being computationally faster, and being more responsive.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">As I mentioned in my email, if you look at the steps listed, enough of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">them happen *on the main thread* that you're spending far more of the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">main threads CPU cycles than you'd like. Possibly even more than doing<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">all the resizing on the main thread.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">With the other improvements suggested by David things do definitely<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">look different, but those are not in a proposal yet.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">There is the other scenario I mentioned, but I'll see what I can do about<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">separately working up a proposal for adding those methods because they were<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">next on my list to deal with. (fromBlob/load may be enough for this.)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Note that the other proposals that have been made has put toBlob on<br></blockquote><blockquote type="cite">HTMLCanvasElement, not on the context. That makes the most sense for<br></blockquote><blockquote type="cite">the main-thread canvas as that way its available on all contexts.<br></blockquote><br>Oh, another thing to keep in mind is that if/when we add fromBlob to<br>the main-thread canvas, it has to be asynchronous in order to avoid<br>main thread synchronous IO. This isn't a big deal, but I figured I<br>should mention it while we're on the subject.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>This is part of why I think Blob is the wrong tool for the job - we really want to use a data type here that can promise synchronous access to the data. When you copy the canvas backing store to a new in-memory representation, it seems silly to put that behind an interface that's the same as data to which you can only promise async access, such as part of a file on disk. There's nothing about copying bits from one canvas to another that needs to be async.</div><div><br></div><div>(Also it's not clear to me why a Blob would be faster to copy from, copy to, or copy cross-thread than ImageData; I thought the motivation for adding it was to have a binary container that can be uploaded to a server via XHR.)<br><div><br></div><br><blockquote type="cite"><div>In general I wonder if we should add API to convert directly between<br>Blob and ImageData. Or at least Blob->ImageData and<br>ImageData->ByteArray. That could avoid overhead of going through a<br>canvas context. That is probably a win no matter which thread we are<br>on.<br><br>We could even add APIs to rotate and scale ImageData objects directly.<br>If those are asynchronous the implementation could easily implement<br>them using a background thread. I'm less sure that this is worth it<br>though given that you can implement this yourself using workers if we<br>add the other stuff we've talked about.<br></div></blockquote></div><br><div>Scaling and rotation can be done with just pixels if you code it by hand, but you can get native code to do it for you if you can manipulate actually offscreen buffers - you just establish the appropriate transform before painting the ImageData. REally the question is, how much slower is a scaling or rotating image paint than an image paint with the identity transform? Is it more than twice as expensive? That's the only way copying image data to a background thread will give you a responsiveness win. I'd like to see some data to establish that this is the case, if scales and rotates are the only concrete use cases we have in mind.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>