- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 20 May 2010 17:50:03 -0700
On May 20, 2010, at 5:48 PM, Maciej Stachowiak wrote: > > On May 20, 2010, at 1:00 PM, David Levin wrote: > >> >> >> On Thu, May 20, 2010 at 11:30 AM, Maciej Stachowiak <mjs at apple.com> wrote: >> > >> > 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. >> >> The criticism for the OffscreenCanvas was >> 1. it made the core use case of image resizing rather complicated and >> 2. depending on the browser's implementation, there may be faster ways to do the image resizing than doing it on a worker. >> >> The net suggestion that "This supports the idea of specialized API..." -- http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html >> >> This is exactly what we are doing (and it addresses those criticisms). > > > Is the purpose of this API performance or convenience? > > 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? Another thought - should the return type here be an ArrayBuffer instead of a Blob? There doesn't seem to be a reason to hide the actual binary data behind an asynchronous interface. I'd also love to hear from Mike Shaver and others from the original thread what they think of this API proposal. Regars, Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100520/a2de1f77/attachment.htm>
Received on Thursday, 20 May 2010 17:50:03 UTC