W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2010

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

From: Oliver Hunt <oliver@apple.com>
Date: Sat, 13 Mar 2010 12:09:33 -0800
Message-ID: <583B6543-04F1-48BB-AEE4-4DB6F12F09B3@apple.com>

On Mar 13, 2010, at 9:10 AM, Jonas Sicking wrote:
> There is a use case, which I suspect is quite common, for using
> <canvas> to manipulate files on the users file system. For example
> when creating a photo uploader which does client side scaling before
> uploading the images, or for creating a web based GIMP like
> application.
> 
> In this case we'll start out with a File object that needs to be read
> in to a <canvas>. One solution could be to read the File into memory
> in a ByteArray (or similar) and add a synchronous
> canvas2dcontext.fromByteArray function. This has the advantage of
> being more generic, but the downside of forcing both the encoded and
> decoded image to be read into memory.

Honestly i think  nice and consistent way for this work work would simply be to support
someImage.src = someFileObject

Which would be asynchronous, and support all the image formats the browser already supports.

> 
> This is why I suggested adding a asynchronous fromBlob function.
> 
> For extracting image data from a <canvas> I agree that a toBlob
> function has little advantage over a toByteArray function (with the
> possible exception that ByteArray so far is still vapor ware).
CanvasPixelArray is a ByteArray to all intents and purposes, and webkit and i _think_ opera implement it as such.  It would of course be good just to get all the native array types into ES, and then make WebLG + Canvas make use of those directly, and i doubt that is something we'll need to wait too long for.

--Oliver
Received on Saturday, 13 March 2010 12:09:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC