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 22:14:00 -0600
Message-ID: <CABirCh-SptLWEdHHLAEbTZ2uXd89tch6936gJP-iWTX=gDjwNg@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Anne van Kesteren <annevk@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
(You're blue today.)

On Thu, Feb 2, 2012 at 4:34 PM, Charles Pritchard <chuck@jumis.com> wrote:

> They are a pain, and lossy.
>
> You don't want to do drawImage then a toBlob png on an image that's a
> jpeg. We've had to use followup XHR calls which may or may not do another
> http fetch. We went the route of doing an XHR call first, but then we
> couldn't display nice progressive loading. Canvas also inflates the size of
> PNG files, typically.
>

Not if the browser optimizes for this and avoids the copy entirely (eg. as
long as you do a 1:1 copy, don't draw anything else on top of it, etc).
 That seems like a useful optimization anyway.

I'm not sure if alpha complicates this.  If you save a transparent PNG back
to a PNG, you want the original RGBA, not premultiplied and
un-premultiplied results.  I don't know if the spec allows bypassing those
lossy steps in this case.  I don't think 2d canvas specifies the color
depth of the backbuffer.  If you think of the backbuffer as having a high
color depth, you'd get the same result.  That doesn't work for alpha values
of zero, though, where the result would be undefined (and is defined as
black) rather than the original color.

It's worth trying to make this work before adding new API.

-- 
Glenn Maynard
Received on Friday, 3 February 2012 04:14:27 GMT

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