W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Proposal for a new Matrix API

From: Rick Waldron <waldron.rick@gmail.com>
Date: Fri, 21 Oct 2011 11:47:52 -0400
Message-ID: <CAHfnhfpkRk+xWNoewGADxsf31-Hf4t=i7YX8+_Y7bM-KYPWWsw@mail.gmail.com>
To: Joćo Eiras <joaoe@opera.com>
Cc: public-webapps@w3.org
On Fri, Oct 21, 2011 at 11:28 AM, Joćo Eiras <joaoe@opera.com> wrote:

> On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira <
> igor.oliveira@openbossa.org> wrote:
>
>  Hello,
>>
>> Currently CSSMatrix and SVGMatrix has an immutable API. None of the
>> method calls change the Matrix, instead, it creates a new Matrix with
>> the changed value. It can be a problem specially when CSSMatrix is
>> used together with WebGL. [1]
>>
>>
> I would suggest that the matrix should not be a host object. Instead is
> should be a pure ecmascript object so it can run closer to the metal (be
> jitted easily).
>

Assuming you mean "native object" when you refer to "pure ecmascript
object", there is no performance benefit, JIT or otherwise. In fact, it's
possible to implement ES functionality with better performance then the
native implementations.



>
> I did suggest previously extending array a bit, like
>
> {length: 6, height: 2, width:3, 0. ..., 1: ..., 2: ..., 3: ..., 4: ..., 5:
> ...,  }
>
> which represents a 2x3 matrix. The matrix would not have any kind of side
> effects or limitations, possibly being of any arbitrary size, hence usable
> not only by graphical APIs, but by any algebra you throw at it.
>
> The methods you suggest, would then be on the prototype, or in the Math
> object.
>
>
Received on Friday, 21 October 2011 15:54:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT