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

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.


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.

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

- James