37 ms·
>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 dif
by _dain_ 5y ago
>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's what causes the change of position.
Uhh, what? Why doesn'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?
- glenjamin 5y agoI think it’s because the centre is computed using the X and Y axis, and the rotated shapes have a different bounding box on those axes.
- lainga 5y agoWhy would you use bounding boxes for computing centres!
- mooneater 5y agoPresumably for speed
- ulber 5y agoMore likely ease of implementation. The use case shown here is an interactive UI element, so performance isn't really a concern.
- mkl 5y agoYou probably already have xy bounding boxes for every element and the selection itself as it helps with selecting, drawing, etc., so using them is the easiest option.
- bsder 5y agoComputational geometry is hard. Let's go shopping! If I'm being less un-charitable, the reason is that this bug is way down the list of priorities and fixing it with a proper solution is a lot of code and work that won't result in any new revenue.
- deleted 5y ago[deleted]
- a_e_k 5y agoI'd wondered that as well. Playing with tldraw and excalidraw, it looks like it's using the center of the bounding box as the pivot point. Suppose that you have three boxes like this: * - - - * . . . * - - - * | | | | | | | | | | | | * - - - * * - - - * . . . @ . . . . * - - - * . | | . | | . | | . . . . . . . . * - - - * The pivot for rotating them will be at the @ in the center of the bounding box around the three. If you then turn that counterclockwise by 45 degrees: . . . . . . . . . * . . . . . . . . . . / \ . . / \ . . * * . . \ / . . \ / . . * @ * . . / \ / \ . . / \ / \ . * * * * . \ / \ / . . \ / \ / . . . . * . . . . . . . . . . . * . . . then the center of the bounding box has now moved towards the corner of what was originally the upper right square (because there isn't a fourth square to complete the symmetry and push the bottom of the box around the three squares down). Rotating again will now pivot around this new point rather than the original and a rotation 45 degrees clockwise back to the original angle will now have shifted the boxes. Honestly, I'd think the correct solution here would be to pivot around the center-of-mass or some other rotationally-invariant point.
- kingcharles 5y agoForget the article, I'm more impressed by your ASCII art.
- iainmerrick 5y agoThe bounding box is the natural implementation because it matches what the user sees -- when you select multiple objects, the rotation handle is at the corner, because where else would it be? Plus it’s very easy to code and to test. But yeah, using a rotationally-invariant point would be better than the stateful fix the article goes for. Center-of-mass would make sense except it might do strange things if you have a mix of solid shapes and lines. How much mass should the lines have? Using the centre of the bounding circle is probably best, as others in this discussion have suggested.