Better undo/redo for Krita
Open, Needs TriagePublic

Description

  1. Snapshot Docker.
    1. Users should be able to save the current state of document as a snapshot. Use KisDocument::clone() to obtain a (relatively) shallow copy of the document.
    2. The docker should display a list of snapshots (shallow copies) of the document, and allow users to replace the current document with any of the snapshots taken.
    3. A user manual should be written on how to use this docker. After finishing the docker, a tutorial video should be recorded.
  2. Copy-on-Write Vector Layers.
    1. Current implementations of vector layers:
      1. Data are stored using d-pointers that are not shared
      2. Subclasses’ d-pointers are inherited from those of the parent class
      3. Have at least two constructors for each class to prevent creating multiple data instances
        1. ChildClass() : ParentClass(new ChildClassPrivate(this))
        2. ChildClass(ChildClassPrivate * dd) : ParentClass(dd)
      4. All shapes are descended from KoShape, including KisShapeLayer itself
    2. Possible implementations:
      1. Similar implementation to the one in KisTile, which manually calls KisTileData::acquire() when an edit is needed.
      2. Qt’s implicit sharing, using the Qt class QSharedDataPointer. This class is reentrant (guaranteed to be safe when different threads access different instances). This is the preferred method. However, this is not thread-safe and may cause problems if the same instance is accessed from multiple threads. More work needs to be done to ensure thread-safety.
      3. C++11’s shared_ptr, as demonstrated by Sean Parent. However, in KDE guidelines, Qt libraries are preferred over std. This should be attempted only if QSharedDataPointer cannot work.

Timeline

Week 1-4 (May 27 - June 23)
Write core code to replace the current document with another KisDocument
Unit test for replacing the current document with another KisDocument
This involves emitting signals to GUI
Probably begin writing the snapshot docker

Week 5 (June 24 - June 30)
Snapshot Docker
Write user manuals
Make a tutorial/demo video

Week 6 (July 1 - July 7)
Build a testing release, and collect feedback from the community
Possible questions:
Is snapshot taking helpful to your workflow?
Is it efficient?
Other features wanted?
Improve the docker using the feedback

Week 7-8 (July 8 - July 21)
Start working on Copy-on-Write vector layers
The re-written classes should have the same API as the old ones, where possible.
Start using implicit sharing for members of KoShapePrivate
What have been stored using pointers may be now stored using shallow copies, for example, QSharedPointer<KoShapeStrokeModel> stroke could be replaced with KoShapeStrokeModel stroke
Make api documents on how implicit-sharing works for these components, and possibly a “guideline” or example on how to use implicit sharing in other classes.

Week 9-10 (July 22 - August 4)
Implicit sharing for the KoShape hierarchy
According to the discussion above, I may need to replace Qt’s macro with code written by myself in all descendents
Write and run unit tests
Try to merge the changes into master

Week 11 (August 5 - August 11)
Write undo commands that switch between states to replace the original ones that stores actions

Week 12 + Remaining 1 day (August 12 - August 19)
Used for buffering

Related Objects

StatusAssignedTask
Opentusooaw
Resolvedtusooaw
tusooaw created this task.May 8 2019, 4:42 PM
tusooaw updated the task description. (Show Details)May 8 2019, 4:45 PM

Discussion on q-pointers.

The KoShapePrivate hierarchy uses q-pointers, which is a barrier to making it derive from QSharedData. (because the data are shared by many KoShapes and we do not know which one we are calling from)

Possible solutions:

  • Refactor out all the q-pointers and pass the KoShape pointer every time we call a function in KoShapePrivate
  • Refactor out all the q-pointers and put all methods using q-pointers into KoShape class
  • Make the shared data an inner layer of KoShapePrivate and access properties using d->s->propertyName (what if a descendent class accesses the d-pointers?)

Discussion on derived d-pointers.

Currently the KoShape hierarchy uses derived d-pointers. E.g. KoShapeContainerPrivate is derived from KoShapePrivate. Since there is public inheritance, it makes it possible for KoShapeContainer class to access things declared in KoShapePrivate class (should this be allowed?).

Do we really need derived d-pointers? Would it be better to let the derived classes have their own d-pointers? There does not seem to be any benefit to use the derived ones, except for saving some memory. And yet, using multiple d-pointers seems to allow less deep-copying.

About q-pointers.

The basic idea of Qt's d/q-pointers is to avoid private members and methods being exposed in a header file (and, therefore in a class' binary representation). It provides us with two features:

  1. binary backward compatibility (we can update private methods without breaking ABI)
  2. reduce compilation time (we don't need to recompile library (and client) code when changing private members

In our case point 1) is of no importance to us. Point 2) is interesting, but is not a "must have".

Looking at the real code, we have very few private methods in KoShapePrivate and its descendants, so I guess we can just refactor out q-pointers completely, that is:

Refactor out all the q-pointers and put all methods using q-pointers into KoShape class

Discussion on derived d-pointers.

Deriving d-pointers is also a part of "binary compatibility" and "private members exposure" problem. Basically, it is a tricky way to support 'protected' members and methods in an environment where you cannot write into a header. If all the private members are derived, then it is enough to have only one Private *p_ptr in a header, and all the descendants will happily use it. But it they are not derived, then every class of hierarchy will have to expose its own Private member.

Would it be better to let the derived classes have their own d-pointers?

I'd say, it is possible. In Krita (not Ko) code we use exactly this way. We declare QScopedPointer<Private> m_d on every level of class hierarchy and expose protected methods via a header. It is not much binary compatible, but we don't care.

Do we really need derived d-pointers?

The only benefit is a little bit better compilation time, so, no, there is no strong requirement on keeping d-pointers derived. The only trouble is, it might be a bit complicated to refactor all these classes. If you manage to do that, that would be very good :)

On KoShapeController:

Currently the methods return a KUndo2Command that will do the changes. However, it should be possible to make them only do the changes, by taking a clone of the active layer before making undoable changes to it.

The original approach looks like:

KUndo2Command *command = shapeController->addShape(...);
doc->addCommand(command);

The new approach should look like:

KisNodeSP originalState = currentNode->clone();
shapeController->addShape(...);
// currentNode has been modified now

// KisNodeReplaceCommand is a post-exec command
// to avoid multiple kundo2_i18n`s we probably want to make a factory method for it?
KUndo2Command *cmd = new KisNodeReplaceCommand(kundo2_i18n(...), currentNode, originalState);
doc->addCommand(cmd);

A note on KisNode::copyFromNode():

We are probably currently unable to "remove then add a copy" because the "original state" has to be a clone of the layer in the working document -- that will mess up with previous undo commands in the history because they cannot find the correct node.

copyFromNode() function should be no longer required as we get rid of undo commands--at that time the whole document will be replaced. See https://invent.kde.org/tusooaw/krita/commit/7c77e99a3c5037e49a44fbf033da6fdec84ed68a

On the crash upon deletion of stroke strategy without creating an undo command:

It happens only when (1) we are not using debugger (so it is probably some timing issue); (2) the mouse is released immediately after pressing; and (3) no undo command is created.

https://invent.kde.org/snippets/335 indicates that the problem probably lies in KisCanvas2, whose m_d->canvasUpdateCompressor is of type KisSignalCompressor instead of the thread-safe one.

But I did also get another error message complaining from QObject::~QObject().

On the crash upon deletion of stroke strategy without creating an undo command:

It happens only when (1) we are not using debugger (so it is probably some timing issue); (2) the mouse is released immediately after pressing; and (3) no undo command is created.

https://invent.kde.org/snippets/335 indicates that the problem probably lies in KisCanvas2, whose m_d->canvasUpdateCompressor is of type KisSignalCompressor instead of the thread-safe one.

But I did also get another error message complaining from QObject::~QObject().

Probably two fixes:

  1. Make canvasUpdateCompressor in KisCanvas2 a KisThreadSafeSignalCompressor
  1. Split the canvas updating part into an update job (?)

https://invent.kde.org/tusooaw/krita/commit/24355db3272a02230a14217da6023a953ec8f119

The crash does not come from KisCanvas2 but KisNode actually, as I said that it happens only when the undo command is not created (so KisNode is deleted by KisNodeReplaceBasedStrokeStrategy::Private's destructor, which is executed in the image thread (by the destructor of KisStroke)).

Ref: https://invent.kde.org/tusooaw/krita/blob/24355db3272a02230a14217da6023a953ec8f119/libs/global/kis_thread_safe_signal_compressor.h

https://invent.kde.org/tusooaw/krita/commit/24355db3272a02230a14217da6023a953ec8f119

The crash does not come from KisCanvas2 but KisNode actually, as I said that it happens only when the undo command is not created (so KisNode is deleted by KisNodeReplaceBasedStrokeStrategy::Private's destructor, which is executed in the image thread (by the destructor of KisStroke)).

Ref: https://invent.kde.org/tusooaw/krita/blob/24355db3272a02230a14217da6023a953ec8f119/libs/global/kis_thread_safe_signal_compressor.h

https://invent.kde.org/tusooaw/krita/commit/1bfd349378b4c1ca5c8f3ede6e465c66c94bb9c1

It comes from KoShapeManager's updateTreeCompressor actually.

We have run updateTree() before every action in KoShapeContainer, so the compressor is not really needed.