Page MenuHome

Undo: increase speed of transformation undo by over 9000

Authored by Andrew Williams (sobakasu) on Jan 21 2019, 12:08 AM.



this patch adds support for accumulation mode undo for transformations.
this is a big speed improvement when you are working with a large scene.

i'm guessing the reason that it hasn't been implemented this way is that there are some edge cases where inverting the transformation won't work (maybe when using constraint modifiers or armatures?).
if there are some edge cases where it doesn't work, transform_undosys_invert() could detect those cases and return false, which makes it fall back to the global undo system.

I also updated the logic in undo_system for undo/redo, because it wasn't working with this code.

related issue:

Diff Detail

rB Blender

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.EditedJan 21 2019, 3:03 AM

Adding optimized undo for specific operators is the wrong direction to go in. It's going to make the code too complicated and result in many bugs.

For transform some difficulties are:

  • There are indirect effects like keyframing and automerge. Detecting all those cases is error-prone.
  • Transforms are not always reversible: snapping, scale to zero, constraints that project to a plane, ... .
  • Some setting in the user interface that affects the operator may have changed since the original operator ran.
  • Even if you detect all that, you still can't reverse the operation exactly due to floating point precision errors.

There are more general ways to optimize the undo system, like making it work per datablock instead of the whole file. That is more work, but it's where effort in this area should go to if we want to have reliable undo.

This revision now requires changes to proceed.Jan 21 2019, 3:03 AM
  • Even if you detect all that, you still can't reverse the operation exactly due to floating point precision errors.

sure, but you get floating point errors by just using blender in general. for example i could grab a cube and move it up 0.1 and then up again 0.2. then i could press undo twice (which would take 50 seconds with T60418) or I would probably just press g z -0.3 to move it back down 0.3. The z value might now actually be 5.551115123125783e-17 but I don't know or care about that because it says Location : Z: 0m in the UI.

There are cases where the error is not so subtle, and then users will not be able to undo reliably. Or worse, only notice something got broken hours later.

We indeed can't guarantee precision if the user does an inverse transform manually. But the undo system cannot be based on being mostly accurate, I guarantee it will come back to bite us.

I've written ideas for how to optimize undo here: T60695: Optimized per-datablock global undo.

agreed optimising the global undo sounds like a better way. at least i learnt how the undo system works. kind of