The Model-View-Controller Architecture - Essentials of Interactive Computer Graphics - page 106

It is important to recognize that the user's asynchronous events are arriving in
between synchronous application timer events. In practice, a user observes an
instantaneous application state (the graphics in the application window) and gen-
erates asynchronous events to alter the application state for the next round of
simulation. For example, a user sees that the HeroBall is about to collide with
another ball and decides to change the HeroBall 's velocity to avoid the colli-
sion. This means that before that synchronous timer update, we must ensure that
all existing asynchronous user events are processed. In addition, the application
should provide continuous feedback to ensure that users are observing an up-to-
date application state. This subtle handling of event arrival and processing order
is not an issue for simple, single-user applications like our ball-shooting program.
On large-scale multi-user networked interactive systems, where input event and
output display latencies may be significant, the UpdateSimulation() function
is often divided into pre-update, update, and post-update.

5.2.2 The View

class CUIDrawArea {
private : An area on application window for drawing. Actual implemenation is API dependent.

public :
void ActivateForDrawing()
// All subsequent Graphics API draw commands will show up in this area

}

Source file. Pseudocode; no
corresponding source file.

class CApplicationView {
private :
CUIDrawArea TargetDrawArea
// An area of the application main window for drawing

public :
void HardwareToModelXform(mousePtInHardware, outputPtForModel)
// transform the input mouse points for the model

void DrawGraphics(ApplicationModel TheModel)
// Set up TargetDrawArea and call TheModel.DrawModel() to draw all balls.

}

Listing 5.2. The view component of the ball-shooting program.