Distributed Engineering for Multiple Platforms

The development of the toolkit involved Digital engineering teams worldwide. The intrinsics were developed in California, primarily on

U LTRIX

system-based workstations, by a team of engineers familiar with the

U LTRJX

system. The toolkit was developed in New Hampshire, primarily on VMS system-based workstations, by a team of engineers familiar with the VMS system. As a result, some problems occurred at software integration points. However, the codevelopment effort ensured that the final software provided the same programming interface, with the same quality, on multiple operat­ ing system platforms.

Perf

orma

nce

Performance was the most serious problem encoun­ tered during early implementation. The ftrst inter­ nal field test of the DEC windows software provided fairly complete functionality for the toolkit and the layers below it. However, the DECwindows devel­ opers, including the toolkit team, had devoted nearly all their efforts toward developing the func­ tionality and postponed measuring, examining, and

DECwindows Program

improving performance. Now that we had an exist­ ing collection of applications, serious work could begin on performance.

In the initial measurements of the system's per­ formance against the goals described earlier, even the worst-case goal was missed in man y are:�s. Early investigation also indicated that the performance problem did no r seem to be localized . That is , the problems could not be isolated to a single compo­ nent in the architec ture. Wi th this information, a task force with members from most DECwindows development groups was convened to determine where the performance problems were and what could be done about them.

We quickly learned that we could nor determine where the performance problems were as easily as we could have in the typical engineering environment to which we were accustomed. Our experience was in evaluating isolated layered app lications , such as compilers, and individual primitive operations, such as system calls. How­ ever, the user imerface actions that were being measured involved the issuance of possibly hun­ dreds of X primitives, and the interaction of up to three separate processes (i.e., the application , the X server, and the window man:1ger). Although the usual evalua tion tools were of some help, additional tools were needed.

Existing tools, such as the VAX performance and coverage analyzer on the

VMS

_{system , were used to} locate performance bottlenecks. These tools helped but did not provide the level of improvemems that were necessary. A number of intern:� I tools to :1id in X performance :1nalysis were used to supplement the traditional tools. These X performance tools included :

• An instrumented X server that counted the resources an application requested , such as graphic con texts, windows, and pixmaps • A set of tests that measured the performance of

Xlib primitive calls

• A protocol monitor that recorded the inter­ actions bet ween an application and the X server • A tool that recorded the dynamic memory

allocation of an application

By using these tools on the applications, a large amount of data was collected and evaluated. Some of the more important observations were:

30

• Applications were using more server resources than anticipated. The most common overuse was windows because each user interface object had its own X window. However, application usc of other resources. such as graphic con texts . pix.maps, and fonts was also at a higher level than anticipated.

• Applications were using too much memory. The object-oriented design of the tool kit and the Xtll Style Guide encouraged applications to use hun­ dreds or thousands of widgets, and each widget was then using about 600 by tes of memory. A number of X toolkit intrinsics fea tures, such :1s resource managemenr and translation manage­ men t, also used a large amount of memory. • Application starr-up was slow. Loading the

large p rogramming libraries , connecting to the X server. and creating widgets were some of the princip:�l functions that slowed app lication start-up.

• The Digital X I I server design was opti mized for graphic primitives , e.g., line and text drawing . The performance of these operations \vas ver y good. However, in optimizing the graphics aspect , the design had traded performance in windowing operations, for example, window creation :1nd mapping . The analysis showed that windowing operation performance was impor­ tant throughout much of the direct manipulation style user interface.

• Many context switches existed lx:tween the server and the application during time-critical operations. Even simple applications required the coordinated efforts of the application , a window manager, and a server. Careful analysis and planning were needed to minimize the communication tra tfic and switching among the processes.

• The basic round-trip time between the server and the application using the DECnet transport was higher than an ticipated . This factor increased the need to reduce the amoun t of com­ munication traffic between the application and the server.

Solutions were designed and tasks defined to help fix the problems. Steps were taken in all layers of the architecture ro reduce CPU utilization , memory utilization , and communication traffic. The two most radical design changes were the design and

implementation of both a shared memory transport and gadgets.

Shared memory transports were implemented hy the server groups. The transports significantly lowered the basic round-trip communication time between the application and the server. The toolkit group led the design of gadgets.

Gadgets Given the results of the performance analysis, it became clear that the performance goals would never be met if every user interface object

required irs own X window. We had to significantly

reduce the number of windows without substan­ tially redesigning the application programming interfaces of the intrinsics or toolkit. The perfor­

mance data showed that at least 50 _{percent of the}

widgets created by a typical application consisted of labels, push-buttons, and toggle buttons used in menus and dialog boxes. If we could eliminate the windows for these objects, we would significantly

reduce the number of X windows. The intrinsics

developers proposed a solution that was nor a radical departure from the existing widget model, could be implemented quickly in the intrinsics, and coul.d be taken advantage of easily in applications. The answer was gadgets.

Gadgets are windowless widgets. Prior to gadgets, the lowest level class in the intrinsics was the core class, which contained all the fields necessary to support a windowed widget. Because the too lkit was object-oriented, the intrinsics developers suggested that we break the core class into smaller subclasses that could support generic objects, as well as windowless user interface objects. We defined three classes above the core class:

• The object class contains the base information required to define any type of object in the intrinsics objec t mechanism , which eliminates

the user interface objects restriction.

• The rectangle object class contains the infor­ mation necessary to define a rectangular user interface object, and is used as the superclass for gadgets.

• The window object class contains the remaining

fields from the core class, which are the fields necessary for a windowed user interface object. As a result of these classes, gadgets for labels, push buttons, toggle buttons, and separators were implemented in the toolkit and used by the

Digital Tecbnicaljournal Vol. 2 No. 3 Summer IY'JO

De uelopment of the X UI ]()()/kit

applications. The

X U !

_{roolkit gadget class hierarchy}

is shown in Figure 3. r - - - -,

I

I

I

WINDOW

I

I

OBJECT OBJECT

l..---

EQUIVALENT TO

I

I

_I

CORE CLASS

I

_I

I

RECTANGLE

I

I _OBJECT

I

I

_I

I

L - - - _ _ _ _ _ _

j

LABEL GADGET SEPARATOR

GADGET

PULL DOWN M E N U PUSH B UTTON ENTRY GADGET GADGET

TOGGLE BU TTON

GADGET

Figure 3 X Ul Toolkit Gadget Class Hierarchy Gadgets reduced the number of X windows, reduced the use of application memory, and reduced application start-up time. Although we provided gadget support in the sample X toolkit intrinsics release 3 implementation, the capability was no t documented in the specification because of time constraints. Gadget support is included in the X toolkit inrrinsics release 4 specification, the current X Window System release.

In document dtj v02 03 1990 pdf (Page 31-33)