Description

Undoing is slow (and saturates a core of the CPU) if the history is long, and full of selection manipulations (blurring is the worst)

Steps to reproduce the bug

1. open or create image
2. lots of editing operations
3. undo

System

• Package format (flatpak, native package, snap?): flatpak
• App version: 0.5.3 (unstable)

Suggested solution

• Add special operation(s?) to the history corresponding to the state of the pixbuf when saving
  • is the initial state (blank canvas or original file) such a special operation? or an other type?
  • contributions from Improved undo performance. #561 made the states object-oriented
  • remember only the last saved state no and delete the other operations from the history? no
    • or keep all of them for now? what has been done for 0.6.0
    • only keep a few of them? --> limit the number of states, which will increase the number of operations between each older one
• limitation: what happens if an user saves while an editing operation (selection? cropping?) is going on? nothing it's not the main pixbuf
• when undoing, recompute only from that remembered pixbuf
• use that pixbuf restoration process refactoring to improve the "reload from disk" action
• make the history rebuilding asynchronous
  • since the number of operations will increase, undoing older operations will be slow: add feedback to the UI so the user knows it's normal (show the info banner while recomputing the image)
• implement GFileMonitor support to tell the user his image has changed on the disk