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

Re: Reading image bytes to a PNG in a typed array

From: Florian Bösch <pyalot@gmail.com>
Date: Wed, 16 Jan 2013 16:40:32 +0100
Message-ID: <CAOK8ODha-3hqqAQhfGUVg=egffaigUgQD3YO_zrX+kqnd-w+5g@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Kyle Huey <me@kylehuey.com>, Webapps WG <public-webapps@w3.org>
Perhaps we should think of a better scheme to export data than toFoo().
Maybe toData('url'), toData('arraybuffer') toData('blob') or perhaps
toData(URL), toData(ArrayBuffer) or toData(Blob). I tend to think that if
you're starting to write toA, toB, toC, toX methods on an object, you've
not thought this really trough what's a parameter, and what's a method.

On Wed, Jan 16, 2013 at 4:26 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Jan 16, 2013 at 6:29 AM, Kyle Huey <me@kylehuey.com> wrote:
>> I don't think there's any reason we can't have toArrayBuffer as well.
>> The hard part from an implementation perspective is asynchronously encoding
>> the image, not what we stick it in.
> No technical reason, but I'd avoid adding yet more paths to do the same
> thing unless there's a real gain.  It'd be bad to head down the path of
> every single Blob-returning operation having an ArrayBuffer duplicate.
> In this particular case, he wants ArrayBuffers to put the data in a ZIP,
> which probably means he should be doing this from a worker anyway, to avoid
> doing a bunch of CRC calculations on the UI thread.  In that case, the
> current API isn't even inconvenient, since once you post the Blob to the
> worker you can use FileReaderSync and not have an extra async operation to
> do.
> ("Pass an array of Blobs to a worker and get back a Blob of a ZIP" is a
> generally useful operation, so maybe he wouldn't even have to write this
> himself.)
> --
> Glenn Maynard
Received on Wednesday, 16 January 2013 15:41:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC