[whatwg] HTMLCanvasElement.toFile()

[Glenn Maynard]

Replying to an old message; sorry if this has been covered since then.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024691.html:
>> I suggest we add a function like:
>>
>> File toFile(in DOMString name, in optional DOMString type, in any...
>> args);
>>
>> This function takes the same arguments as toDataURL(), plus an
>> additional 'name' argument.
>
> The File should stick to representing files. After all, you would not make a File object to
> convert something to text for uploading. Nor would it make sense to do
> an asynchronous read from this. And under the covers, you would want
> to pass the actual binary data to the upload code, not a file with a
> file name.

It does make a lot of sense to do asynchronous reads from file data
generated from a canvas.

For a larger canvas, generating a PNG can take some time.  By making a
copy (or COW) of the canvas, reading PNG data from it can be done
asynchronously.  This would keep the whole page from halting for half
a second (or more; PNG can be expensive at higher compression levels)
while the data is generated.

For example, this would be very important if an image editor is
backing up the user's work in the background, as Gmail does with
message text.  If the user is drawing on the canvas, having the UI
hitch for 500ms (or even 100ms) would be disruptive.

The hard part is that you can't have a Blob whose size isn't known in
advance, so this would probably need a separate class, making it a
much larger undertaking.  (The same would be needed for things like
deflating/inflating data: can't slice it and don't know the final
size.)  But, the async reads and compression themselves do make a lot
of sense.

-- 
Glenn Maynard