- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 12 Mar 2010 12:16:55 -0800
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. / Jonas
Received on Friday, 12 March 2010 12:16:55 UTC