[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] String constructors for arrays?
- To: Vladimir Vukicevic <email@example.com>
- Subject: Re: [Public WebGL] String constructors for arrays?
- From: Philip Taylor <firstname.lastname@example.org>
- Date: Tue, 22 Dec 2009 11:24:08 +0000
- Cc: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eK7wnpMILUJTIQsv+x0Nid9DCxTRyp1Aawy8BNMgtME=; b=uTg0dT+DxYZiCfyiXAdqq/uyBl220lAgJZY5E4OyrShTBZhZ9KS2vUjb8Q2rz3naVz bm8re1rKZM/RcBQ3p9LTiflCyy1ev5nZ372eAF8UYZ+f1C2iKGpHULv3g6VYQnX1No55 1kybZlN9RxmlbEA56c2/tSflwmHj/llv5PR4Q=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VUMGzjf2ig0fG80sb0SweZRy31rjzx8IddqSJLB8yIm4r0B6I9Fay+cBl8a086uA5n S7PWYdywUQBOQ2/LcuGpoujvOMlJDwrYlzZH8aDLX9mNOolRhQMOOfwVxaZ/Z22yzb5R rFuLgh/Q8aPfeIofy1cQrLTJ/w8J8QrdeVFps=
- In-reply-to: <4B307073.firstname.lastname@example.org>
- References: <4B307073.email@example.com>
- Sender: firstname.lastname@example.org
On Tue, Dec 22, 2009 at 7:08 AM, Vladimir Vukicevic
> I was reading Ilmari's post here --
> -- and thought that it might be interesting to supporting constructors on
> the WebGL array types that take a string as input data. The 8-bit types
> would take only the low 8 bits of each character value, and for completeness
> the 32-bit types could sign-extend to 32 bits. This would make it much
> easier to work with data read from the net until we have better native
> support for interacting with truly binary data, because dealing with it in
> string form is pretty common. Feature creep or useful?
What about big-endian vs little-endian? Signed vs unsigned? Floats,
half-floats, truncated 16-bit floats, fixed point numbers? It seems
like this API would be either very specific to a handful of data
representations (and therefore useless when people want their data to
be very slightly different), or it would be a large complex
general-purpose binary number parsing system (and therefore harder to
understand and use, and it shouldn't be defined as part of a canvas
context because it's out of scope).
With a very rough test like
(parsing and summing 4-byte ints), I see speeds of about 2 million
ints/sec in Firefox 3.5, and 14 million ints/sec in Opera 10.50 - so
it's possible for pure JS to be pretty fast, and the bottleneck is
likely to be network bandwidth.
So I'd be happier to keep binary parsing as plain JS code, and focus
any browser implementation effort on optimising JS engines for this
kind of use, since that minimises spec complexity and maximises
flexibility for authors.
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: