\def\im{.}
\lefthead{Dellinger}
\righthead{Vplot}
\footer{SEP--61}
\title{Why does SEP still use Vplot?}
\author{Joe Dellinger}

\ABS
{
Vplot is SEP's ``home-brew'' plotting system.
Ten years after its creation, SEP continues to use Vplot
even though Vplot is not suited for interactive plotting.
Many better-written commercial and academic packages are now available,
but SEP has not switched yet because these packages fail
to provide certain critical
capabilities needed by researchers:
\begin{itemize}
\item{Ability to run on many machines}
\item{Complete set of graphics primitives}
\item{Virtual device concept}
\item{Ability to plot well on many devices}
\item{Batch-mode manipulation}
\end{itemize}
The relative strengths and weaknesses of Vplot and current ``window''
systems are based upon their differing aims. Vplot attempts to be
a good system for archiving important plots; it is meant for
making static figures that will go into papers or onto slides.
Current window systems are designed as a base for interactive
application programs.
Both sorts of capabilities are needed by researchers.
}
\mhead{INTRODUCTION: WHAT IS VPLOT?}
\shead{Basic structure}
Vplot is a graphics driver system that allows graphics applications
programs to plot on a wide range of graphics devices with little effort.
It was intended from its inception as a ``hardcopy'' language. Although
it supports many screen-based devices, it is not suited to interactive
graphics.

Vplot has three components.
\begin{list}{}{}
\item[(1.)]
Vplot metafiles.
Vplot metafiles contain encoded descriptions
of what is to be plotted.
\item[(2.)]
``Pen filter'' programs.
Pen filters are the device-specific part of Vplot;
they accept as input a Vplot
metafile, interpret the encoded graphics commands in it, and
create the desired plot on a particular graphics output device.
\item[(3.)]
A subroutine library, {\it libvplot}.
When a user program calls a libvplot subroutine to draw something,
the subroutine writes out the corresponding Vplot metafile command.
\end{list}

Note that Vplot is based on the Unix ``pipe'' concept,

\verb+program | pen (| device)+,

\noindent which means the data flow
from user program to graphics driver is necessarily one-way.
The graphics
driver can not communicate back to the user program, so Vplot cannot be
interactive. This excludes Vplot from a broad class of possible uses.

\shead{Historical limitations}
Vplot was created at SEP over ten years ago.
Because it has evolved
over generations of students instead of being
designed in a unified grand vision,
some parts of the code are not as well-structured or
well-written as they ought to be.
All extensions to Vplot have had to remain backwards
compatible to the original definition, which while advanced for
the time was certainly not optimal.
Vplot is not particularly widely
distributed (perhaps a hundred sites or so currently use it).
\mhead{PHILOSOPHY OF VPLOT}

SEP makes hundreds of figures in each project report,
most of them using Vplot.
For every hardcopy plot in a report,
dozens of screen versions of the same image are made, also using vplot.
Given that Vplot is a home-grown non-interactive kluge,
why should SEP still use it? The reason is that although Vplot is indeed
limited, it serves the needs of a research environment reasonably
well.
What does SEP like about Vplot?

\shead{Ability to run on many machines}
One advantage of using UNIX is that it does not tie you to a particular
vendor. Similarly, one also does not wish to use a graphics system that is
tied to one specific platform. UNIX is widespread, which enables
programs written to run under UNIX to be widely used.
Similarly, if you want other scientists to be able to use your
graphics programs,
they will need the underlying graphics system on their machine too.
In the absence of a standard like Unix,
the surest way to accomplish this is to have portable freely redistributable
source code available that is not hardware-dependent.
If the graphics system is needed on another machine,
ideally you can simply copy the source over
and compile it.

This rules out standard commercial packages, who want lots of money
for the privilege of letting you use the software wherever you need to,
and then won't even allow access to the source code. (This may be changing;
recently companies are beginning to realize that it may be in their
own interest to release their software in the hopes that it becomes
a standard. For example, Adobe recently made public
previously closely-guarded proprietary details about its fonts.)

\shead{Complete set of graphics primitives}

A good graphics system ought to recognize all the standard
kinds of graphics primitives, loosely categorized here
as vector, text, filled area, and raster. (See Figure~\ref{example}
for an example.)
\plottop{example}{3.5in}{./example}
{
A typical plot from Claerbout's new book, with square-boxed annotation
added to point out how the four basic graphical primitives (vector, text,
filled area, and raster) are used.
}

Almost all graphical systems handle vector primitives
such as lines or curves quite well; they would hardly
be usable if they didn't.
Most graphical systems also support a few kinds of
filled-area objects, such as solidly shaded polygons
and hatched polygons.
Vector and filled-area objects are normally allowed to have arbitrary sizes
and shapes.

Unfortunately many graphics systems stop there;
text primitives are allowed, but only in a limited number of fonts,
sizes, and orientations.
Few graphical systems support raster primitives at all, and those that do
usually require the raster to be specified in terms of the output
device's hardware pixels.
Text and raster must stretch and rotate
the same way as vectors and filled areas.
Being able to resize plots arbitrarily is a basic
requirement of any graphical system used for serious research.
If all of the graphical primitives making
up a plot cannot be scaled and stretched together,
the plot as a whole cannot be scaled or stretched.

The obvious reason for needing to scale plots is so
they can be made just the right size to fit into a report.
A less obvious but equally important reason is so that
{\it arrays} of plots can be made.
Researchers make plot arrays to compare
some data before and after processing, to show the effects
of changing the value of some parameter, or just to show
the same data two different ways. (Figure~\ref{example}
is an example of this last kind of plot array.)

\shead{Virtual device concept}

There are three basic strategies to dealing with the wide array
of graphics hardware available. The first is to give up and
only support a limited set of devices. For example, the ``X'' window
system is only meant to run on pixel-oriented devices.
The second is to inform the applications program of the capabilities
of the current device, and require that it adjust its behavior
to fit. For example, the ``X'' window system has several different
possible ``color models'';
X tells the program which ones apply to the device in use, and it
is up to the program to make sure to use the right one.
The third strategy is for the graphics system to simulate
in software as best it can
any capabilities the applications program needs that the device lacks.
This is the ``virtual device'' approach. Postscript is the most
well-known system that follows this strategy.

Unfortunately, most current window systems use the second approach;
if this approach is taken, any static
record of the commands used to generate a given plot
will necessarily be device-specific. A metafile recording
the Suntools commands used to make a plot on a color sun
will not work on a monochrome one.
Even worse, in my experience most researchers are simply too
lazy to write (or debug) fully general
programs, and instead will support only the capabilities
of the particular device they happen to have on their desk.

Vplot uses the third strategy. The vplot metafile format
defines a virtual device. This ``graphical output device''
has (nearly) unlimited resolution, and supports all the graphics
primitives in vplot to the fullest extent possible.

When a vplot metafile is fed into a pen filter, it describes
what it wants plotted on the virtual ``vplot device''.
It is up to pen filter to do its best to comply on the actual
output device being used.

For example, suppose the vplot metafile asks the pen filter to draw color
raster, but the output device is a Tektronix 4014-compatible terminal.
(There are a {\it lot} of these terminals about, and given how they last,
they will be in use for many years to come.)
Tek 4014 terminals are monochrome, and only know how to draw dots and lines.
The pen filter does not shirk from the task;
it first interpolates the requested raster
to the device's resolution, converting it from color to grey-level
as it does so. It then dithers the resulting raster, so that while
each pixel is either black or white the plot as a whole
appears to have the correct shades of grey.
Finally, it breaks
the resulting block of pixels into as small a number of vectors
and dots as possible and sends them to the device, using all the
Tek 4014-language compression techniques it can.

This philosophy is the most device-independent, since it makes
all devices look the same to the user's program, and allows the
same metafile to work with any device. The user should not have to
debug his program or his plot on each kind of device. The author of
the graphics system should solve these problems once and for all.

\shead{Ability to plot on many devices}
Most research groups cannot afford to buy the latest fancy workstation
to put on everybody's desk; cheap dumb terminals will be around a long
time. For this reason it is important for any graphics system to
allow for supporting all kinds of devices easily.

Vplot uses a ``layered subroutines'' structure.
At the top level, there is one subroutine
for each basic kind of graphics primitive and control function.
If the device can handle fat dashed lines with hardware
clipping, for example, a device-dependent subroutine to handle
vectors would be written to connect in at the top level.
If the device cannot handle such complicated objects, an
appropriate ``generic'' routine can be linked in instead. A
generic routine accepts a complicated graphics primitive and
``digests it'' into simpler ones.
For example, a generic routine could accept requests for
fat dashed lines requiring clipping, and output a
set of requests that draws the same thing but contains
only thin solid lines that don't need to be clipped.
Using this structure, devices of all types and levels of
sophistication can be supported with a minimum of coding.

\shead{Batch-mode figure manipulation}
SEP has some programs for interactive manipulation of Vplot metafiles,
but they don't get used much.
Instead of a complex manipulation done on a single metafile,
researchers more often need a simple manipulation performed again
and again on many similar metafiles.
This sort of manipulation is best done in ``batch'' mode.

The sorts of simple manipulations most needed are:
\begin{itemize}
\item{Sizing}

It is important to be able to resize a plot arbitrarily so that
it is exactly the desired size.
\item{Positioning}

Mostly this is automatic left-justification or centering of a plot
without otherwise changing it. This is used at SEP
to make plots suitable
for automatic inclusion into {\TeX} documents. It is also useful
to be able to shift a plot some arbitrary amount
to touch up the positioning, or to overlay plots produced
by different programs.
\item{Editing text}

It is useful to be able to change one label without having to
edit the entire plot. Another useful feature is to be able to magnify
all text by some amount.
\item{Changing global attributes}

The most important global attribute is to make the entire plot
drawn ``fatter'' so lines stand out from the page more. Other
important ones are text font, background color, raster polarity,
whether to skip shading filled areas or not, and whether to skip drawing
raster blocks or not. (These last two are useful for getting a
crude version of a plot out quickly.)
\item{Plot arrays}

The single most useful non-trivial manipulation is to
combine groups of plots into arrays.
\end{itemize}
\mhead{STATIC VERSUS DYNAMIC PLOTTING}
There are two broad classes of plotting,
dynamic and static.

A dynamic plot is malleable, meant to be interacted with and
changeable by the user. A dynamic plot must have a running program
of some sort behind it, ready to update parts of the plot as they
are changed. For example, we might plot a seismic section on a screen,
and then overlay hyperbolas on it. As we move the mouse around,
the overlayed hyperbola changes position under the control of
a running program.

A static plot, on the other hand, is unchanging by nature. Static plots
are what we tack onto the wall, publish in SEP reports, project
with slide projectors, and look at on our terminal screens to
see how our inversion program worked.
80\% of what we do is screen static plotting; we usually
just want to throw
something up and look at it. We don't need or want to modify it
interactively, because to change the parameters we are investigating
requires rerunning a program that takes 10 hours of CPU time.

A good graphics system ought to do both dynamic and static plotting
well, but the requirements are quite different.

For dynamic plotting, speed is the most important factor.
Graphics systems should make clever use of device-dependent capabilities
such as overlay planes, bit blits, and hardware zoom to increase
plotting speed. Calculations should be performed in the device's
physical pixel coordinate system whenever possible.

For static plotting, device-independence is the most important factor.
This requires keeping all the resolution present in the
original floating-point calculations in the user's program, and
doing things in as device-independent a way as possible.
We can't know what sorts of devices we will want to later reproduce
plots on; they may be quite different from the device we used to view
the original. In particular,
typical hardcopy devices
like laser printers have much higher resolution
than typical interactive devices
like Sun workstations. Furthermore, many hardcopy devices are vector
and text oriented, while most interactive
devices are raster or polygon oriented.

Window systems like X and Suntools were designed with interactive
plotting in mind, with no provision for
keeping track of the original user coordinates.
All one can do to make a hardcopy is to dump the pixels on the screen
to a laser printer. The resulting plots have much cruder resolution than
is possible on a laser printer, say 100 dots per inch instead of 300.
Furthermore, all information about the distinct elements that made
up the original plot is lost in the rasterization.

\shead{Dynamic {\it and}\/ static}

Until the last year and a half or so, almost all of the graphics
programming at SEP has been static-plotting oriented.
Vplot has been good for this sort of plotting from the beginning,
which is why Vplot has been popular at SEP.

Recently SEP has started feeling the limitations of Vplot,
and has started branching into dynamic-oriented programming.
Despite this trend, however,
the recent batch of interactive programs created at SEP
just haven't caught on.
Why? One difficulty has been getting the advantages of
interactive programming without losing the advantages we
are used to with Vplot.

