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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:48 UTC