The animation area will display processors, some of their data as specified by the algorithm description, and network communication between processors. For some algorithms, it may be necessary to show I/O. Others may not show data detail but just show when the processor is computing. It is not clear whether the network connections should always be shown; initially we will only show them while communication is taking place.
The control area will have two parts. The first will have parameters that can be changed during the animation. Intially there will be a choice for rate of animation (number of screen refreshes) and for which messages to show. There will be pause and resume buttons. The second part will have parameters that, if changed, the animation should start over. This will be a choice of some small number of pre-defined processor configurations and data sizes. There should be a choice of algorithm rate (ratio of algorithm time to animation time as described below). There will also be a restart button.
The user interface may look something like the following.
(Put picture here.)
The algorithm animation will be specified in an algorithm description that details
The animation should have a single thread to draw in the animation area. Here is an example applet with the basic structure of an animation thread and some controls in a separate applet area. Bounce.java
There are three notions of time. The third is real time, i.e. milliseconds of computation on the browser's machine. The second is animation time. This is the time at which the screen is repainted. The rate of animation is controlled by the amount of time that the run loop sleeps in-between each repaint. Note that animation time can be kept by having paint add one to a time variable each time that it is called. The first notion of time is algorithm time. These are the units of a hypothetical parallel processor computation, expressed as tcalc, the time to do one floating point calculation, and the units of the hypothetical machine communication, expressed as tcomm, the time to transfer one floating pt. number, and tlat, the latency of one communication. So one communication is tlat + M * tcomm, where M is the number of data items transferred, the message size. There is also a ratio of algorithm time to animation time. This will control how many units the animation shows computation and how many positions a message will be shown in during its transfer between processors, according to its described communication time.
For each algorithm, the programmer must translate the algorithm description to a sequence of graphical events with algorithm time, such as display stencil at some location for some amount of time. The description of these events may include loops. Then during the animation the program must translate these graphical events to a sequence of display instructions with an animation time attached. Then each time repaint is called, the paint method can examine this sequence and see what it should display in the current animation time. Note that there may be some notion of objects to display every time (such as processors and data) and objects which are displayed as the animation (such as computation and communication messages).
The data structures to achieve this behavior are yet to be designed and will be part of the intial applet programming.