On May 20, 2010, at 8:13 PM, David Levin wrote: > > > On Thu, May 20, 2010 at 7:55 PM, Maciej Stachowiak <[email protected]> wrote: > > On May 20, 2010, at 6:24 PM, Robert O'Callahan wrote: > >> On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak <[email protected]> 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); > >
Ah, I misread the proposal. Didn't realize it had call backs. 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. Regards, Maciej
