[whatwg] Image resize API proposal

[David Levin]

On Thu, May 20, 2010 at 7:55 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 20, 2010, at 6:24 PM, Robert O'Callahan wrote:
>
> On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>> I'd also love to hear from Mike Shaver and others from the original thread
>> what they think of this API proposal.
>>
>
> 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.
>
> 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 :-).
>
>
> 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.
>
>
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.)

Sample code from the proposal:

var successEvt = function (newBlob) { myDiv.innerHTML += "<img src='" +
newBlob.url + "' />"; };

i.getBlob("image/jpeg", 300, 350, successEvt);


dave



> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100520/c2688d2e/attachment-0002.htm>