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

Re: Image.toBlob()

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 2 Feb 2012 23:03:36 -0600
Message-ID: <CABirCh8uppxvhfK5=+Q0eujUACD6_C_UnMoHkMQ7iMQA483VeA@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Anne van Kesteren <annevk@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, Feb 2, 2012 at 10:26 PM, Charles Pritchard <chuck@jumis.com> wrote:

> **
> There's nothing like it in current implementations. I'd think it rare to
> come across an instance where an author has only made a clone image, and
> done nothing else. They'd just use the <img> element in such a case.
>

It's not at all rare, since it's how you convert images to blobs.  (Or, if
it's rare, then that's an argument against adding a special method for it.)

We're talking about jpeg, as well as PNG, and items like WebM. Canvas is
> specified as RGBA. What happens when an indexed or an RGB PNG file is put
> in? You're taking some real liberties with the scheme I mentioned above,
> and there seems to be very few use cases for it.
>

If there aren't use cases, then there's no need for
HTMLImageElement.toBlob, either.  The use cases are identical.

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.

-- 
Glenn Maynard
Received on Friday, 3 February 2012 05:04:03 GMT

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