![](bg2.png)
ers is to capture static views of the executed steps
of the algorithm, thus producing an execution history
(S. Douglas and Hundhausen, 1996). Similar to the
way an example might be presented in a textbook, the
state changes of the algorithm’s data structures are
recorded whenever a significant change to the algo-
rithm state happens, and saved for later viewing. This
is a widely used approach in static algorithm anima-
tions which can not be applied to visual simulations.
A static animation is an animation which does not
allow users to perform changes to the input data of
the algorithm. The input data for the animation was
already hard-coded by the author at the creation and
can not be changed (Baker and Kappes, 2008). A vi-
sual simulation, on the other hand, is a dynamic ani-
mation with an underlying real time simulation of the
algorithm or data structures. In contrast to static an-
imations, simulations allow users to change the input
data before or even during the execution of the algo-
rithm and are capable of supporting different levels of
interaction. The static history approach is best suited
for static animations. Each significant change can be
stored as a view in a sequence of views, thus form-
ing an execution history. The user can review pre-
vious steps by navigating through the history. How-
ever, this approach has some disadvantages. Firstly,
it is unsuitable for large animations, as an excessive
amount of memory is needed to store all graphical
primitives used by each view. Secondly, it can not be
used for visual simulations which are dynamic by na-
ture. Playing a simulation backwards for say n steps,
and then playing it forwards n steps might produce
different views not previously recorded, as the user
is allowed to change the input data before each step.
This particularly applies to dynamic data structures,
such as trees. Another popular approach that might
be applied to static animations as well as visual simu-
lations is, to maintain clones of all used (or at least the
last modified) graphical primitives after each step and
store them for later undo. However, this method also
entails two serious drawbacks. Cloning visual objects
slows down the execution of the visualisation, which
can affect the overall performance of the application.
Saving the cloned object after each step might require
an extremely huge amount of memory and can eas-
ily lead to memory overflow, particularly when un-
limited undo is supported. Moreover, system devel-
opers do not explain which technique they utilised to
implement their approach. It seems that each devel-
oper has developed an individual solution that suits
the system architecture being used. Implementation
details are kept concealed. At our Institute of Com-
puter Graphics we are developing a unique approach
to generate three-dimensional visual simulations of
algorithms based on the algorithm source code, al-
most automatically. One of the requirements a gen-
erated simulation needs to satisfy is to provide an un-
limited undo/redo facility. We succeeded in develop-
ing a generic efficient interface that supports our ap-
proach of automation, which we are going to present
in this work. Efficient in this context means fast and
memory-friendly. This has always been considered a
huge challenge in algorithm visualisation systems.
2 UNDO/REDO MODELS AND
DESIGN PATTERN
When we intend to develop a new undo/redo frame-
work, we will need to choose an undo/redo model
(Prakash and Knister, 1994) and an appropriate im-
plementation design pattern (E. Gamma and Vlis-
sides, 1994). To increase the understanding of our
work we will briefly outline the undo/redo models and
design patterns usually utilised when developing an
undo/redo facility.
2.1 Choosing an Undo/Redo Model
Each undo/redo model has a scope which is char-
acterised by four aspects: repetition, granularity,
limit and linearity. Repetition denotes the number
of steps the model allows to be undone. There are
single-undo and multiple-undo. Granularity refers
to the number of actions that can be undone in each
step. There are single-action and multiple-action. As
a consequence of this classification there are 4 dif-
ferent undo/redo-models: single-undo/single-action,
single-undo/multiple-action, multiple-undo/single-
action and multiple-undo/multiple-action. While
most multiple-undo-systems limit the number of
undoable steps, some systems allow an unlimited
undo. The last criterion to classify a model is,
whether it is linear or non-linear. In both models
the undoable steps are maintained in an ordered list.
Linear undo requires the user to undo the latest action
before undoing earlier ones. With non-linear undo,
the action to be undone can be freely picked from
the list. While editors and algorithm visualisation
systems commonly implement a linear model, most
web browsers support non-linear ones. Obviously,
a linear multiple-undo/multiple-action undo/redo
model is from a pedagogical point of view, the
most appropriate model which can be implemented
for algorithm visualisations. Therefore, a linear
multiple-undo/multiple-action model with an un-
limited undo/redo of user interactions underlies the
proposed framework.
AN EFFICIENT UNDO/REDO-FRAMEWORK FOR THREE-DIMENSIONAL VISUAL SIMULATION OF
ALGORITHMS AND DATA STRUCTURES
275