Re: Image transformations

[Alan Third]

On Fri, Jun 14, 2019 at 10:05:46AM +0300, Eli Zaretskii wrote:
> 
> The matrix is defined according to XRender, AFAIU.  NS and Cairo need
> to transpose/invert/etc. the matrix to use it, and so will the
> MS-Windows code, IIUC.  The matrix fuses the actual primitive
> transformations into a construct which we currently don't seem to
> understand well, whose only "documentation" is in a tutorial that is
> not part of XRender's official docs.

I was first taught affine transformation matrices in a Mathematics for
Engineers course at university. The lecturer used these exact same
matrices to perform rotations on diagrams drawn on a blackboard. This
was before XRender existed and I can find references to them in a
maths book originally published in 1963. I’m sure they’re even older
than that.

Here’s some more documentation lifted from a google search for ‘affine
transformation matrix’:

https://en.wikipedia.org/wiki/Affine_transformation#Image_transformation
https://www.mathworks.com/discovery/affine-transformation.html
http://mathworld.wolfram.com/AffineTransformation.html
https://eli.thegreenplace.net/2018/affine-transformations/

Transposition of a matrix is literally using m[b][a] instead of
m[a][b].

Inversion of a matrix is a bit more complex but still well within the
capabilities of a high school student:

https://www.mathsisfun.com/algebra/matrix-inverse.html

Besides, the NS API provides a one liner for that:

  [transform invert];
  
We need to do this whether we use the transformation matrix functions
in image.c or use the NS API, as they do the same thing.

FWIW, I wrote this code for NS first. The fact it appears to match the
XRender requirements so well is simply that XRender’s API has been
written to match the existing maths.

> From where I'm standing, this is a scary situation. I believe both
> Cairo and MS-Windows have a much clearer official documentation of
> the related functionality (didn't try looking for NS docs, but I'd
> expect to see good documentation there as well), so clean code could
> be relatively easily written for these platforms using the
> transformation spec's parameters instead of the matrix.

We certainly can, I just feel it’s a waste of everyone’s time.

> > If we were to throw out that shared matrix code and put it into each
> > backend we would be simply duplicating the code.
> 
> I'm not convinced we will end up with a duplication.  Certainly, for
> rotations by multiples of 90 deg no matrix multiplication is necessary
> (though possible) to construct the transform.  And in the Windows case
> having the original parameters of the transform will make it much
> easier to detect the transforms that cannot be supported on older
> platforms than it will be by analyzing the matrix.
> 
> What I'm suggesting in practice is to move the entire calculation of
> the matrix to image_set_transform, instead of communicating the
> individual transformations via the matrix that's calculated piecemeal.
> Then each port will be able to either use that matrix or do something
> different with the transform parameters.  Since image_set_transform is
> the only caller of image_set_size, image_set_crop, and
> image_set_rotation, I see no inherent reasons to return the result of
> those primitive transformations in the form of a matrix.
> 
> WDYT?

I think it’s doable, the only caveats I have is that I feel it adds
complexity and each step needs to know the result of the previous
step. For example we can’t calculate the scale factor without knowing
the width and height calculated by the crop, which in turn relies on
knowing the width and height after the rotation. The matrix
calculations need to know this information too, so we’ll need to hang
onto it.

BTW, are you really keen to get rid of the matrix multiplications?
Anything we replace them with for XRender will simply be matrix
multiplications written out in long form, keeping track of each
element separately.
-- 
Alan Third