Re: Image transformations

[Eli Zaretskii]

> Date: Mon, 17 Jun 2019 22:13:32 +0100
> From: Alan Third <address@hidden>
> Cc: address@hidden
> 
> > > In another part of this thread you pointed out that crop and image
> > > slices are doing basically the same thing. I hadn’t realised that.
> > > Given that that’s the case, I think we should just get rid of the crop
> > > function.
> > 
> > I agree, but please make sure the slices are indeed a 100% replacement
> > (I cannot yet do that because I don't have a working :crop support to
> > try it).
> 
> As far as I can tell they are perhaps a 90% replacement, the only real
> difference is that the interactive keybinds from image.el don’t work
> (r for rotate, + for scale up, etc.). They can probably be made to
> work, but to be honest I’m not sure it matters. If someone is cropping
> an image I can’t think of any use cases where they’d want to then
> provide the user the ability to play with that image interactively.

I finished working on the Windows implementation, and have a working
prototype.  The tests you wrote all work, with the single exception of
cropping (not surprisingly, since I didn't really figure out how is
this supposed to work).  I guess the above means I don't have to dig
into this, as we are losing :crop in the native transforms, is that
right?

So now I'm ready to discuss the restructuring of the transform
matrices code.

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.  I
think that calculating a matrix and then inverting it at draw time is
inefficient at best and silly at worst; I'd rather calculate the
inverse matrix to begin with.  Calculating the inverse matrix involves
reversing all the primitive transformations (translations change sign,
rotations change the sign of the angle), and also changing the
multiplication order from left-multiplication of matrices to
right-multiplication.

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?

Finally, there's the issue of what to return from image-transforms-p.

Thanks.