Re: Image transformations

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Mon, 24 Jun 2019 15:50:14 -0400
> 
> IIRC one matrix is needed when computing "display position from
> image position" and the inverse is needed when computing "image position
> from display position".

I don't think I understand what "display position" means here.  Did
you mean coordinates of a pixel?

What actually happens AFAIU is that in some cases the matrix describes
how to convert the original image to the transformed image, while in
others it describes how to transform the image space into the
transformed space.

> Also, one of the two matrices can't be computed if the transformation
> turns the 2D image into a line (or a point).

We don't support such transformations.

> > I think that calculating a matrix and then inverting it at draw time
> > is inefficient
> 
> Compared to the cost of handling the image, inverting a 3x3 matrix
> is probably negligible, tho.

Maybe so, but it still sounds silly to me.

> > Given these findings, what would you prefer to do in image.c?  We
> > could either (a) make the individual functions (image_set_rotation
> > etc.) return the transformation parameters, and leave the matrix
> > calculation to image_set_transform, or we could have the individual
> > functions accept a flag to tell them whether to generate XRender/Cairo
> > style matrices or NS/Windows style.  Or maybe you ave yet another
> > idea?
> 
> As long as the matrices aren't made visible to Elisp and only one GUI
> can be compiled at a time, we could also use a compile-time flag.

Yes, but #ifdef's uglify the code too much, IMO.