Re: comments on Matrix

On 21/03/2013, at 6:25 AM, Gregg Tavares <gman@google.com> wrote:

> 
> 
> 
> 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?

Mostly because we think this is a common enough use case that it shouldn't need external libraries.

Also, the other requirement is that we need a class that can be produced and accepted by both the existing SVG and CSS APIs, for backwards compatibility. It can't simply be a Float32Array, although it could certainly be something that exposes one.

Dean


> 
> 
>  
> 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
>> 
>> 
> 
>