Drawpile
Drawpile copied to clipboard
drawpile
All users sharing one undo stack?
In recent sessions we've encountered situations where when one user presses ctrl+z, nothing happens to their drawing. Meanwhile others (who were drawing on a remote area of the canvas) finding their brushstrokes disappear. We realized that it seemed like all users were sharing one single undo stack instead of having their individual ones. In the end we decided to revoke the permission for everyone just so people's work won't be ruined by accidentally undoing others' brushstrokes.
I'd like to know whether this is how the feature is intended to work, or we've triggered a bug about it.
Please see #779 regarding this issue and the second comment from Callaa.
Also read this: https://github.com/drawpile/Drawpile/wiki/How-Drawpile-works#undo
The short answer is that actions that are undone should be reapplied. Off hand, since I'm not in front of a computer, I imagine that this might happen when users have bad latency and are undoing an action close to the end of the global stack, possibly pushing the needed redo actions out of the stack as people keep drawing.
I'm not sure there's still a good way to handle this issue, given I'm not a programmer, but I have some ideas I've wanted to run by @callaa at some point. I'll try to post back here later with said ideas.
I've been using Aggie for a while (similar shared drawing pad) and that works pretty nicely for undoing/redoing.
It feels like what they do is something along the lines of:
- Each layer has an owner (one user, they are the only one who can draw/erase on that layer).
- Each layer has a separate undo/redo stack (and the client keeps track of/decides which layer of the current user's owned layers to undo/redo to).
- Each new user that joins gets their own new layer that they are the owner of.
- Users can double-click on unowned layers to become the owner of that layer.
- Drawing admins can assign/unassign/reassign layer owners.
It's a bit less nice than 'everyone draws on the same layer', and ends up with more layers being created, but in terms of undo/redo it definitely ends up feeling nicer for each user.
Aggie is a bad example, doing the one layer per user is the worst solution. Being unable to edit/erase others is crippling in a shared canvas enviroment.
A solution will come without having to compromise functionality, Drawpile is using the simplest solution in Callaa's words.
Totally fair enough, just tossing that in as an example since even though it's a bad solution the way undo/redo works in it acts how people expect a bit more closely.
I've been thinking about this problem. One solution I came up with is that the session history could be split up into concurrent partitions, so that each partition only contains commands that are causally dependent on each other. Each partition would have a bitmap that shows which tiles it touches. When an action is undone, only its partition needs to be reverted and replayed. This would allow disconnected parts of the canvas to be undone independently and each partition to have its own undo stack, effectively. I haven't fully thought this through yet, but the idea seems promising.
(I've taken over development on Drawpile, so I'm going through these tickets and organizing them.)
Drawpile 2.2 will bring the option of making the undo stack bigger, which alleviates the problem of running out to a degree. I can't currently think of a sane way of changing the way undos work without eating up unbounded amounts of memory or removing the ability to collaborate, so for now I'd say that this is intentionally how Drawpile works. There's definitely optimizations that could be done to the undo algorithm though, so I'd say improving that and just letting undos stack up really deep is the way forward.
