🚀 go-pugleaf

In article <1481@helios.ee.lbl.gov> forrest@ux1.lbl.gov (Jon Forrest) writes:
>I'd like to hear comments about how Display Postscript is fast
>enough to be used as a display system whereas Printer Postscript
>seems to be the bottleneck on many laser printers. Is my
>assumption about the cause of the bottleneck correct? What is
>missing from Display Postscript that makes it unsuitable to also
>be Printer Postscript? Does Display Postscript performance degrade
>when complicated images are displayed the way Printer Postscript
>does? What are the other differences that make the speed of
>Display Postscript so much better?

A simple, quick answer is that there are lots of caches, binary
encodings, and greased tracks for the Display PostScript system
interface that help quite remarkably in interactive use.

The long answer is that there is great complexity behind the perception
that "PostScript is Slow."  It is pretty easy to say, but it helps to
have a little understanding of the language itself to make a more
incisive judgement.

Consider the task of drawing a circle:

	method 1:
		60 30 30 0 360 arc stroke

	method 2:
		/circle {
		    /endang exch def
		    /startang exch def
		    /radius exch def
		    /Y2 exch def
		    /X2 exch def
		    /Y1 exch def
		    /X1 exch def
		    X2 X1 sub 2 div Y2 Y1 sub 2 div translate
		    X2 X1 sub Y2 Y1 sub
		    gsave
			scale
			newpath 0 0 0.5 startang endang arc
			stroke
		    grestore
		    newpath 
		} def

		0 0 60 60 0 360 circle

In method 1, a circle is drawn with a single procedure call to the
native "arc" operator.  There is very little interpreted language
overhead in this; it has to recognize the "arc" name, but during the
drawing of the circle, it is not executing any interpreted code.  This
is fast.

In method 2, a "circle" procedure is written that runs three times
around the Mulberry bush before eventually calling "arc".  You can see
all kinds of interpreted language overhead in this procedure.

This does not illustrate why Display PostScript is fast while Printer
PostScript is slow.  It is certainly possible to make any programmable
interface go slowly.  What it does help illustrate is that the
PostScript language as a printer interface is not *inherently* slow.
People just manage to make it go slowly.  The primary reason for this
seems to be that it is easier to make a PostScript program that
emulates your application than it is to just produce good marking
instructions with PostScript.

When building a printed page, people don't get overly concerned about
"a little overhead."  They want the output to look right, first and
foremost.  The above charicature of printer driver PostScript is
actually a great simplification over what most printer drivers really
look like.

If you were writing a Display PostScript screen driver, you would
notice this lack of performance right away, and you'd fix it (basically
because you watch it happening, and it is painful).  When you are
writing a printer driver, you just don't (instead, you rely on the old
saw "if it ain't broke, don't fix it.").

Think of "emacs", the editor.  It is essentially based on an
interpreted language at some level, too.  Does that make it too slow to
be an editor?  Depends on how you program it, methinks. (No flames,
please, about how it is actually compiled, etc., etc.)

This is all to say that the original premise is basically false, not
that it wasn't a reasonable conclusion....

Glenn Reid
Adobe Systems
PostScript Developer Tools & Strategies