5 ms·
Having written an undo/redo stack for a graphical editing component. That's pretty much what I did. Maintain a redo stack that holds the operations and paramete
by wila 9y ago
Having written an undo/redo stack for a graphical editing component. That's pretty much what I did. Maintain a redo stack that holds the operations and parameters.
An undo then became going back to the original image plus a redo of everything on the stack minus the last operation. Rather simplistic, but it worked well for our purposes and was easy to implement.
- default-kramer 9y agoI do this all the time when I write a game which can easily be described as a sequence of discrete moves. Chess is a good example, and games with physics engines are the opposite. As you said, the Undo operation is just "start with the initial board and apply N-1 moves to get the current state." This plays nicely with immutability too.
- terminalcommand 9y agoStarting with the initial board and applying n-1 moves should be significantly slower than using immutable data structures. I don't have much experience in algorithms but I think O(1) trumps O(N-1) :).
- wila 9y agoThe problem with graphics though is that some graphical operations are destructive so you can't just undo the operation. In order to undo without a redo list, you would have to keep a complete graphical representation of the image and each operation. With images the memory usage goes up very quickly in that case, copying large blocks of memory on each operation makes your image editing slow down too.
- beached_whale 9y agoI saw a video and Photoshop used to use the command pattern but moved to just saving complete images(mostly) and it was much simpler and fast
- wila 9y agoWell I wasn't creating Photoshop :) this really was the easiest solution for our needs.
- Sharlin 9y agoLightroom, on the other hand, stores only the edit history by its very design (non-destructive editing). Though I guess that during editing it may cache intermediate results to speed things up.