[whatwg] Offscreen canvas (or canvas for web workers).

David Levin levin at google.com
Fri Mar 12 12:41:36 PST 2010


On Fri, Mar 12, 2010 at 12:16 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Fri, Mar 12, 2010 at 11:57 AM, David Levin <levin at google.com> wrote:
> > On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> What is the use case for this? It seems like in most cases you'll want
> >> to display something on screen to the user, and so the difference
> >> comes down to shipping drawing commands across the pipe, vs. shipping
> >> the pixel data.
> >
> > Apologies for not including this at the start. As now mentioned in
> several
> > places in the thread, the simplest use case is resize/rotate of images.
>
> As Hixie pointed out, resize/rotate images do not seem solved by this
> API. In order to resize an image with this API you need to:
>
> 1. Load the image into an <img>
> 2. Copy the image into a <canvas>
> 3. Extract an ImageData from the <canvas>
> 4. Send the ImageData to the worker thread
> 5. Import the ImageData into the worker thread canvas
> 6. Resize/rotate the image using the worker thread canvas
> 7. Extract an ImageData from the worker thread canvas
> 8. Send the ImageData to the main thread
> 9. Import the ImageData into a main thread <canvas>
>
> And if you want to send the resized image to the server:
>
> 10. Extract the data in a serialized format from the <canvas>
> 11. Send using XHR.
>
> Just looking at just the work happening on the main thread it sounds
> like just resizing/rotating on the main thread is faster. Not to
> mention much less complex.
>
> I'm not saying that the proposed API is bad. It just doesn't seem to
> solve the (seemingly most commonly requested) use case of
> rotating/scaling images. So if we want to solve those use cases we
> need to either come up with a separate API for that, or extend this
> proposal to solve that use case somehow.
>

If fromBlob and toBlob were on canvas, it gets rid of steps 1-3 and changes
step 4 to be send file to worker thread. I simply didn't include
fromBlob/toBlob because toBlob was already being discussed in another
thread. I thought it best to let that topic get discussed in parallel, but
it is part of this whole thing, so I am interested in that happening (and
discussing those apis further).

So it looks like this:

1. Send the File to the worker thread
2. Import the File/blob into the worker thread canvas
3. Resize/rotate the image using the worker thread canvas (to thumbnail for
instance)
4. Extract a blob from the worker thread canvas

Either

5. Send the blob using XHR in the worker.

or

5. Send the Blob to the main thread
6. Import the Blob into a main thread <canvas>
(or both).

Given the blob support this would be overall a better user experience
because the loading of the image is done in the worker as well as the resize
to a much smaller size, so the i/o happening on the main thread is much
lower overall.

dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100312/c0241afe/attachment.htm>


More information about the whatwg mailing list