Re: comments on Matrix

On Wed, Mar 20, 2013 at 12:19 PM, Dean Jackson <dino@apple.com> wrote:

> On 21/03/2013, at 1:29 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
>
> 2013/3/20 Dirk Schulze <dschulze@adobe.com>
>
>> It is easier to answer to the answers entirely, even if we can discuss
>> details in separate threats later.
>>
>> The specification describes a unified way to exchange matrices across
>> other specifications. This is a very reasonable approach for me.
>
>
> It's reasonable to exchange matrices across APIs but we don't need a
> Matrix class for that, we can exchange raw arrays (say Typed Arrays) as is
> done in WebGL. We'd just need to agree once and for all on a storage order
> (say column-major as in WebGL).
>
>
> The proposal exposes the raw TypedArray so that you can use whatever
> matrix library you want. If you want speed and accuracy, do that (and load
> the external JS). If you want convenience, use the methods this API exposes
> (it's not meant to solve every problem).
>
> Dirk mentioned some of the motivations behind this proposal. A lot of
> people use CSS transforms. At the moment the only real API to that is via
> string manipulation. We're seeing a huge amount of time being chewed up in
> real-world applications when building and parsing the strings. We need
> something better than that.
>

Can you be more specific as to the issues that need to be solved?

If CSS transforms could take a Float32Array(16) in and you could get a
Float32Array(16) out and given a simple JS math library performed fast
enough (possibly faster than this proposal) then why not go that direction?




> I think it is ok for a specification to address it's concerns, and in this
> case it is addressing most of the needs of the community who build Web
> content using SVG and CSS. Sure, it still won't be as fast or as accurate
> as a "real" library, but I don't think that's enough reason to not do it.
>

> Meanwhile, I think your points about avoiding temporary objects and copies
> is very important. We should definitely try to avoid this in the API.
>
> Dean
>
>
> If we do add a Matrix interface for the purpose of exchanging data, then
> at least it does not need to offer any computational features.
>
>
>> We already have matrix definitions in SVG (SVGMatrix). And even if
>> SVGMatrix is less specified than with this specifications, we have a huge
>> amount of compatible implementations, including all major browsers and even
>> more SVG viewers. I am much less concerned about the specification than you
>> are. In fact, there is a need for an exchange format of transformation
>> descriptions. Currently, HTML Canvas relies on SVGMatrix to describe a CTM.
>>
>
>> The primary goal of the specification is interoperability and backwards
>> compatibility. As mentioned before, SVG described SVGMatrix. This
>> specification replaces SVGMatrix with the requirement to be as much
>> backwards compatible as possible. This requires to follow the naming schema
>> chosen in the specification.
>
>
> That SVG has a SVGMatrix doesn't imply that other Web APIs should have a
> matrix class. Maybe SVG had a good reason to have a matrix interface, which
> I don't know, but I don't understand how that would generalize enough to
> have a Web-wide matrix interface, when, as I said above, arrays are enough
> to exchange matrices, and even if we really wanted a matrix interface for
> data exchange, that still wouldn't justify putting computational features
> in it.
>
>
>
> To point 6. This is not a matrix library. The spec provides a simple set
>> of functions to do basic operations. It does not aim to allow full linear
>> algebra.
>
>
> As we just discussed, this offers a QR decomposition method (part of
> decompose()) even if it's hidden under misleading geometric names. This
> also offers matrix products, and various geometric transformation helpers.
> In my book, this _is_ a matrix library; regardless of naming, this is
> plenty complex enough to be very hard to optimize fully.
>
> Even an API offering only, say, translate() and scale() and skew() and
> transpose() would already have hard problems to solve. First, as these are
> cheap operations, the overhead of a DOM API call would be dominant, so
> browser developers would be scratching their heads about whether to add
> special JS-engine-level shortcuts to avoid the overhead of DOM calls there.
> That may sound overengineering until you realize that if a benchmark
> stresses these operations, having such shortcuts will allow to get faster
> by easily TWO orders of magnitude there. Now suppose that a browser engine
> has such shortcuts. The next problem as I mentioned in my first email is
> temporaries removal. Indeed if a benchmark (or a real application, for
> that's a real use case) does .translate().scale().skew()... then avoiding
> copying the intermediate results to/from temporary matrices will allow > 2x
> speedups. In short, as soon as you have_any_ computational feature in a
> matrix library, it's a tough job to optimize and maintain.
>
>
>
>> It just specifies what is necessary to fulfill the goal as an common
>> exchange format for transformation matrices. You are mentioning benchmarks
>> for browsers. I actually hope that browsers will optimize for performance
>> as well. This brings the question of precision over performance. Either you
>> make a compromise or decide for one or the other. Again, for me this is not
>> the priority. I can live with one or the other direction.
>>
>> I hope this answers some of your questions.
>>
>
> Unfortunately, it doesn't.
>
> Benoit
>
>
>>
>> Greetings,
>> Dirk
>>
>> >
>> > Benoit
>>
>>
>
>