Re: Multiple Undo devours RAM
Re: Multiple Undo devours RAM
- Subject: Re: Multiple Undo devours RAM
- From: Erez Anzel <email@hidden>
- Date: Sat, 31 Jan 2004 14:00:56 -0500
Thanks, Public (?). I basically agree: I'll have to store my Undo data
more efficiently. I will respond to your specific suggestions here, and
get into details in the thread "Designing for multitudinous objects". I
just had difficulty with your last paragraph; I ask my question below.
Back in the earlier MacApp days, if I remember correctly, I did it the
way that you mentioned that you did it: I would store a command, and
the Undo or Redo would apply to the current selection. In my simple
approach (for a simple app), there wasn't an Undo stack in the same
sense. Each object stored not only its current state (color, position,
etc.), but also its previous state. Undo/Redo would simply toggle back
and forth. This obviously did not allow for multiple Undo, but it sure
was simple.
I also appreciate the importance of storing selection changes as
Undoable, so that's something I currently do.
I'm not sure if I understood your last point correctly; please correct
me if I am wrong. You stated:
>
One final trick is to treat objects deletions as just another kind of
>
selection change. The deleted objects are retained in the undo record
>
for the selection change even when removed for the document proper.
>
When the undo record goes away either because of redo or because the
>
user cleared the undo stack, everything gets cleaned up nicely.
I assume that you are referring to something which I already do. A
typical scenario might be that the user selects some data (first
Undoable action), deletes that data (second Undoable action), and
performs some third Undoable action. When the user deletes, the objects
go into the Undo stack (and are thereby retained), and are removed from
my document's model (i.e. removed from my NSMutableArray, and thereby
released). When the stack gets cleared (such as when saving or closing
the document), the deleted objects are released when the stack is
cleared.
Bye...Erez
On 27-Jan-04, at 5:46 PM, Public Look wrote:
>
On Jan 26, 2004, at 8:22 PM, Erez Anzel wrote:
>
>
[snip]
>
>
>
>
> I figure that instead of storing the Undo and Redo stacks in memory,
>
> as
>
> is currently done, perhaps theres a means of writing them out to
>
> disk.
>
> There would be some overhead for each operation, obviously. Perhaps
>
> this could be an option for the user. Or perhaps the hard drive is
>
> used
>
> if real RAM starts getting tight, so as to avoid getting bogged down
>
> with virtual memory.
>
>
[snip]
>
>
In my experience, you should just let the virtual memory system do its
>
thing. It is most likely better at deciding when to transition from
>
RAM storage to disk storage and back, it requires no special
>
programming effort, and it follows the fastest possible I/O bath
>
through the system. The better answer for you is to store your undo
>
data more efficiently.
>
>
In a high end CAD like application that my company made, the solution
>
was to treat changes of selection as undo events and only store
>
"operations" with the knowledge that they implicitly apply on the
>
(current) selection. Lots of information gets saved with selection
>
changes, but they are infrequent compared to moves etc.
>
>
operation 0: select 500 objects containing 50,000 points
>
operation 1: move selection 150, -60
>
operation 2: move selection 0, 1
>
operation 3: move selection 0, 1
>
operation 4: select 700 objects
>
operation 5: set selection color red
>
operation 6: set selection color blue
>
>
As an added bonus, our users liked being able to undo selection
>
changes. It was common for users to accidently select or deselect
>
points due to clutter and sloppiness, but there was no harm done.
>
Just undo :) We also let them save selections in a list with user
>
specified names so they could get back to a favorite selection like
>
"objects in layers 5,6,8 except master points" at any time.
>
>
One final trick is to treat objects deletions as just another kind of
>
selection change. The deleted objects are retained in the undo record
>
for the selection change even when removed for the document proper.
>
When the undo record goes away either because of redo or because the
>
user cleared the undo stack, everything gets cleaned up nicely.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.