<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 6:24 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">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>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>Regards,</div><div>Maciej</div><div><br></div></body></html>