Re: Image transformations

[Stefan Monnier]

> In my research I found out that the equivalent Windows graphics APIs
> need a matrix that is the inverse of what we calculate in image.c.

[ Beware, I know next to nothing about graphics APIs and such, so please
  assume I'm mostly just spewing hot air.  ]

IIRC one matrix is needed when computing "display position from
image position" and the inverse is needed when computing "image position
from display position".  So this difference seems to reflect
a fundamental difference in the way the problem is approached (unless
the API(s) perform(s) matrix inversion internally as well).

Right?

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

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

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


        Stefan