No, storing a Graphics object is usually a bad idea. 🙂
Here’s why: Normally, Graphics instances are short-lived and is used to paint or draw onto some kind of surface (typically a (J)Component or a BufferedImage). It holds the state of these drawing operations, like colors, stroke, scale, rotation etc. However, it does not hold the result of the drawing operations or the pixels.
Because of this, it won’t help you achieve undo-functionality. The pixels belongs to the component or image. So, rolling back to a “previous” Graphics object will not modify the pixels back to the previous state.
Here’s some approaches I know works:
-
Use a “chain” of commands (command pattern) to modify the image. Command pattern works very nice with undo/redo (and is implemented in Swing/AWT in
Action). Render all commands in sequence, starting from the original. Pro: The state in each command is usually not so large, allowing you to have many steps of undo-buffer in memory. Con: After a lot of operations, it becomes slow… -
For every operation, store the entire
BufferedImage(as you originally did). Pro: Easy to implement. Con: You’ll run out of memory fast. Tip: You could serialize the images, making undo/redo taking less memory, at the cost of more processing time. -
A combination of the above, using command pattern/chain idea, but optimizing the rendering with “snapshots” (as
BufferedImages) when reasonable. Meaning you won’t need to render everything from the beginning for each new operation (faster). Also flush/serialize these snapshots to disk, to avoid running out of memory (but keep them in memory if you can, for speed). You could also serialize the commands to disk, for virtually unlimited undo. Pro: Works great when done right. Con: Will take some time to get right.
PS: For all of the above, you need to use a background thread (like SwingWorker or similar) to update the displayed image, store commands/images to disk etc in the background, to keep a responsive UI.
Good luck! 🙂