Image rotation

[RokB]

RokB, re-arranging the pixels is computationally expensive. Transforming the getPixel() and setPixel() co-ordinates would be comparatively much faster. One problem with that approach is when you create a texture from that image. It looks like it would have to do the pixel re-arranging before/during that conversion.

Another problem would arise when using Image::copy() it seems, which is necessary for creating complex images. Personally, I think it would be a lot simpler to create a function rearranging the image rather than to go around tweaking everything that currently uses the class. I've already done so for my own use. It's not insanely expensive and it's not like it's the sort of thing you'd be using very often.

[Nexus]

Personally, I think it would be a lot simpler to create a function rearranging the image rather than to go around tweaking everything that currently uses the class.

Nothing will break of course, it's just an internal optimization.

For simplicity, we can mark copy() and other operations so that they "evaluate" the image. Lazy evaluation loses a bit of its usefulness as such, with a bit of thought also this could be addressed.

One advantage that lazy evaluation definitely has is that it allows two subsequent transforms to be executed efficiently (O(1)). For example, it would then be enough to provide rotateCcw() and rotateCw() -- we wouldn't need a rotate180(), because twice 90° costs nothing.

[Hapax]

we wouldn't need a rotate180(), because twice 90° costs nothing.

This is true and I'm sure it'd be perfectly acceptable. The only reason I mentioned a separate 180 degree rotation previously was because it can be optimised to be faster than 90.