Re: Image transformations

[Richard Copley <rcopley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4948 bytes --]

On Fri, 14 Jun 2019 at 15:44, Eli Zaretskii <eliz@gnu.org> wrote:

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

OK. (I meant to thank you for the link, in my previous message. It got lost
in
editing. Thanks!) The matrix representation wouldn't cause a problem here.
Since
we would disallow applying a rotation or shear, we would be sure that the
matrix
had no rotation or shear component, and it would not be too hard to derive
the
rectangular transformation from the matrix components.

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

OK. We would have the advantage of good documentation, as always.

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

OK, but I don't think homogeneous coordinates are platform specific,
or any more complex than necessary.

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

OK. And :rotation? And :shear, since combining stretches and rotations will
allow arbitrary shearing transformations?

I'm imagining allowing these transformations to be composed in any order,
which would be nice for interactive use (a key for rotating, a key for
stretching horizontally, and so on). If we don't want to support that
then yes, you're right, we can calculate the resulting attributes
from one stretch followed by one rotation (or whatever), easily enough.

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

Not "more compact".

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

OK. As long as you don't propose allowing composing the simple
transformations,
including rotations, in any order, then you won't need to do that, indeed.

I'm not writing this just to be a thorn in your side. I worry the model
you're
presenting might lead to difficulties that have already been overcome
elsewhere.
But it's probable I have overestimated how much generality you're proposing
to
support.

I like the idea Yuri described. It's as powerful and easier to use. As far
as I
can see there would still be a homogeneous matrix on the implementation
side,
though, with the accompanying variations for each platform, so perhaps it
doesn't overcome your reservations.

[-- Attachment #2: Type: text/html, Size: 5984 bytes --]