
<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 1:00 PM, David Levin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br>On Thu, May 20, 2010 at 11:30 AM, Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br>><br>> I'm not clear on why this API is needed. ... This API seems much less general than offscreen canvas, so it's subject to the same criticism and you can't even make the argument that it also serves other use cases.<br>

<br>The criticism for the OffscreenCanvas was <br>1. it made the core use case of image resizing rather complicated and<br>2. depending on the browser's implementation, there may be faster ways to do the image resizing than doing it on a worker.<br>

<br><div>The net suggestion that "This supports the idea of specialized API..." -- <a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html</a><br>

<br><div>This is exactly what we are doing (and it addresses those criticisms).</div></div></blockquote></div><div><br></div><div>Is the purpose of this API performance or convenience?</div><br><div>It seems like the proposed API is so specialized that it's only really useful to resize an image immediately before transferring it over the network in some way. Is that really so much more common than any other resizing that it needs a specialized convenience API?</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>