Path: utzoo!utgpu!watmath!clyde!att!rutgers!gatech!purdue!decwrl!adobe!greid From: greid@adobe.com (Glenn Reid) Newsgroups: comp.lang.postscript Subject: Re: Why is Display Postscript Fast when Printer Postscript is Slow? Message-ID: <132@adobe.COM> Date: 20 Dec 88 01:43:35 GMT References: <1481@helios.ee.lbl.gov> Sender: news@adobe.COM Reply-To: greid@adobe.COM (Glenn Reid) Organization: Adobe Systems Incorporated, Mountain View Lines: 88 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