[whatwg] Offscreen canvas (or canvas for web workers).
jonas at sicking.cc
Fri Mar 12 12:16:55 PST 2010
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.
More information about the whatwg