[OpenRaster] Save history

[pedropaulosuzuki]

Description
The OpenRaster specification "has" a standard extension for importing/exporting history, as defined in the spec.

The problem is the spec page is empty and I don't know if they have any other docs anywhere else. So no idea how it would look in the stack.xml (btw: would it even be in the stack.xml?)

[cameronwhite]

The page also says Status: proposal so I'm not sure if any more docs exist for this elsewhere..

[pedropaulosuzuki]

The page also says Status: proposal so I'm not sure if any more docs exist for this elsewhere..

Maybe we can create an updated proposal. @cameronwhite, @Lehonti, @Matthieu-LAURENT39 and @PabloRufianJimenez, what are your thoughts?

I'd personally use a separate file (history.xml) inside the .ora, instead of creating it inside stack.xml, as it doesn't seem to make a lot of sense to put the history itself inside of the layer stack file.

[cameronwhite]

• This could turn into a very large file if there are a lot of edits to the layers' contents, especially if this takes the simplest and most portable approach of storing an image for the previous version of the layer
• There can be custom history items (e.g. from add-ins) or things that are very Pinta-specific like undo items from the shape / text tools, so you'd need to figure out what to do with those
• Agree that it's likely separate from the main layer stack in the .ora file

[Matthieu-LAURENT39]

Fully agree with what cameronwhite brought up.
To expand on the first point, I don't really think we can avoid storing the various versions of a layer's content, so this will come at a pretty steep storage cost. We can store only the changed region in the image and the offset at which to apply the change, which could save space for some effects.
But I doubt we can do much more than that without breaking compatibility with non-Pinta programs (or even across Pinta versions, if an effect receives changes).

As for the second point, I assume each history item would contain:

• the tool name
• the changed pixels
  so for items with tools that we don't recognize (like from removed add-ins, or from non-Pinta programs), we can just show that name and a fallback icon (maybe something like a question mark).

[pedropaulosuzuki]

Fully agree with what cameronwhite brought up. To expand on the first point, I don't really think we can avoid storing the various versions of a layer's content, so this will come at a pretty steep storage cost. We can store only the changed region in the image and the offset at which to apply the change, which could save space for some effects. But I doubt we can do much more than that without breaking compatibility with non-Pinta programs (or even across Pinta versions, if an effect receives changes).

As for the second point, I assume each history item would contain:

* the tool name

* the changed pixels
  so for items with tools that we don't recognize (like from removed add-ins, or from non-Pinta programs), we can just show that name and a fallback icon (maybe something like a question mark).

I was thinking more in terms of actions than in terms of bitmap states. If we could save the history as a series of steps, then we could save them without taking too much space.

Think something like:

1. Create new image (800x600)
2. Create new layer above layer 1
3. Select layer 2
4. Draw rectangle from (50, 50) to (120, 120) with color #000 and outline Fix formating for headers in patch-guidelines.md #222, 2 pixels wide outline.
5. Select layer 1
6. Fill bucket on pixel (15, 15) with tolerance 35 and flood mode global

This would also be close to a scripting workflow, as allowed by #1879. It should be backwards-compatible, when possible. If a step depends on an add-in, then we could show a warning dialog or something if we try to undo some item earlier in the stack.

This would break compatibility with other programs, but I don't think it would be the worst compromise. Some implementation details might be tricky, but I think it might be doable.

[cameronwhite]

Being able to do that would be great for making Pinta's internal history management lightweight (and probably making tools more testable). A lot of the history items are just storing diffs of changes to the canvas pixels, which is more expensive memory-wise (but far simpler to implement) than storing something like apply brush with these settings and these mouse movements
I suspect it's a rather large amount of work and kind of ties into the live / re-editable tools ideas

I'm not sure how I feel about actually doing this for .ora files, since it won't be compatible with any other programs. Although I'm also not sure how useful it would be for users to transport full history across programs anyways?

[pedropaulosuzuki]

Being able to do that would be great for making Pinta's internal history management lightweight (and probably making tools more testable). A lot of the history items are just storing diffs of changes to the canvas pixels, which is more expensive memory-wise (but far simpler to implement) than storing something like apply brush with these settings and these mouse movements I suspect it's a rather large amount of work and kind of ties into the live / re-editable tools ideas

For Pinta's internal history, we probably would still need to cache intermediary points of the history, otherwise we'd need to evaluate them from the start every time, which can become a big hit in performance (as most transformations don't have a clean 'inverse function'). Probably at every 10 undos or so is good enough, or for each expensive operations.

I'm not sure how I feel about actually doing this for .ora files, since it won't be compatible with any other programs. Although I'm also not sure how useful it would be for users to transport full history across programs anyways?

The idea is to have your history back when you open a file in Pinta itself. For other programs it really doesn't make much sense, as operations completely are different anyway.