On Thu, Feb 2, 2012 at 10:26 PM, Charles Pritchard <[email protected]> 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
