<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 20, 2010, at 8:13 PM, David Levin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, May 20, 2010 at 7:55 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><br><div><div>On May 20, 2010, at 6:24 PM, Robert O'Callahan wrote:</div><br><blockquote type="cite">On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.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">
<div style="word-wrap:break-word"><div><div></div>I'd also love to hear from Mike Shaver and others from the original thread what they think of this API proposal.</div></div></blockquote><div> </div></div>I think Shaver's feedback still applies: on any device with a GPU, we can optimize canvas and/or rendering enough that scaling images is no problem on the main thread. So this API would have a short useful lifetime ... possibly negative.<br>
<br>Coming thread full circle, I now think there are good use cases for off-main-thread canvas, in particular with WebGL, but I guess that deserves its own thread again :-).<br></blockquote></div><br></div><div>As far as I can tell, the proposed API doesn't enable resizing off the main thread. It is an API on HTMLImageElement so you can't call it from a worker. And it returns synchronously so the main thread has to block until the resize is done regardless. It returns a Blob, so I suppose it may be possible that the intent is to make a magical blob that's actually backed by a background thread asynchronous computation instead of data. That wasn't clear to me from the proposal. It would be a little weird.</div>
<div><br></div></div></blockquote><div><br></div><div>The proposed api has a callback for the blob, so it is totally async. We attempted to return the blob sync (and do everything hidden in the background), but blob.size wouldn't be known (so it would need to throw or block, etc.) </div>
<div><br></div><div>Sample code from the proposal:</div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div class="gmail_quote"><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; white-space: pre-wrap; "><p>
var successEvt = function (newBlob) { myDiv.innerHTML += "<img src='" + newBlob.url + "' />"; };</p><p>i.getBlob("image/jpeg", 300, 350, successEvt);</p><div><br></div></span></div></div></blockquote></blockquote><br></div><div>Ah, I misread the proposal. Didn't realize it had call backs.</div><div><br></div><div>In that case - why add an asynchronous API for this when there is evidence that adequate responsiveness can be achieved with a sufficiently optimized nonblocking API? Surely an async API is not more convenient on the whole. So the only reason to add it would be for performance, but it seems that could be achieved just by optimizing canvas sufficiently.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>