forrest@ux1.lbl.gov (Jon Forrest) (12/16/88)
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? Jon Forrest Lawrence Berkeley Lab., 486-4991 forrest@lbl.gov (internet) ucbvax!lbl-csam!ux1!forrest (uucp) FORREST@LBL (bitnet)
tynor@pyr.gatech.EDU (Steve Tynor) (12/16/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? Could it have something to do with lower resolution (e.g. ~75 dot/inch vs. ~300)? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= No problem is so formidable that you can't just walk away from it. Steve Tynor Georgia Tech Research Institute tynor@gitpyr.gatech.edu
jonnyg@umd5.umd.edu (Jon Greenblatt) (12/16/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 ... >Jon Forrest Lawrence Berkeley Lab., 486-4991 I do not know first hand but I hear Display Postcript gets compiled down to machine code and is not interpreted. Also from what I have seen of the NeXT Machine the windowing is handled in Objective C, only the actual graphic output is in postscript. This is why display postscript blows away everything else inlcluding NeWS in terms of speed. I'll know more when the black boxes come rolling through the door. JonnyG.
anderson@vms.macc.wisc.edu (Jess Anderson, MACC) (12/16/88)
In article <4348@umd5.umd.edu>, jonnyg@umd5.umd.edu (Jon Greenblatt) writes... ]This is why display postscript blows away ]everything else inlcluding NeWS in terms of speed. I'll know more when ]the black boxes come rolling through the door. At this point, that should probably be *if*, not when! ==Jess Anderson===Academic Computing Center=====Univ. Wisconsin-Madison===== | Work: Rm. 2160, 1210 West Dayton St., Madison WI 53706, Ph. 608/263-6988 | | Home: 2838 Stevens St., 53705, 608/238-4833 BITNET: anderson@wiscmacc | ==ARPA: anderson@macc.wisc.edu========UUCP:{}!uwvax!macc.wisc.edu!anderson==
cplai@daisy.UUCP (Chung-Pang Lai) (12/16/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.
]What are the other differences that make the speed of
]Display Postscript so much better?
]
]Jon Forrest Lawrence Berkeley Lab., 486-4991
]forrest@lbl.gov (internet)
]ucbvax!lbl-csam!ux1!forrest (uucp)
]FORREST@LBL (bitnet)
People in Adobe should answer this, but I can contribute what I heard.
I actually asked the same question when I took a PostScript programming
course at Adobe Systems. Back then, Display PS is not out yet, they
showed us a demo video tape and claimed that they did not speed up
the video. :-) I doubted the tape back then because a page that used to
take 10 minutes on a LaserWriter flashes on the screen in 10 sec.
Of course, I believe them now after seeing the real demo in conferences.
The instructor did not answer my question directly but instead just
said that they will use the Display PS technology in future release of PS
controller for printers. I guess they wanted to keep it as a trade secret.
These I heard from other sources:
1. 72 dpi vs 300+ dpi is a big difference.
2. Display PS cheats when handling small size font. They use bitmap
font when you can't tell the difference.
3. They pass pre-scanned tokens instead of sending streams of ASCII
postscript code.
I heard the above, don't blame me for any mistake.
I am taking a NeWS programming class this week at Sun. Doing PostScript
interactively is really fun compared to waiting at a printer. PostScript
is only a small part of NeWS. Sending a PostScript picture to my fellow
classmate's screen is fun. It is like crossing X-window with PostScript
and Object Oriented Programming but not quite.
--
.signature under construction ...
{cbosgd,fortune,hplabs,seismo!ihnp4,ucbvax!hpda}!nsc!daisy!cplai C.P. Lai
Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961jhc@vax5.CIT.CORNELL.EDU (12/17/88)
In article <994@dogie.edu> anderson@vms.macc.wisc.edu (Jess Anderson, MACC) writes: |In article <4348@umd5.umd.edu>, jonnyg@umd5.umd.edu (Jon Greenblatt) writes... | |]This is why display postscript blows away |]everything else inlcluding NeWS in terms of speed. I'll know more when |]the black boxes come rolling through the door. | |At this point, that should probably be *if*, not when! | We just got some delivered this week. They'll be installed and up in one of our public sites by the beginning of the spring semester. Can't wait. -JimC -- James H. Cloos, Jr. "Entropy isn't what it used to be." jhc@Crnlvax5.BITNET --c/o Fortune @ batcomputer.UUCP jhc@Vax5.CIT.Cornell.EDU #include <std_disclaimers.h> cornell!vax5.cit.cornell.edu!jhc@rochester.UUCP B-7 Upson Hall, Cornell Univ., Ithaca, NY 14853 +1 607 272 4519
greid@adobe.com (Glenn Reid) (12/20/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
greid@adobe.com (Glenn Reid) (12/20/88)
In article <2164@daisy.UUCP> cplai@daisy.UUCP (Chung-Pang Lai) writes: >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. >]What are the other differences that make the speed of >]Display Postscript so much better? >] >]Jon Forrest Lawrence Berkeley Lab., 486-4991 >]forrest@lbl.gov (internet) >]ucbvax!lbl-csam!ux1!forrest (uucp) >]FORREST@LBL (bitnet) > >These I heard from other sources: >1. 72 dpi vs 300+ dpi is a big difference. >2. Display PS cheats when handling small size font. They use bitmap > font when you can't tell the difference. >3. They pass pre-scanned tokens instead of sending streams of ASCII > postscript code. >I heard the above, don't blame me for any mistake. > 1. Yes, there are fewer bits to render. This helps, especially when software is rendering the bits (rather than hardware). 2. "cheats" isn't quite the right word. You CAN tell the difference, which is exactly why bitmap fonts are used. It isn't a performance optimization (the font cache would handle that). It is done strictly for the better appearance of hand-tuned bitmap fonts at small point sizes. 3. Yes, pre-scanned tokens is part of the streamlined front-end interface to the interpreter, and this also helps. There are also cached paths, graphic state objects, and lots of language extensions to help with interactive rendering. I hope this helps. Glenn Reid Adobe Systems
cosell@bbn.com (Bernie Cosell) (12/20/88)
In article <133@adobe.COM> greid@adobe.COM (Glenn Reid) writes: }In article <2164@daisy.UUCP> cplai@daisy.UUCP (Chung-Pang Lai) writes: }>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. }>]What are the other differences that make the speed of }>]Display Postscript so much better? }>] }> }>These I heard from other sources: }>1. 72 dpi vs 300+ dpi is a big difference. } }1. Yes, there are fewer bits to render. This helps, especially } when software is rendering the bits (rather than hardware). Should one conclude from this that PostScript on "for real" printers (2000dpi and up) runs super-duper slow? [After all, 300 is about 20 times as many bits as 72, but 2000dpi is almost a *thousand* times as many points] __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
greid@adobe.com (Glenn Reid) (12/22/88)
In article <33706@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes: >Should one conclude from this that PostScript on "for real" printers (2000dpi >and up) runs super-duper slow? [After all, 300 is about 20 times as many >bits as 72, but 2000dpi is almost a *thousand* times as many points] Well, no. It isn't the total number of bits, but more the number of calculations required. Think of the "flatness" parameter. If you're filling a rectangle, it doesn't matter much how many DPI you have. If you're reducing a Bezier curve to a bitmap, you have to do more work if the resolution is higher. So yes, it is a factor. But it is nowhere near proportional to the density of device space. Besides, the marking engines run more slowly for higher resolution printers, so no one notices, right? :-) Glenn Reid Adobe Systems Mountain View