I am looking into how to write a paint program that supports undo and seeing that, most likely, a command pattern is what I want. Something still escapes me, though, and I'm hoping someone can provide a simple answer or confirmation.
Basically, if I am to embody the ability to undo a command, for instance stamping a solid circle on the screen, does this mean I need to essentially copy the frame buffer that the circle covers into memory, into this command object? I don't see any other way of being able to undo what might be, for instance, stamping over a bunch of random pixel colors.
I've heard that one approach is just to keep track of the forward actions and when an undo is performed, you simply start from step 1 and draw forwards to the step before the undo, but this seems unfeasible if you are to support a large undo stack.
Perhaps the solution is something in between where you keep a bitmap of every 15-20 actions and start from the last 'save' forwards.
Can someone provide any insight on what is the typical accepted approach in this case, either saving buffer rectangles in the commands, redo-ing every action forwards, or something I've altogether missed?
Update: Plenty of good responses. Thanks, everyone. I'm thinking from what I'm reading that I will approach this by saving out the buffer every N actions and when the user issues an undo command redo all commands from the most recent saved buffer. I can tweak N to as high a value as possible that doesn't noticeably bog down the user experience of needing responsive undo (in order to minimize memory usage), but I suspect without really knowing for sure at this point, that I should be able to get away with performing quite a few actions in one frame such that this isn't too bad. Hopefully this approach will let me quickly determine whether to turn the other direction and instead go with saving bitmap rects for the previous states for actions that require it.
First, beware overdesign: if your app isn't complex and your images small, you may find 'just store everything' to be quick, cheap and feasible. But assuming that's not so:
You are correct that it is not feasible to redraw the entire canvas from step 1 forward for each undo; unless your paint program is very simple some operations simply take too long. Also, an infinite undo buffer is probably not called for (and could be very space-consuming to store).
If your art program is complex, I'd actually start with a hybrid approach, to deal with the variety of operations. Save frame buffer every so often (the every 15-20 commands you suggest seems OK; I might start with 10 and adjust once I had it working) and go forward from last save. But don't make the 'every 15 operations' rigid, because it is likely that a few extra rules of thumb would make it seem much more fluid to the user.
For example, some time-consuming or tricky-to-reverse operations could always create a new save point:
- Any canvas resize (crop etc.)
- Any save. ("I just saved" is a very likely place for the user to undo back to.)
- Any operation which is extremely time-consuming should create a new save point after, not before, the operation; i.e. it should flag the next operation to save the buffer to undo. (Why? If the op takes 30 seconds, you don't want every undo in the stack afterwards to take an extra 30+ seconds.)
- Conversely, any operation which has an easily performed mathematical negative, or is self-inverting (like photonegative) need never bother to save frame buffer, and shouldn't count towards the next save.
All of this leaves out the question of layers; if your program has them it's obviously sufficient to save only those layers that change.
Definitely my highest-priority suggestion though: regardless of what method you use, you should always save frame buffer for the most recent operation performed. "Whoops, didn't mean that" is the most likely reason for undo, so you always want undo-one-step to be responsive. You can discard this buffer after the next command execution if it's not one you're keeping.
You'll also need to consider what constitutes one atomic undo operation. (For example, is a set of strokes with a single brush tool one operation or many? Both have advantages and drawbacks.)
Perhaps the solution is something in between where you keep a bitmap of every 15-20 actions and start from the last 'save' forwards.
I would go with something like this one. You have to bound your command stack at some point anyway, so you'll need a starting point if the user empties it.
You could get clever and save the buffer when you reach the bound and use that as your save point, since you have to drop a command from the stack anyway. Essentially, your save point buffer is the representation of the dropped actions, so as you're dropping actions from your undo stack, you just write them onto that buffer.
I've heard that one approach is just to keep track of the forward actions and when an undo is performed, you simply start from step 1 and draw forwards to the step before the undo
This isn't a very good idea. Users typically undo only a few recent actions and they expect it to be fast, so it's better to be able to revert immediately than redoing everything from the start.
Can someone provide any insight on what is the typical accepted approach in this case, either saving buffer rectangles in the commands, redo-ing every action forwards, or something I've altogether missed?
You don't have to store all commands in the same way. Depending on the type of operation, you can use one or more techniques, for example:
Drawing/painting operations generally can't be reverted directly, so you have no choice but to save the original image contents. You can however save space by storing only parts of the image that have changed instead of the entire image.
Some operations like inverting colours are inherently invertible, so in such cases, you only need to store the type of operation on the undo stack, and you can replay the operation in either direction.
If you probably won't draw gigantic bitmaps, your approach seems totally ok.
To simplify even more, write whole pictures to tmp directory onto disk, and see what it will be like for the users.
Don't overdesign at start-there are other issues that need to be adressed, no doubt.
From my understanding, the command pattern for implementing undo/redo sorts of systems just record the actions in a stack, not the actual results from those actions (since those will be recreated/removed in sequence). I think you alluded to this, but said you considered it unfeasible for a large undo stack. Can you be more specific? I believe it is possible.
Related
When you are stepping through Swift code in Xcode (9/10?), there is a green bar on the right with something like:
You are supposed to be able to drag the partial-hamburger-menu upwards to rewind the statement pointer to re-run code. However, every time I try it it moves back as expected, but then 100% of the time I step from that point I get:
Is there a trick to this?
You can move the pointer to the next statement to be executed to either a previously executed statement or a not-yet-executed statement, but in order for that to work the stack needs to be in the correct state, and so do the variables in memory.
In my experience, the outcome is usually a crash.
You'd need to drop down to the assembler code and examine it in order to figure out what's really going on, and might need to patch variables and/or the contents of the stack in order for your code to survive the change of program counter. I've never invested the time to try to do that, however. As a result I find the feature pretty much useless, and have given up on it. (I've worked in assembler a LOT in years past, but never learned enough about ARM assembler to be able to read it well, much less hack registers, memory, and the stack to make moving the program counter work.)
I am writing a custom plugin for TinyMCE. One of the new buttons makes a number of DOM manipulations in the document. The default undo behavior creates a few undo levels in the middle of the changes. If the user hits the undo button after using the plugin, he/she then sees a document with the operation partially reversed and really not in a proper state.
It looks like there used to be a pair of instance commands called mceBeginUndoLevel / mceEndUnoLevel (removed in version 3.3) that let a developer start/end a large undo batch that would be undone in a single operation....but I don't see anything in the docs that replaces that feature.
Some forum postings suggest using editor.undoManager.add() as a replacement, and that works for cases where you want more levels of undo during an operation, but I actually want less.
There is also a undoManager.onBeforeAdd event that you can hook into, but looking at the source for the undoManager, I don't think that hooking there will let you abort an undo snapshot.
So, is there a proper way to batch undo operations that I'm not seeing using the existing API? If not, my only other option seems to be patching the undoManager to allow the onBeforeAdd hook to abort a snapshot.
I suggest overwriting the current UndoManager. It is just a rather small file.
That's what we needed to do in order to suppress the creation of some unwanted undosteps.
I created a run loop in OpenGL ES which is called by a CADisplayLink at 60fps. AFAIK CADisplayLink calls it's target on a background thread.
I have about 100 state variables which are used by the run loop.
The problem: From the main thread, I want to change state variables which are used in the run loop to draw something. A frame must be drawn only after all state variables have been set to their target values.
I am afraid that at some point when I change a state variable, and I'm not done yet changing them all (in one big method in same run loop iteration on main thread), for example position of a geometric shape, there is multi-threading related crash or problem where the CADisplayLink will kick in right in the middle of my method that updates the state variables, and then draw garbage or crash.
Obviously when I just use synchronized or atomic properties it won't help because it is still not transactional. I think I need transactions.
My naive approach is this:
Instance variable read by run loop:
BOOL updatingState;
The run loop method will skip drawing if updatingState reads YES.
Then before starting to change state I set it to YES. And when everything is changed, I set it back to NO.
Now of course, problem: What if -while I am changing this- the run loop method is reading the values?
How do game engines deal with this problem? What kind of locking mechanisms do they have so the changing of the state variables can be finished before the next frame is going to be drawn?
You might find a read-copy-update strategy useful. One possible implementation is that each object actually contains two copies of the rendering parameters and an atomic flag is used to tell the rendering thread which to use. You will need to use a read memory barrier in the renderer to make sure that the flag is read before reading any of the parameters and a write memory barrier in the updater thread to make sure that all of the parameter updates are written before flipping the flag.
The usual way how this is done is that all state updates happen at each run loop iteration, before the drawing is done. That is, the run loop looks schematically like this:
updateState();
draw();
With this model, the drawing only happens after the a consistent state has been reached.
For this to work, you need to have a model where events such as key presses are polled for on each updateState() instead of happening asychronously, and a time measurement on each iteration to tell you how much time elapsed since the last frame.
I can't help you how this is realized in the concrete case of iOS programming, though, as I don't know anything about that. But I hope I could point you in the right direction.
I think this is a common problem in concurrency, so there are several ways to do it:
Use an immutable state class to hold the state variables.
Use a locking mechanism (if an immutable class cannot be used) to protect the state variables.
Have multiple states which you can modify, but only one is "active." This will allow you to reuse states and it will reduce copying and memory allocation.
Additionally, consider this situation:
Thread 1. Start drawing something.
Thread 1. Read 1/2 of the state 01 parameters (first state).
Thread 2. Swap out state 01 with state 02 (second state).
Thread 1. Reads the other 1/2 of state 02, but it's different from the state 01 parameters.
So the best option is not to allow the update of the state during the drawing, so option 3 might be the best way to do it because you would simply pick up the latest state and draw it. Let's say you have two states: drawingState and nonDrawingState. In your draw function you will always use the drawingState to draw while other threads modify the nonDrawingState. Once you're done drawing, then you can swap the states and continue drawing with the latest state modifications.
We're repetitively making a CGLayer, doing processing, and then releasing it. This happens a lot in real time. Surely there is a lot of overhead in making a whole new CGLayer each time. So...
Surely it would be better to just keep the layer around, and erase all the data from it each time -- rather than creating a new one from scratch.
Note: if you paint in a blank or clear rectangle covering everything, that just adds even more data on top of your extant paths.
So, how to actually "erase" or "start again" a CGLayer?
There is a function CGContextBeginPath(cc) but it's confusing: it seems to only clear out "that" path, it does not appear to erase all of the CGLayer back to no-data state.
How to return a CGLayer to a state of no-data? Does anyone know?
Update...
It turns out there is actually NO WAY TO DO THIS.
After considerable experimentation, we have determined that there appears to be no way to clear out all the data from a CGLayer (which is disappointing really).
Note that adding a new white or clear rectangle, only does that - it actually adds more data.
So unfortunately no known way to do this. If you are building these at high hz (perhaps for a calculation), you just have to start with a fresh one each time. Or, you can apparently delete (actually delete, not just cover) just the one path using CGContextBeginPath().
Hopefully this will help someone in the future.
Once you have the context call CGContextClearRect( cc, someRect ) to clear the contents.
Why don't you just fill it with a rectangle of (clear/white) color?
Make sure the layer is not opaque if you wanna clear it with clearColor (transparent).
I am creating function (for example) to validate content, then if it is valid, close the view, if it is not, present further instructions to the user. (Or other such actions.) When I go to name it, I find myself wondering, should I call it -doneButtonPressed or -validateViewRepairAndClose? Would it be better to name the method after what UI action calls it, or name it after what it does? Sometimes it seems simple, things like -save are pretty clear cut, other times, and I can't thing of a specific example right off, but I know some have seemed like naming them after what they do is just so long and confusing it seems better to just call them xButtonPressed where x is the word on the button.
It's a huge problem!!! I have lost sleep over this.
Purely FWIW ... my vote is for "theSaveButton" "theButtonAtTheTopRight" "userClickedTheLaunchButton" "doubleClickedOnTheRedBox" and so on.
Generally we name all those routines that way. However .. often I just have them go straight to another routine "launchTheRocket" "saveAFile" and so on.
Has this proved useful? It has because often you want to launch the rocket yourself ... in that case call the launchTheRocket routine, versus the user pressing the button that then launches the rocket. If you want to launch the rocket yourself, and you call userClickedTheLaunchButton, it does not feel right and looks more confusing in the code. (Are you trying to specifically simulate a press on the screen, or?) Debugging and so on is much easier when they are separate, so you know who called what.
It has proved slightly useful for example in gathering statistics. The user has requested a rocket launch 198 times, and overall we've launched the rocket 273 times.
Furthermore -- this may be the clincher -- say from another part of your code you are launching the rocket, using the launch-the-rocket message. It makes it much clearer that you are actually doing that rather than something to do with the button. Conversely the userClickedTheLaunchButton concept could change over time, it might normally launch the rocket but sometimes it might just bring up a message, or who knows what.
Indeed, clicking the button may also trigger ancillary stuff (perhaps an animation or the like) and that's the perfect place to do that, inside 'clickedTheButton', as well as then calling the gutsy function 'launchTheRocket'.
So I actually advocate the third even more ridiculously complicated solution of having separate "userDidThis" functions, and then having separate "startANewGame" functions. Even if that means normally the former does almost nothing, just calling the latter!
BTW another naming option would be combining the two... "topButtonLaunchesRockets" "glowingCubeConnectsSocialWeb" etc.
Finally! Don't forget you might typically set them up as an action, which changes everything stylistically.
[theYellowButton addTarget:.. action:#selector(launchRockets) ..];
[theGreenButton addTarget:.. action:#selector(cleanUpSequence) ..];
[thatAnimatingButtonSallyBuiltForUs addTarget:.. action:#selector(resetAll) ..];
[redGlowingArea addTarget:.. action:#selector(tryGetRatingOnAppStore) ..];
perhaps that's the best way, documentarily wise! This is one of the best questions ever asked on SO, thanks!
I would also go with something along the lines of xButtonPressed: or handleXTap: and then call another method from within the handler.
- (IBAction)handleDoneTap:(id)sender {
[self closeView];
}
- (void)closeView {
if ([self validate]) {
// save and close
}
else {
// display error information
}
}