Fixing the Drift in Shape Rotations

There should also be strategies for the choice of center to be invariant even after re-selecting the rotated set of shapes. You should be able to do this by finding the two points farthest from each other, and choosing the midpoint between the two, for instance. But that point might not be unique, so maybe finding the center of the smallest circle enclosing all objects would be a better example?

&gt;However, the rotated shapes probably have a different average center; which means that your second rotation (ie to rotate things back) is pivoting around a different point. And that&#x27;s what causes the change of position.<p>Uhh, what? Why doesn&#x27;t the rotated group have the same centre as the original? The article glosses right over this without explaining it. Is it floating point imprecision? Is it from rasterization?

The author treats this kind of destructive rotation as a positive, but this is exactly why rotation modifier as part of the object tree is generally a good thing! There&#x27;s no need to recompute a center because it&#x27;s the same center, only a rotate operation has been applied on top of the node. Also, that&#x27;s how rotation works in the web browser, which these design apps are often targeting.

I think instead of the center of the bounding box, I&#x27;d instead use the average center of each selected item. Each primitive will have a rotation agnostic invariant center relative to its location, so the average of those will always be invariant