[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] DataView suggestions
- To: Christopher Chedeau - Vjeux <[email protected]>
- Subject: Re: [Public WebGL] DataView suggestions
- From: Kenneth Russell <[email protected]>
- Date: Mon, 11 Apr 2011 19:18:35 -0700
- Cc: [email protected]
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302574719; bh=v85NYHXaleRx+aB9HTP4Tx8+hmI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ER9Fl97TlWK4O5io4D6daA99R+/7Xl9T+0wnQJgbNyhf+4pSEWQNz6p9AU+iJAAZX 7Jf6ofOXcSTzfgp18OgrA==
- 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 :content-transfer-encoding; bh=6ThvU672G2Q6W8CXV8BjS80GA639G9w3hhist7GndAA=; b=SQ5XVEC8Frrkt+7PhZaHn037V0MboS4Y+o2+z8IC8EjOwYKQfbw8oiTxtVXrJrijN1 hc2w7Li516MIfQ9qJvDg==
- 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:content-transfer-encoding; b=ZamiXl0ZbTWyGZaTStE5VxK1YkI5OIjyXqaPxz9WYUKZQCiHMjx1ise1DyVMFU7hJ2 168g8CUxVQ/J0fI6GtQQ==
- In-reply-to: <[email protected]>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <[email protected]>
- Sender: [email protected]
Thanks for your feedback.
Earlier versions of the DataView class were stateful, and contained a
cursor for stream-like input. Discussion on the WebGL mailing list
informed the current design. The basic idea is that a cursor can be
necessary for the DataView class to contain all of the functionality.
The simpler the DataView class, the more likely it is that the entry
which is important to get good file reading and writing performance.
More responses inline.
On Fri, Apr 8, 2011 at 3:52 AM, Christopher Chedeau - Vjeux
<[email protected]> wrote:
> I have been working on a lib that provides DataView API for all the browsers
> (it uses the best feature available from String, Typed Array or DataView)
> called jDataView: https://github.com/vjeux/jsDataView/
> While working on this library, I found that the current API was not really
> practical to use. Adding those few points would make the handling of binary
> data more enjoyable.
> 1) Addition of littleEndian to the constructor
> A binary file is either in littleEndian or bigEndian form. It is therefore
> really annoying to have to define the endianness everytime you read a value.
> This is even more annoying since the default value is bigEndian whereas most
> files nowadays are in littleEndian.
> To solve this, we can add a parameter littleEndian to the DataView
> constructor. When you read/write and the littleEndian value is undefined,
> this is the value from the constructor that is being used. I would also set
> bigEndian by default.
I think that this sort of functionality belongs in a wrapper library.
There's no reason to artificially limit a particular DataView instance
to reading only big- or little-endian data. One could imagine a file
format that contained both big- and little-endian values, though it
would be convoluted.
> 2) File cursor
> Most of the time you read a file sequentially. With the current API, you
> have to keep a cursor of where you are at and this is extremely annoying.
> You would like to write
> var a = view.getInt8();
> var b = view.getFloat32();
> Instead you have to write
> var cursor = 0;
> var a = view.getInt8(cursor); cursor += 1;
> var b = view.getFloat32(cursor); cursor += 4;
> DataView could have an internal cursor initialized to 0 at creation. Every
> time you make a read/write, it would be set to the end of what has been
> read/written. byteOffset will be set to the cursor position. if undefined.
> In order to manipulate the cursor, we would have two functions:
> seek(byteOffset) and tell()
Per above, this was already considered and rejected. It can easily be
implemented in a wrapper library.
> 3) getChar and getString
> Often, binary files also contain characters and strings. With the current
> API, this is extremely annoying to read those types of values.
> I suggest to add 4 new functions:
> getString(length, byteOffset)
> setChar(byteOffset, char)
> setString(byteOffset, string, optional length)
> One issue I see is encoding. I believe that strings in binary files are
strings is definitely needed, and there have been discussions on this
mailing list about how to achieve it. Unfortunately, so far there
hasn't been a champion of this functionality to specify it.
I am no expert in this area, but I have a feeling that the API needed
for this functionality will be moderately sized. It seems clear that
it will be necessary to support multiple character encodings. For
these reasons, I think the best path forward would be to add a
decoding into typed arrays and/or the DataView class. If you'd be
willing to contribute to this effort that would be great.
> I hope that these suggestions will help to make the DataView API more user
> friendly. It is important to have a good support for binary files if we want
> Christopher CHEDEAU - Vjeux
> EPITA - LRDE - Ing2 2012
> Curse.com Web Developer
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email: