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.

Received on Tuesday, 24 January 2012 18:33:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC