GPencil: Undo System #95450

New Issue

Falk David · 2022-02-02T18:46:30+01:00

Falk David commented

2022-02-02 18:46:30 +01:00

Overall design

The gpencil undo system is a relative differential undo system (see https://wiki.blender.org/wiki/Source/Architecture/Undo). Steps do not encode the whole object data, but rather only what changed between steps. We make use of the update cache (#95401) to retrieve what changed.

How undoing works

We only save “one-way” diffs. That means we can get from the current state into the future, but we cannot go into the past. E.g. when drawing a stroke and then deleting a layer, the system will save the change with the stroke and then the change with the layer. When we undo now we need to restore the deleted layer, but the previous step just has the data with the change of the stroke.
In this case we need to go back further in time until we find a step that changed what we want to restore. Then we need to re-apply all the diffs (going back to the future) until we reach the desired step.
In order to guarantee that we always find a step that has enough data in it, we force the first step of the “grease pencil undo chain” to be a full copy (initial full-copy). When a step is freed, we also ensure that the full copy is kept in the first position.
In the case that the previous step already encodes the element we are looking for, we just apply those changes to the current state.

How redoing works

Redoing is more trivial: we just need to apply the step's diff onto the current grease pencil data.

Limitations

Going into object mode in an undo step
Right now, when going into any gpencil mode from object mode and then undoing will not work. This is probably because the global undo system is not able to restore the object mode for gpencil objects.

Undoing changes outside of the active grease pencil data
The gpencil undo system only encodes a step if:

the active gpencil data was modified
the scene's frame changed
the step before was not part of the same undo system (initial full-copy)
All other modifications are not taken into account, and therefore not undo-able (similarly to how the mesh undo system works).

Editing multiple gpencil objects
Because of how steps are encoded, the current system only supports undo/redo on the active GP object. If the dopesheet displays keyframes of several objects, only the modifications applied on the active object's one will be undo-able.

How to free the update cache

Without the undo system, the update cache was always freed after the update-on-write happened, e.g. after the changes were written to the eval object. With the undo system, we need to make sure that the cache is still populated when we encode a step. This can fail for example when we run a modal operator. Every modal execution might trigger an update-on-write, but only after the operator has finished do we encode the undo step.
So we need to make sure that we only free the cache after the encode step was run. This is done by tagging the gpencil data with a flag GP_DATA_UPDATE_CACHE_DISPOSABLE after the encode, and clearing it after a free.

Memory usage

Steps that encode full copies or layer copies might become very large. In the worst case, the entire object might be duplicated multiple times in memory. This applies mostly to operations that modify layers (e.g. reordering layers, deleting a layer or adding a new one).

Additionally, we need to make a decision on what happens when the update cache is not populated. Right now, this will fall back to a full-copy of the data block. Again this will increase the memory usage substantially. An alternative would be to only encode steps when the cache is populated. Ideally this would be the case once the cache is used everywhere in grease pencil.

Implementation

Undo system patch: D13996

Co-authored-by: @yann-lty

## Overall design The gpencil undo system is a relative differential undo system (see https://wiki.blender.org/wiki/Source/Architecture/Undo). Steps do not encode the whole object data, but rather only what changed between steps. We make use of the update cache (#95401) to retrieve what changed. ## How undoing works We only save “one-way” diffs. That means we can get from the current state into the future, but we cannot go into the past. E.g. when drawing a stroke and then deleting a layer, the system will save the change with the stroke and then the change with the layer. When we undo now we need to restore the deleted layer, but the previous step just has the data with the change of the stroke. In this case we need to go back further in time until we find a step that changed what we want to restore. Then we need to re-apply all the diffs (going back to the future) until we reach the desired step. In order to guarantee that we always find a step that has enough data in it, we force the first step of the “grease pencil undo chain” to be a full copy (initial full-copy). When a step is freed, we also ensure that the full copy is kept in the first position. In the case that the previous step already encodes the element we are looking for, we just apply those changes to the current state. ## How redoing works Redoing is more trivial: we just need to apply the step's diff onto the current grease pencil data. ## Limitations ~~**Going into object mode in an undo step** Right now, when going into any gpencil mode from object mode and then undoing will not work. This is probably because the global undo system is not able to restore the object mode for gpencil objects.~~ **Undoing changes outside of the active grease pencil data** The gpencil undo system only encodes a step if: - the active gpencil data was modified - the scene's frame changed - the step before was not part of the same undo system (initial full-copy) All other modifications are not taken into account, and therefore not undo-able (similarly to how the mesh undo system works). **Editing multiple gpencil objects** Because of how steps are encoded, the current system only supports undo/redo on the active GP object. If the dopesheet displays keyframes of several objects, only the modifications applied on the active object's one will be undo-able. ## How to free the update cache Without the undo system, the update cache was always freed after the update-on-write happened, e.g. after the changes were written to the eval object. With the undo system, we need to make sure that the cache is still populated when we encode a step. This can fail for example when we run a modal operator. Every modal execution might trigger an update-on-write, but only after the operator has finished do we encode the undo step. So we need to make sure that we only free the cache after the encode step was run. This is done by tagging the gpencil data with a flag `GP_DATA_UPDATE_CACHE_DISPOSABLE` after the encode, and clearing it after a free. ## Memory usage Steps that encode full copies or layer copies might become very large. In the worst case, the entire object might be duplicated multiple times in memory. This applies mostly to operations that modify layers (e.g. reordering layers, deleting a layer or adding a new one). Additionally, we need to make a decision on what happens when the update cache is not populated. Right now, this will fall back to a full-copy of the data block. Again this will increase the memory usage substantially. An alternative would be to only encode steps when the cache is populated. Ideally this would be the case once the cache is used everywhere in grease pencil. ## Implementation Undo system patch: [D13996](https://archive.blender.org/developer/D13996) Co-authored-by: @yann-lty

Falk David commented

2022-02-02 18:46:30 +01:00

Added subscribers: @yann-lty, @filedescriptor

Antonio Vazquez commented

2022-02-03 12:54:30 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Falk David was assigned by Antonio Vazquez

2022-02-03 12:55:30 +01:00

hamza.SMA commented

2022-08-20 12:56:29 +02:00

Added subscriber: @hamza-el-barmaki

hamza.SMA commented

2022-08-20 12:56:30 +02:00

HI, reallly nice work @filedescriptor
any news on this in near future maybe blender v3.4 or 3.5 or after rewrite of eevee-next?

a found that for primitive tools 'like arc, circle tools..' are lagging in heavy GP, also ,sculpt mode every tool works smouthly except strenght tools which is lagging in heavy GP ,is it a a knowns issue?

HI, reallly nice work @filedescriptor any news on this in near future maybe blender v3.4 or 3.5 or after rewrite of eevee-next? - a found that for primitive tools 'like arc, circle tools..' are lagging in heavy GP, also ,sculpt mode every tool works smouthly except strenght tools which is lagging in heavy GP ,is it a a knowns issue?

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

GPencil: Undo System #95450