Re: [css2-transforms] Re: comments on Matrix

On Wed, Mar 20, 2013 at 3:23 PM, James Robinson <jamesr@google.com> wrote:

>
>
>
> On Wed, Mar 20, 2013 at 2:52 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>> On Wed, Mar 20, 2013 at 12:10 PM, Benoit Jacob <jacob.benoit.1@gmail.com>wrote:
>>
>>>
>>>
>>> 2013/3/20 Rik Cabanier <cabanier@gmail.com>
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2013 at 7: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).
>>>>>
>>>>> 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,
>>>>>
>>>>
>>>> No, CSS, Canvas and SVG currently all have different matrices. People
>>>> shouldn't have to learn 3 different ways to do the same thing.
>>>> A matrix class is needed to bridge the gaps.
>>>>
>>>
>>> In my ideal world these Web APIs wouldn't impose their own matrices,
>>> they would just take raw arrays. The user would be free to use whatever JS
>>> matrix library he wants. The user would get more flexibility, no mismatched
>>> matrix APIs, and better performance too going forward.
>>>
>>> In the non-ideal world where matrix APIs have already been allowed to
>>> sneak into Web APIs, first of all I don't really see how adding yet another
>>> matrix API fixes anything, since we can't really take anything out from
>>> existing Web APIs (we don't break Web compatibility) so we're stuck with
>>> any matrix API we have for a long time anyway. If really we agree to try to
>>> at least standardize on one matrix interface going forward then I'm at
>>> least arguing that it should focus solely on data exchange and NOT on
>>> anything computational.
>>>
>>
>> I agree that data exchange is the most important aspect.
>> However, since this API needs to match SVG's matrix, it HAS to have
>> computational functions since they're in SVGMatrix too.
>>
>
> Why not put the extended APIs on the SVGMatrix interface but leave that as
> a subclass that's not used in the general purpose Matrix APIs?  I don't
> think the use of SVGMatrix should require us to add a bunch of API to
> everything in the web platform that needs to pass a set of floats around.
>

As Dean's example shows, those functions are useful for CSS as well. It
doesn't make sense to have to allocate an SVG matrix to do CSS
manipulations.
Canvas will also improve since it won't have to reference a SVG matrix
anymore.


>
>
> then interpolate the rotation1's, the diagonal coefficients, and the
>>> rotation2's separately. Note that these two decompositions can be achieved
>>> with a single SVD, but that viewpoint is probably better because if you
>>> matrices are already rotations you definitely don't want to replace them by
>>> a product of two rotations, as a direct SVD would do. That interpolation
>>> will look very natural geometrically because you'll really be interpolating
>>> singular values and left/right singular vectors i.e. things that have a
>>> coordinate-free geometric significance. Using a different coordinate system
>>> wouldn't make any difference.
>>>
>>> If you're not convinced yet I'm OK to work out an example where QR-based
>>> interpolation would give weird results for reasonable endpoints.
>>>
>>
>> It's not about 'convincing' me (you already have), it's about what is
>> already implemented TODAY and shipping in your browser.
>> We can fix bugs in the pseudo code, but we can't switch to something
>> better but that will give different results.
>>
>
> CSS transitions use a specific matrix decomposition, but that doesn't
> imply that everything else in the web platform will want to use the same
> set of primitives.
>

I agree. That's why we should move it to an interpolation function.
That specific matrix decomposition is only useful for that use-case so it
shouldn't be used to generate decomposed values.


>
> "SVG does it this way" is a terrible argument for cluttering up other web
> platform APIs.  If SVG made mistakes, let's make sure those mistakes stay
> limited to SVG.
>

I'm unsure what SVG mistakes you are referring to.