Re: Matrix4x4 proposal

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 UTC