Editing Graphics development with vplot (section)

==Being efficient==
Nobody likes waiting for plots. In order to make your Vplot pen filter
pleasant to use, you should consider what you can do to make the plot come
out as fast as possible for the kinds of plots you make most often.
The first thing you have to ask yourself is what is the limiting factor
likely to be for each kind of object you typically draw?

The answers I usually get, in order of importance, are:

# The communication link between the device and the host computer
# The device's speed at plotting
# Your time as a programmer
# The host computer's speed at calculating

Let's go through these point by point.

1) My experience is that whenever you have a tty line between the computer
and a device, that is the weakest link. This means you should put some
effort into making the output data stream as parsimonious as possible.

Here are some ideas about what you can do:

FASTER LINK:
Usually the most helpful thing to do is to simply get a faster
communication channel! Ethernets are better than AppleTalk Networks are
better than fast tty lines are better than slow tty lines...

COORDINATES:
Many devices will let you pick the coordinate system you want to work in.
You should try to pick a coordinate system in which the coordinates are
as short to represent as possible. Usually this means one integer unit for
each pixel on the screen, but not always.

CLIPPING:
Sometimes it is better to let Vplot do the clipping for the device, even
if the device can clip efficiently in hardware. You don't want to spend
your time waiting while graphical objects are being laboriously transmitted
to the device, which then takes one look at them and throws them all away.

MACROS:
Some devices let you define your own commands to use when talking to the
device. Use this to make new commands better tailored to what you want
than the primitives that come with the language.

RASTER:
Let the device do dithering and pixel replication on board, if possible.
This is especially important if your raster plots normally have less
resolution than the device you output them on.

VECTORS:
Most devices have some alternative to simply always drawing vectors.
Moves and draws are almost always better to use than vectors because
most of the time you draw CURVES rather than unconnected line segments
(Move-draw-draw-draw-... versus Move-draw - Move-draw - Move-draw - ...).
If you don't want to use genvector you should at least examine it as
a starting point because it does several sorts of tricky things to try
to be efficient.

Once you've got the vectors processed into moves and draws, most devices
will further allow various sorts of compaction. A favorite one is
"relative moves and draws", where you give the offset from one point
to the next rather than always specifying the complete global position
of every point. Many devices have a "Tektronix emulation mode" which
may be worthwhile to look into using for drawing vectors because Tektronix
has a particularly good scheme for encoding coordinates into a minimal
number of bytes. (Of course, if there is no way to escape out of Tektronix
mode so you can plot things besides vectors on the same plot this is useless.)

Some devices will let you link together strings of vectors into "paths".
This is just "move-draw-draw-draw-..." under a different name.

It is usually worth it to do fattening and dashing in hardware when possible.

TEXT:
Although vector text is more flexible and predictable, hardware text is
usually MUCH faster than vector text, and hence should be made the default
whenever possible. Hardware text usually looks better, too.

POLYGONS:
Hardware polygons are usually much faster than any software attempt at
filling polygons with vectors.


2) Watch out for semi-buggy devices. By "semi-buggy" I mean that in certain
special cases the device will take an exceptionally long time to produce
the correct result (or if the device is simply "buggy" an incorrect result,
or nothing at all). You want to avoid such problems if you can.

Typical causes of such problems: 

* Drawing the vertices of a polygon in the "wrong" direction.
* Filling a polygon that is "too long and skinny".
* Filling a polygon with "too complicated" a fill pattern.
* Filling a polygon that doesn't end on the same point it started.
* Filling a polygon that does end on the same point it started.
* Doing "too many" draws in a row without a move.
* Hitting the same point several times in the same set of moves and draws.
* Drawing "too near" the edge of the page.
* Drawing lines "too close" together.
* Drawing "too complicated" a plot.
* Trying to use the machine immediately after somebody else's job on it has bombed.
* Having 2 computers try to talk to the same machine at the same time.
* Processing "too many" jobs without powering off and on the machine.
* Trying to do things that are more complicated than the simple examples in the documentation.
* Trying to use the device at its rated baud rate.

Sometimes you can get around these problems in software, by checking for
these situations and having a special case to get around them. Sometimes
yelling loudly at the company that makes the equipment works, too, but
usually not.

Don't expect that it is always faster to do something in hardware, even when
it is "working perfectly". On some brands of terminals filling polygons
by drawing vectors is actually FASTER than using the hardware polygon filling
commands.


3) Don't spend too much time trying to be tricky, especially if the
communication link between the device and the host computer is very
fast. It seems every device will have weird bugs you have to get around;
if the communication link is fast it is usually easier and better to
just treat the device as being completely stupid and let all the generic
routines do the work.


4) If you wait a few years you'll get a faster computer to replace the one
you have now, AND it will fit under your desk...