From Péter Szilágyi to ~eliasnaur/gio-patches

```
``````
Hey Elias,
Thanks for the review comments. I kind of knew they are coming, just
didn't have a good place to rationalize/discuss them (would be nice if
sourcehut provided a means to add comment / questions outside of the
patch commit description). I replied below, but the crux of my
question revolves around making all the helper methods internal. I do
understand the desire, but that entails the internal fields being
converted to public. I can do that id that's what you want, but I'm
not sure. Please advise.
> "works"? Did you mean "rows"?
Yup, sorry, will fix.
```

From Péter Szilágyi to ~eliasnaur/gio-patches

```
``````
Currently Gio has a simplistic transformation operation implemented
that's essentially an offset vector. This is enough for many layout
tasks, but falls short when animations come into the picture (e.g.
spinner).
This CL replaces the current transform op with one base on affine
transformation matrices, thus enabling advanced operations such as
scaling, rotation and shearing.
Since it's expected that most UIs will not use (or use in very limited
portions) the advanced transforms, the CL also special cases the offset
use case, so both calculations and serializations using only translation
will take optimized coda paths. This is handled under the hood.
[message trimmed]
```

From Péter Szilágyi to ~eliasnaur/gio

> Ah, that's a good idea. I can compute the inverse on the fly just by > inverting the ops individually and doing a reverse order > multiplication. Cool, will update the PR with that :) Updated the PR so that the inverse matrices are maintained too https://lists.sr.ht/~eliasnaur/gio-patches/patches/9128. PTAL

From Péter Szilágyi to ~eliasnaur/gio-patches

```
``````
Currently Gio has a simplistic transformation operation implemented
that's essentially an offset vector. This is enough for many layout
tasks, but falls short when animations come into the picture (e.g.
spinner).
This CL replaces the current transform op with one base on affine
transformation matrices, thus enabling advanced operations such as
scaling, rotation and shearing.
Since it's expected that most UIs will not use (or use in very limited
portions) the advanced transforms, the CL also special cases the offset
use case, so both calculations and serializations using only translation
will take optimized coda paths. This is handled under the hood.
[message trimmed]
```

From Péter Szilágyi to ~eliasnaur/gio

> You don't necessarily have to compute the inverse. You could always > keep an inverse matrix alongside each forward transform, and > reverse-append inverse transformations to it whenever you append > transformations to the main matrix. Ah, that's a good idea. I can compute the inverse on the fly just by inverting the ops individually and doing a reverse order multiplication. Cool, will update the PR with that :)

From Péter Szilágyi to ~eliasnaur/gio

Hey there, > Further, inverting a general matrix is expensive, but inverting an > affine transformation is not. See for example > > http://negativeprobability.blogspot.com/2011/11/affine-transformations-and-their.html I'm not sure that article is completely accurate. It only talks about inverting 1 rotation and 1 translation. Generally you can do multiple translation-rotation-translation rounds, and also scaling and (less likely) shearing come into play. I doubt that it would be so easy to invert a long chain of transforms. > A starting point is to change the representation of TransformOp to fit