W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: Matrix4x4 proposal

From: Chris Marrin <cmarrin@apple.com>
Date: Tue, 24 Jan 2012 10:32:32 -0800
Cc: dino@apple.com, igor.oliveira@openbossa.org, public-fx@w3.org, 'public-d3d mlist' <public-declarative3d@w3.org>
Message-id: <C3755D86-D742-4C9B-B31D-03931729CF85@apple.com>
To: Timm Drevensek <timm.drevensek@igd.fraunhofer.de>

On Jan 24, 2012, at 6:58 AM, Timm Drevensek wrote:

> Hallo
> 
> We were discussing about your implementation proposal and there came up some question about the constructors and the underlying data type of a matrix class:
> Related to the Khronos TypedArray specifications: http://www.khronos.org/registry/typedarray/specs/latest/
> 
> 
> Would it be an idea to design the Matrix class in a way that:
> - It works internally on ArrayBuffer as the underlying data container.
> - The Matrix class itself derives from an ArrayBufferView like TypedArrays does.
> 
> 
> Pros:
> - Extendable by any existing libraries that are acting on TypedArrays (glMatrix) without any copy of data from and to the Matrix class (just provide a pointer to the underlying TypedArray container)
> - Possibility for a performing way for creating arrays of matrices: By multiple views into a single container (see subarray() & constructor(buffer, byteOffset, length) @ TypedArray spec)
> - Same interfaces for 32 and 64 bit Matrices
> - No overhead for copy to the GL context
> 
> 
> Cons:
> - If you act on a ArrayBufferView you cannot create a 3x3 matrix "view" into a container, holding a 4x4 matrix (like subarray() of TypedArrays) due the offset after each row break.
> For work around this issue, the Matrix could act on an extended 2 dimensional ArrayBufferView...with holds information on size and offset for the 2. dimension...or a construct like the step_iterator, available in the boost gil library: (see http://stlab.adobe.com/gil/html/gildesignguide.html#StepIteratorDG) 

I don't think the overhead of copying a matrix into a Float32Array is significant, compared with the rest of the overhead involved. So I think it would be better to avoid the internal dependency on Typed Arrays and stick with the current functions to create and copy into them.

-----
~Chris
cmarrin@apple.com
Received on Tuesday, 24 January 2012 18:33:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 24 January 2012 18:33:10 GMT