W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

From: Chang Shu <cshu01@gmail.com>
Date: Wed, 7 Aug 2013 17:21:28 -0400
Message-ID: <CAMtH1gCRy-Ct25H6hmdMKgiarvQPDE6BEy6u97LMO16eDaMueQ@mail.gmail.com>
To: kg@luminance.org
Cc: WHATWG <whatwg@lists.whatwg.org>
I agree there are many cases this feature can be used for performance
improvement, especially when we handle large data buffers. If we plan
to enhance the Encoding spec, I personally prefer a new pair of
BinaryDecoder/BinaryEncoder, which will be less confusing than reusing
TextDecoder/TextEncoder.

Chang

On Wed, Aug 7, 2013 at 3:52 PM, K. Gadd <kg@luminance.org> wrote:
> JSIL currently ships a hand-rolled typed array to/from base64 implementation
> due not being able to use btoa/atob; if they were improved to support typed
> arrays as described that would be an improvement for some of my use cases.
> It'd need to be necessary to detect the presence of the feature at runtime,
> though.
>
> I should also point out that in general string decoding/encoding targetting
> typed arrays is a really important use case for JSIL (and as I understand
> things, it is also important for emscripten/embind). Right now moving
> between JS strings and a fake heap in a typed array is really expensive, and
> you need to do it any time you leave the domain of your application and talk
> to HTML5 APIs like canvas, XHR, etc. Base64 isn't the only kind of
> encode/decode that matters; I'd argue that UTF8 and UTF16 are equally
> deserving of similar functionality being exposed - if not more deserving.
>
>
> On Wed, Aug 7, 2013 at 3:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>
>> On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu <cshu01@gmail.com> wrote:
>> > But it appears to me we have to introduce
>> > another pair of coders, say BinaryDecoder/BinaryEncoder, in addition
>> > to TextDecoder/TextEncode since the signatures of the decode/encode
>> > functions are different.
>>
>> So TextDecoder is bytes to string and TextEncoder is string to bytes.
>> If we always represent the base64-variant as a sequence of bytes the
>> signature seems fine. If you want to get a string out of those bytes
>> again you could utf-8 decode it for instance.
>>
>> I'd be interested in knowing what the level of interest is outside of
>> Google for this feature.
>>
>>
>> --
>> http://annevankesteren.nl/
>
>
Received on Wednesday, 7 August 2013 21:22:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC