Service Manuals, User Guides, Schematic Diagrams or docs for : xerox parc techReports CSL-73-4_Omnigraph_Simple_Terminal-Indepenent_Graphics_Software
<< Back | HomeMost service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.
Image preview - the first page of the document
>> Download CSL-73-4_Omnigraph_Simple_Terminal-Indepenent_Graphics_Software documenatation <<
Text preview - extract from the document
\
\ \
\
\
OMNIGRAPH: SIMPLE TERMINAL-
INDEPENDENT GRAPHICS SOFTWARE
BY ROBERT F. SPROULL
CSL 73-4 DECEMBER 10,1973
This paper describes a graphics subroutine package for driving a number of
different display devices with any of three different programming
languages. The Omnigraah system is designed for routine graphics
appl ications, not for high-performance terminals. The success of the
design is largely due to the modest aims of the routines and to the
particularly simple framework chosen for the graphics facilities.
The paper cites a number of design errors in the initial Omnigraph
routines, and suggests improvements. The Omnigraph Reference Manual is
reprinted as an appendix.
XEROX
PALO ALTO RESEARCH CENTER
3180 PORTER DRIVE/PALO ALTO/CALIFORNIA 94304
1
I. INTRODUCTION
The rapid development of low cost graphics terminals has created a new
customer for computer services who wants to view simple drawings or graphs
resulting from computer calculations. He is not an accomplished graphics
programmer and has probably never heard of Sketchpad; he attaches his
terminal to whatever computer resources can be found, preferably
timesharing services; his favorite programming language, if he is a
programmer, is doubtless FORTRAN. In short, this new user is nei ther
prepared to undertake construction of a graphics programming system nor
willing to devote time to issues tangential to his application.
Such a user often relies on "graphics subroutine packages" provided by
terminal manufacturers. This software presents speCial disadvantages both
to the user and to the computer facility which must support it.
The user suffers because the software is often poorly designed and
documented. None of the software aids in minimizing the number of
annoying and time-consuming screen erasures on storage-tube terminals; it
often fails to provide even rudimentary graphical operators such as
coordinate transformation and windowing; and furthermore, it is frequently
riddled with idiosyncratic features, such as curve-drawing capabilities,
that are unique to the terminal. Thus, in many ways the deSign of the
software needlessly obscures the basic simplicity of creating drawings.
Even when subroutine packages are thoughtfully designed, they are still
troublesome to the computer facility. The staff must support many
different subroutine sets, one for each different terminal or different
progranuning language desired by users. Users of different kinds of
terminals cannot share programs; programs written for one terminal require
alterations to use another. Similarly. the computer facility is hampered
in providing graphics services, such as graph-plotting, on many different
terminals because a separate program is required for each terminal. For
the same reasons, re-programming efforts are required whenever a user
decides to discard one terminal and rent another different one.
The Omnigraph display routines, implemented on a PDP-10 timesharing system
at the Computer Center of the National Institutes of Health, are designed
to solve these problems. They provide modest graphical services for
several terminal devices, and can be used with three programming languages
(SAIL, LISP 1.6, FORTRAN). From the user's viewpoint, the Omnigraph
routines are almost terminal-independent: the programmer is not concerned
with the intricacies of driving particular terminals.
The Omnigraph routines drive specific terminals from information provided
by the user's terminal-independent subroutine calls. Presently, a DEC 340
2
refresh display, and Ards, Tektronix 4010 and Computek 400 storage-tube
terminals are supported; programs for Adage AGT-30, IMLAC PDS-l and DEC
GT-40 displays are being designed. Many portions of the Omnigraph
software are identical for all terminals; less than lO% is actually
terminal-dependent.
The routines are deliberately designed to be a less-than-high-performance
graphical programming system. They are thus matched to the moderate
abilities of low-cost graphics terminals and to the modest graphical tasks
undertaken by typical users.
3
II. OUTLINE OF OMNIGRAPH ROUTINES
The paragraphs below briefly describe the facilities of the Omnigraph
routines; more detail is presented in tutorial, reference, and
implementation manuals [1]. Several of the concepts presented here are
mandatory for a graphics system of this kind; others are necessary to
establish a common vocabulary for all terminals.
Classification of the system. The Omnigraph system can best be
characterized in terms of the model of a general-purpose graphics system
presen ted in [2] (page 388; also see Figure 1). Omn igraph omi ts the
structured picture definition; the Omnigraph facilities are used to create
a 'transformed segmented display fiie.' All coordinate transformations are
performed prior to generation of the display file. The file is used to
refresh the display or (in the case of storage-tubes) to send appropriate
commands to the terminal in order to generate the display.
Terminal selection. Selection of the display terminal to be driven is
delayed until program-execution time. An initialization call loads the
device-dependent portion of the Omnigraph routines for the specified
display into a reserved space: all subsequent subroutine calls are
dispatched to these routines. This feature allows one execution module to
be used with any terminal supported by the Omnigraph routines.
The DINI call only loads device-dependent routines; the calls DGET and
DREL are used to sieze or relase the display hardware. This permits the
program to relinquish the display to others when the user does not need to
see the picture, such as during a long computation. All Omnigraph calls
still o~erate correctly, building or modifying pieces of the display file.
When the display is next seized, the results of the c◦ Jabse Service Manual Search 2024 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo