Graphics Reference
In-Depth Information
When we examine this solution in the context of supporting user interaction,
we have to concern ourselves with efficiency issues as well as the potential for
increased complexity.
Efficiency concerns.
Typically a user interacts with an application in bursts of
activity. These are continuous actions followed by periods of idling. This can be
explained by the fact that as users, we typically perform some tasks in the applica-
tion and then spend time examining the results. For example, when working with
a word processor, our typical work pattern consists of bursts of typing/editing
followed by periods of reading (with no input action). In our example applica-
tion, we can expect the user to drag out some circles and then observe the free
falling of the circles. The continuous while-loop polling of user commands in
the
main()
function means that when the user is not performing any action, our
program will still be actively running and wasting machine resources. During ac-
tivity bursts, at the maximum, users are capable of generating hundreds of input
actions per second (e.g., mouse-pixel movements). If we compare this rate to the
typical CPU instruction capacities that are measured at 10
9
per second, the huge
discrepancy indicates that, even during activity bursts, the user command-parsing
switch statement (B) is spending most of the time in the default case not doing
anything.
Complexity concerns.
Notice that our
entire solution
is in the
main()
func-
tion. This means that all relevant user actions must be parsed and handled by the
user command-parsing switch statement (B). In a modern multiprogram shared-
window environment, many actions performed by users are not application-
specific. For example, if a user performs a left mouse-button click and drag in
the drawing area of the program window, our application should react by drag-
ging out a new
HeroBall
. However, if the user performs the same actions in
the title area of the program window, our application must somehow implement
moving the entire program window. As experienced users in window environ-
ments, we understand that there are numerous such operations, and we expect all
applications to honor these actions (e.g., iconize, resize, raise or lower a window).
Following the solution given in Listing 1.2, for every user action that we want to
honor, we must include a matching supporting case in the parsing switch state-
ment (B). This requirement quickly increases the complexity of our solution and
becomes a burden to implementing any interactive applications.
To support the development of efficient interactive applications, we need sys-
tem support where we could remain idle by default (not taking up machine re-
sources) and only become active in the presence of interesting activities (e.g.,
Search WWH ::
Custom Search