Re: Image transformations

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Copley <rcopley@gmail.com>
> Date: Fri, 14 Jun 2019 13:49:52 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs Development <emacs-devel@gnu.org>
> 
>       http://winapi.freetechsecrets.com/win32
> 
>     According to it, GM_ADVANCED is not supported on Windows 9X.
> 
> Is it important to support such advanced features there?

I'd like to support there what can be supported.  Which means
everything except rotations.

>     That might work, and doesn't really
>     contradict what I say above, but we should first make sure that all
>     the toolkits we support interpret the matrix the same.
> 
> They don't, but the differences are small platform-specific fixups
> (possibly inverting and/or transposing the matrix, as well as
> converting the values to the appropriate types). The mathematical
> fundamentals are the same for all the platforms.

The mathematical fundamentals are the same, but if we interpret the
Lisp-level matrix as only some platforms do, Lisp programmers whose
background is from the rest of the platforms will likely become
confused and will make mistakes.

IOW, I consider complex platform-specific interfaces generally
unsuitable for being exposed on the Lisp level.

>     > Thirdly, the homogeneous matrix is compact and uniform, and makes
>     > it easy to compose and invert (undo) transformations.
> 
>     So are/do the attributes.
> 
> I think you're underestimating the difficulty of that part. Here's a
> concrete example. Suppose the user wants to apply two
> transformations,
> 
> 1. Stretch by factor 2 in the x direction, then rotate clockwise by
> 45 degrees, then translate to the right by 100 pixels.
> 
> 2. Stretch by factor 0.5 in the x direction, then rotate clockwise
> by 90 degrees, then translate left by 100 pixels.
> 
> Calculating the resulting matrix might be a little tricky to get
> right, but with some experimentation you'll get there. Calculating
> the resulting shear, rotation, scale and translation is much more
> difficult to conceptualize.

I don't see why.  We have :width and :height for stretching in a
single direction, and :scale for stretching in both.  Translation is
impossible anyway, because we can only place images by adjusting
buffer contents and using various layout features like :align-to.

>     Which representation is more compact is
>     arguable: for example, the matrix representation of a rotation is much
>     more wasteful than just a single angle of rotation parameter.
> 
> I didn't say "more compact".

You said "compact and uniform".

>     But I think this is a tangent, because my proposal doesn't preclude
>     providing a matrix-based API in the future.
> 
> It will make it difficult to preserve backward compatibility. Constructing
> the :crop, :rotate, etc., from the matrix, is hard.

I don't see why someone will need to deconstruct a matrix, so I don't
think this problem should bother us.