Event-Driven Programming - Essentials of Interactive Computer Graphics - page 28

corresponding case statements in the control-driven solution presented in List-
ing 1.2 (B1-B3). It should not be surprising that this is so, because we are im-
plementing the exact same user actions based on the same specification. Line 3
of the LMBDownRoutine() (D1L3) demonstrates that when necessary, our ap-
plication can request the GUI system to initiate events. In this case, we signal
the GUI system that an application redraw is necessary. Notice that event ser-
vice routines are simply functions in our program. This means that at D1L3, we
could also call RedrawRoutine() (D7) directly. The difference is that a call to
RedrawRoutine() will force a redraw immediately, while requesting the gener-
ation of a Redraw event allows the GUI system to optimize the number of re-
draws. For example, if the user performs a LMB click and starts dragging imme-
diately, with our D1 and D2 implementation, the GUI system can gather the many
GenerateRedrawEvent requests in a short period of time and only generate one
Redraw event. In this way, we can avoid performing more redraws than necessary.
To achieve a smooth animation, we should perform about 20 to 40 updates per
second. It follows that the SimulationUpdateInterval should be no more than
50 milliseconds so that the ServiceTimer() routine can be invoked more than
20 times per second. (Notice that a Redraw event is requested at the end of the
ServiceTimer() routine.) This means, at the very least, that our application is
guaranteed to receive more than 20 Redraw events in one second. For this reason,
the GenerateRedrawEvent requests in D1 and D2 are really not necessary. The
servicing of our timer events will guarantee us an up-to-date display screen at all
times.
One important lesson to learn here is that we have completed the design of a
solution without mentioning implementation. In later chapters, we will see how
we can map this solution to implementations based on different technologies. The
lesson to learn is to design a solution before coding.

1.7 Summary

In this chapter, we have discussed programming models that are simply strategies
for organizing statements of our program. We have seen that for interactive ap-
plications, in which an application continuously waits and reacts to a user's input
actions, organizing the program statements based on designing control structures
results in complex and inefficient programs. Existing GUI systems analyze all
possible user actions, design control structures to interact with the user, imple-
ment default behaviors for all user actions, and provide this functionality in GUI
APIs. To develop interactive applications, we take advantage of the existing con-