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

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
>
>