Re: Image transformations

[Eli Zaretskii]

> Date: Thu, 13 Jun 2019 23:26:26 +0100
> From: Alan Third <address@hidden>
> Cc: address@hidden
> 
> > I'm beginning to think we should do this on all platforms, and leave
> > the matrix calculation, if needed, to the terminal-specific back-ends
> > (xterm.c, w32term.c, etc.).  It sounds like we gain nothing by
> > spilling XRender-specific stuff in image.c and letting all the other
> > platforms adapt.
> 
> I think you have a fundamental misunderstanding of how the
> transformation matrix is being used.

That's always possible, although I stared at that code and stepped
through it in a debugger long enough to assume it's not the case.

> It’s not specific to XRender.  Aside from a few short‐circuits the
> only XRender specific code is in image_set_transform, and XRender,
> NS and Cairo all have their own code in there, and use the same
> transformation matrix.

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.  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 could even use the same matrix with ImageMagick with a bit of work.

I think this would be a wasted effort.  There's no need to make all
the implementations use the same matrix, unless they all assign the
same semantics to the matrix -- which doesn't appear to be the case,
at least not as far as this discussion shows.

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