In the ideal windowing system, all graphical
objects would be manipulated by user programs
as if the screen and all objects on it
had infinite resolution; the window system would worry about how to
represent the objects at the physical resolution of the screen.
The window system
would also keep track of everything necessary to reconstruct
the current image at the original floating-point resolution.

The natural evolution of things seems to be pushing SEP towards a
triple-layered graphics system:
\begin{list}{}{}
\item[(Layer 3.)]
A portable device-independent but hardware-sensitive
primitive window system. By ``device independent'',
I mean something like ``X'' which presents a standard interface
across many devices.
By ``hardware sensitive'', I mean that some details of how
this standard interface works may depend on the particular device.
This layer is responsible
for talking to the graphics device, catching mouse events, etc.
The user program would not talk to this layer directly.
\item[(Layer 2.)]
A static plotting language which is invoked whenever the user
wants to save permanently the results of his work to a metafile
or hardcopy device.
The user program would not talk to this layer directly, either.
\item[(Layer 1.)]
An infinite-resolution graphics system running on top of
Layers 3 and 2, with the user program running on top of {\it it}.
This top-level graphics system accepts
commands with floating-point resolution, and translates
them into the hardware pixel units required by the window system in Layer 3.
It also keeps track of all the objects on the screen and knows
how to recover the original floating-point coordinates for them,
so it is prepared to use Layer 2 to create a metafile snapshot
of any graphical objects on the screen at any time.
\end{list}

At SEP we currently have two different tentative incarnations of just
such a hybrid system.
One is Dave Nichols' modified version of the window system InterViews, in which
Layer 3 is the X window system from MIT, Layer 2 is Vplot, and
Layer 1 is the Stanford X-toolkit InterViews.
The other system is Claerbout's home-grown ``GI'', in which
Layer 3 is either X or Suntools,
Layer 2 is Vplot,
and Layer 1 is the ``GI subroutine library''.

My best guess for SEP's plotting package in 1993, if it isn't home
grown, would be either Sun's NeWS system or some public version of
Display Postscript for Layer 3, Postscript for Layer 2,
and a much-improved Interviews for Layer 1.
(This scenario requires that either somebody invent a system
for plotting Postscript on any device, or that all hardware manufacturers
adopt Postscript as THE standard. Unfortunately, I have learned
through experience to be cynical about the quality of the hardwired
software that comes with graphics devices, especially ones at the
``cutting edge''.)
\CON
Vplot should have died out years ago at SEP, but has not.
Partly this is just inertia, but mostly it is because
no suitable successor to fill its role has yet emerged.
SEP still uses Vplot because it is the only system we know of that is
portable, device-independent, and good for archiving plots.

These advantages of Vplot define only a small part
of what would make ``the ideal graphics system''.
In my opinion, the ideal graphics system should:
\begin{enumerate}
\item
be widely available, portable, and ``standard'',
\item
be fast and efficient,
\item
support a broad range of graphical primitives,
\item
support a broad range of devices,
\item
present a uniform hardware-insensitive interface,
\item
keep track of objects in multiple arbitrary user-defined coordinate systems,
\item
allow simple interactive manipulation of compound graphical objects,
\item
have a toolbox of batch manipulation utilities and
allow new specialized ones to be easily written,
\item
be able to archive plots at full user-coordinate precision, and
\item
have a method of plotting archived plots on any device.
\end{enumerate}
\ACK
I wish to thank Jon Claerbout,
Dave Nichols, Rick Ottolini, Mike Teemann, John Interrante,
Scott Seligman, and Peter Deutsch for explaining to me their various
points of view.
\REF
\reference{Cole, S., and Dellinger, J., 1989, Vplot: SEP's plot language:
SEP--{\bf 60}, 349--389.}
\reference{Claerbout, J., 1989, Interface for system independent plotting:
SEP--{\bf 60}, 391--412.}
\reference{Dulac, J., Nichols, D., and van Trier, J., 1988, An introduction
to InterViews: SEP--{\bf 59}, 217--222.}
\reference{Linton, M., and Calder, P., 1987, The design and implementation
of InterViews: {\it in} Proceedings of the USENIX C++ Workshop, Santa Fe,
NM, 256-267.}
\reference{Nye, A., 1989, Xlib Programming Manual for Version 11,
O'Reilly \& Associates, Inc.}