Re: comments on Matrix

2013/3/20 Dean Jackson <dino@apple.com>

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

That's a good criterion for including stuff --- but not the only criterion,
not an absolutely sufficient condition.

It has to be balanced with other criteria:
 - is this something for which there exists a consensual choice of API? No,
matrix APIs are hard to get people to agree on.
 - is this something that has a well-defined wanted feature set? No, every
matrix library has a different feature set and I don't agree with the
feature set that this one currently has.
 - is this something that we can hope will perform significantly better if
implemented inside of the browser? No, as said above, quite the contrary.
 - is this something that we are confident won't incur a large maintenance
load? No, if this becomes popular we will have to make it run fast and that
will be a rathole as explained above.
 - is this something that people here on this mailing list / WG know better
than application developers do? No, being a browser developer doesn't make
one good at matrix libraries.

Benoit




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