I've long been speculating about ways to see and manipulate the revision history of a Krita project. I feel like I might have asked about this here before, but I don't see it anywhere in my old forum posts, so.

There are already various ways of taking snapshots of the work-in-progress files. Git works, but it was optimized for working with text, so committing large binary files is slow. Git also can't merge different edits to images the way it can merge text commits. File storing/sharing services like Dropbox are faster, I think, but most are proprietary, and as far as I know none support flexible merging of edits either.

Tim Chen as a grad student experimented with a solution. You can still read the whitepaper and watch a demo video he made, which looks pretty magical. Unfortunately, his solution was based on hacks to the GIMP code base back in 2011, meaning it probably doesn't generalize to other applications, and his specific implementation probably isn't even compatible with modern GIMP anymore either.

But maybe we could work toward a system like this gradually? Simply saving Krita's undo history to a file — either a separate file or optionally as part of the project's main .kra file itself — would be a big step forward.

Each image layer having their own undo history would also help.

I could envision a couple of approaches:

* Use save incremental version automatically and then take a binary diff of them
* Save undo states: but undo stats are mostly the changed tiles in layers
* Expand the macro recorder to record everything; possibly integrating that with the undo system (mypaint doesn't save tiles for undo, but keeps the full command history, for instance)
* Do it like a photoshop engineer revealed at a cpp conference in Moscow: every undo state is a complete, shallow copy of the image, there are no undo/redo commands. This gives a full history of the image at every step and makes a history brush possible as well.

The last method probably is the most flexible, but also the hardest to implement. Although we made kind of a start with it since in 4.0, saving an image operates on a shallow clone, so it can happen in a background thread. And once shallow cloning is available and efficient... The possibilities start to open.

I would say, dig into the source code for each option and see how it strikes you

Ps. using a DAG of operations comes closest to fixing the recorder, but not quite. I guess that the paper you linked to was inspired by the architecture of gegl, more than by a deep analysis of the requirements, and in any case, Krita's internals are completely different from that sort of architecture.

boudewijn wrote:The last method probably is the most flexible, but also the hardest to implement. Although we made kind of a start with it since in 4.0, saving an image operates on a shallow clone, so it can happen in a background thread. And once shallow cloning is available and efficient... The possibilities start to open.

There's a start on it already? That's a pleasant surprise. I'm intrigued to see what will be in Krita in 5.0 then.