Graphics Reference
In-Depth Information
9
10
11
12
DrawLine ( Appearance=BundleDASHB,
PtStart = (x2,y2), PtEnd = (x3,y3) );
DrawLine ( Appearance=BundleSOLIDB,
PtStart = (x3,y3), PtEnd = (x4,y4) );
The use of the state-machine strategy is natural for IM platforms, since the
goal is to represent the underlying graphics hardware as closely as possible. This
strategy has both pros and cons. The advantages include being more concise and
supporting control over subordinate modules. Consider a function that draws a
dashed triangle:
1
2
3
4
5
6
7
function DrawDashedTriangle (pt1,pt2,p3)
{
SetState( LineStyle, DASHED );
DrawLine( PtStart=pt1, PtStart=p2 );
DrawLine( PtStart=pt2, PtStart=p3 );
DrawLine( PtStart=pt3, PtStart=p1 );
}
What color will the generated triangle be? Since the function controls only
the line style, the color is unspecified and depends on the state when control is
passed to the function. This has advantages (the caller can control the subordi-
nate's behavior, and the subordinate can produce a greater variety of effects by
allowing this control). However, it also has disadvantages: The effect of the func-
tion is not fully defined, and debugging unexpected output is difficult because the
programmer has to trace backward through the execution flow to the most recent
settings of the relevant attributes.
This uncertainty of behavior is actually bidirectional, since subordinate func-
tions are not isolated and can inadvertently produce side effects that damage the
caller's behavior. Our function
DrawDashedTriangle
changes the line-style state
variable, and thus can have an impact on the caller's behavior and on logic that
executes subsequently. The effect will persist until the next explicit setting of the
line style. To avoid side effects, each function that changes state should bear the
responsibility of restoring state before it returns, as illustrated here in pseudocode:
1
2
3
4
5
6
7
function DrawDashedTriangle (pt1,pt2,p3)
{
PushAttributeState();
SetState( LineStyle, DASHED );
...
PopAttributeState();
}
Clearly, unless constructed with such protocols to reduce/eliminate side
effects, an application built on a state-based platform can produce unintended
behaviors that can be difficult to diagnose, so programmer discipline is crucial.
In a typical OpenGL application, the program's main function will start by
initializing the pipeline, specifying the screen/window location of the
viewport
(as in WPF, the rectangular area on the output device in which the scene will be
rendered), setting up camera and lighting characteristics, loading or calculating
meshes and textures, setting up event handlers, and finally passing control to
