Nick Gammon said:
The image isn't -actually- rotated when WindowImageRotate() is used, because due to the rectangular nature of images, that would either clip the image's corners or require a resizing of the canvas. It's simpler just to store a rotational value, and use that when the image is drawn.
I can't say I agree with this bit.
For maximum generality I am experimenting with setting up a translation matrix (see the API documentation mentioned above). This lets you set up 6 numbers, M11, M12, M21, M22, Dx and Dy.
Effectively this lets you control the translation between x and x' as a multiplication of the old x/y position with a multiplier (applied independently to x and y) followed by a displacement.
In a nutshell, this lets you scale, rotate, shear or reflect depending on the six values you supply.
So this gives you so much more than mere rotation, you could scale as well (or reflect).
I think for simplicity we will assume that the source image is to be completely applied to the destination (in other words, excluding sub-images), and at a given point.
You are correct that with virtually any transformation (that is, excluding mere reflection) some clipping or resizing will be required. However that is really just a case of having the room available to start with.
So, for example, if I had a long, thin image with the word "inventory" in it, and wanted to rotate it 90 degrees then the destination would need to be as deep as the source is wide, for it to fit.