W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] Image resize API proposal

From: David Levin <levin@google.com>
Date: Thu, 13 May 2010 15:53:25 -0700
Message-ID: <AANLkTilVdoySWvGmHQ114WHcNACm34UIOW3z_7n13EEd@mail.gmail.com>
Thanks for your feedback Gregg.

On Thu, May 13, 2010 at 3:32 PM, Gregg Tavares <gman at google.com> wrote:

> This really seems like the wrong solution. Taken to an extreme next you'll
> need to add VideoRisizer, AudioRecompresser, and any thing else JavaScript
> can't do without freezing the browser.
> It seems like it would be better to figure out a way to get Web Workers to
> be able to do this.

This has been explored. See "Alternatives considered" in the original

> Even if they have to XHR the binary down, decompress into a TypeArray (see
> WebGL) and read the data themsevles so they can keep the EXIF stuff,
> bloating the browser for one small use doesn't seem like the right solution.

"Small use" is a relative term. In that there are a lot of web properties
that either do this or want to do this right now.

> You can post an open source library and the usage can be as simple as this
> proposal.

Then you would have to include the open source library as part of your web
application which is suboptimal.

> On Tue, May 11, 2010 at 11:58 AM, Sterling Swigart <sswigart at google.com>wrote:
>> 2. Or, limit the size of an image file before uploading it to a web
>> server.
> This use case is already handled (minus the EXIF).

How? (Note "limit the size". If you mean using canvas, it may hang the UI
for the user which is a really bad experience.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100513/0f188e67/attachment.htm>
Received on Thursday, 13 May 2010 15:53:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC