W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: Image.toBlob()

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 02 Feb 2012 21:07:50 -0800
Message-ID: <4F2B6BA6.508@jumis.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Anne van Kesteren <annevk@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On 2/2/12 9:03 PM, Glenn Maynard wrote:
>
>     With that scheme, though, if you were really referencing an image,
>     then your toDataURL and toBlob output, given no optional
>     parameters were specified, and the file format were the same, well
>     it could be a copy of the binary data.
>
>
> That's the whole idea.  You can transparently bypass the process of 
> blitting to a backbuffer for this case (modulo the zero alpha issue). 
>  It's just an optimization.

Oh, that's not a use case I need. There's no real overhead.

I need the use case of  Image.toBlob() returning a binary copy of the 
resource, metadata and all, in its original and pure form. That way I 
don't have to XHR after or before hand, and I can still get progressive 
rendering and whatever else comes along with the browser implementation 
of the Image object.

It ought to spout off a state error if image has not loaded yet, a 
security error if cors isn't met, I'm going to be using <img 
crossorigin>, cause that's what I do.

I actually don't need Image.toBlob() to be used for image format 
conversion, though that'd be up to the implementer.
Canvas.toBlob() is a PNG by default.
Image.toBlob() is format agnostic by default.


-Charles
Received on Friday, 3 February 2012 05:08:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT