Undo system allows to manage history of changes

We need something flexible to serve as an undo system. Exemplary data to be undone consists of tool usage (e.g. using brush), per-layer events (e.g. applying a filter to a layer), per-image events (e.g. flatten visible layers).
The tool usage undo and filter events all can be done by storing the state of the part of image being modified, both before and after the action.
The undo framework should allow user to undo and redo specific action as a whole and not only by undoing/redoing spefic event like QMouseEvent. In order to achieve this, we need a transactional-like system. At the start of each action the transaction would be begun and events appended to it. With the end of action (e.g. releasing mouse button) the transaction should be commited and some additional work can be done - that is removing overlapping bounding rectangles and storing them in a unique manner, on-the-fly gzip compression, etc.
For ways of implementation of undo frameworks see http://gimp-plug-ins.sourceforge.net/gimp2/doc_undo.html, http://lists.xcf.berkeley.edu/lists/gimp-developer/2002-October/007571.html, http://docs.gimp.org/en/gimp-concepts-undo.html. The transaction system is used in Krita.

As we do some bit-blitting in undo framework, it would be wise to speed things up by using some SIMD-fu. This could be Qt 4.7 based (see http://labs.trolltech.com/blogs/2010/08/24/improving-the-rendering-performance-with-more-simd/) or using external library (e.g. vc, http://gitorious.org/vc#more - this was taken from one of the comments in the article). This would work best with aligned data (however, we don't know the boundaries of undoable action and aligning data would require a change in Qt sources).

rawo[2010-08-26]
I'm fine with the simd support. I rather prefer to use external lib and later eventually switch to qt. Nevertheless at the moment this support should be posponed if it would take more than a week to introduce it.