[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] [Typed arrays] String to Buffer to String
- To: Dannii <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] [Typed arrays] String to Buffer to String
- From: Kenneth Russell <email@example.com>
- Date: Mon, 7 Feb 2011 13:39:50 -0800
- Cc: public_webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297114792; bh=TL/LCaMNLt4LBcfiZQHDi8F23y8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Z8Ixf8gVcZ4sVKbKnU4Iyi9FtKkrHtun/4RpLm62n/Pn1H/Cb+f527GLfpV+WBNuS /R6QyjN6dJ9/fJbnvcITg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+56ZVPpKDIQK+Yw8AInj/hOR+L+oF+80TkKc5jmkd4c=; b=iUNo+hT+Sy7aIZTlfHpY4q5H4VFyaHeSdaCjMss//bWp1jGkA5fo7YfE3rktRo6HcG fXxZdvTfyqm4HdwKAsFw==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZhK1NjJhFBWKdsPpCwastYjVUACO1Fd7F5nzIJvLPiEvfLJlqQv6F+IrIdwCU6YPEW VDM2Q1cubHcLVcOppOlg==
- In-reply-to: <AANLkTim_1iOwVr4wyyMdmKWhNZmV1fkfxZJgey=7vkvT@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTim_1iOwVr4wyyMdmKWhNZmV1fkfxZJgey=7vkvT@mail.gmail.com>
- Sender: email@example.com
On Sat, Feb 5, 2011 at 6:01 AM, Dannii <firstname.lastname@example.org> wrote:
> I've read the archives which mention the need for a string to Buffer API,
> but I don't think my particular use case was represented, so I thought I'd
> share it in the hope that it might still be possible to include it in the
> spec, or to encourage a separate spec to be drafter.
> I work on VMs written in JS, which can run bytecode files of up to several
> MB. We currently use regular arrays but I'd like to shift to typed arrays
> soon. When the data is first downloaded we can get the buffer directly from
> the XHR, which is great. But because I'd like to be able to set it up to
> work offline as well, I want to store the files in localStorage, and read
> from it in the next session. As I understand it there's no way to do this
> other than just go through byte by byte. Which may be fine for desktop
> browsers, but will be quite slow for mobile browsers.
> Sure there might be endianess issues, but they can be dealt with just as
> they have been for DataViews. The conversion function could include an
> endian argument if needed.
> I was also wondering, what is the justification for requiring that a
> TypedArray's offset be a multiple of its element size? That makes it hard to
> emulate DataView (which won't be implemented in Firefox 4).
This constraint was enforced in order to allow the highest performance
code paths for loads and stores into typed arrays. If they needed to
support unaligned loads and stores, there would be a significant
performance impact, at least in some situations.
typed array view types are present. You just need a temporary
ArrayBuffer 8 elements long. For each get operation on the DataView,
use a Uint8Array against the source ArrayBuffer to copy out the right
number of bytes into a Uint8Array against your temporary ArrayBuffer,
storing them with the right endianness. Then use the appropriate typed
array against your temporary ArrayBuffer to fetch element 0. Setting
an element works similarly. (If Float64Array isn't present, then I
agree it will be very difficult to implement the getFloat64 /
setFloat64 entry points.)
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: