Math behind rotation in MS Paint (2011)
math.stackexchange.com
math.stackexchange.com
The world is very different today, bilinear texture sampling is built into GPU hardware and is lightning fast. The idea that a sequence of skews might be more efficient is a curious relic of when CPU was considered a reasonable place to do image transformation.
[0]: https://www.amazon.com/Digital-Image-Warping-George-Wolberg/...
Real time graphics is of course a different matter.
And the scaling also requires interpolation. So I'm not sure if it's better or worse in terms of bluriness.
Back in the day, the "rotozoom" coefficients were chosen at a nearest integer to avoid interpolation. This of course means that you can't continuously choose the value of the angle. Interpolation doesn't play nice with a palette-based image with a fixed number of colors anyway.
When palette and integers are not a restriction, higher quality interpolation (bicubic, etc) is also an option. Comes with tradeoffs, of course.
Using integer coefficients will also enable all kinds of opportunities for assembly-level optimization.
Rotations about the origin are linear transformations. Rotations about an arbitrary point are affine transformations.
States can add upon these requirements, and several require both.
[0]: Yes, it's just a multiplication which is taught but be honest: How many students will come up with that on their own without being told?
It's a trick because to many it's not immediately obvious (even if you know about transformation matrices).
This is exactly the kind of thing I visit HN for -- the demonstration and explanation of an interesting hack. You may not have found it interesting, which is perfectly fine, but please don't assume that others didn't.