Ticket #30 (closed enhancement: moved)

The undo/redo logic currently functions by saving a snapshot of the current work environment to an XML document in memory, and executing a "restore state" command with the appropriate document when an undo operation is requested.

Unfortunately, restoring from a state document can be extremely slow in many cases. For example, if the state contains 30 MB of overlay data, it does not make sense to sift through all of it, comparing it with the current overlay data, looking for incongruities, merely to undo a single overlay edit.

Rather, such operations are easily invertible with a counter operation; for example, to undo adding a new overlay, merely record onto the stack that the inverse operation is a deletion of that overlay. When an undo or redo operation is requested, the appropriate command or its inverse can be executed quickly.

For non-invertible operations, a warning could be issued stating that a state restoration will be needed to proceed (or perhaps merely stating that "undo will be slow").