laser-lovers@ucbvax.UUCP (01/28/86)
From what little I know about PostScript printers, it seems like the biggest drawback is the speed of the interpreter. I was wondering just how cost effective it would be to really soup-up the CPU in a PostScript printer, and what that souping-up would involve. For a small machine like the Apple LaserWriter the slow compute speed doesn't seem too critical. Once you get into 20+ ppm machines, however, you really need the processor speed to take advantage of that wonderful print engine. Both the LaserWriter and the Dataproducts LZN-266x have M68000's in them. (Anybody know about the QMS machines?) Why not a 68010 or 68020? Surely the performance gain would be worth the extra few hundred dollars. Am I underestimating what it would cost to put in an 020? What about hardware assist for the main processor? Wouldn't a few RasterOp chips do wonders to speed graphics up? Surely there must be a faster way to do area fill than to have a 68xxx step through a 2-D array and do bit-set operations. They build lisp machines to run lisp super-fast, why not a PostScript machine? Am I beating a dead horse with this? Do the available PostScript printers already use these tricks? If not, can anybody thing of a good reason why not? Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
laser-lovers@ucbvax.UUCP (01/30/86)
> What about hardware assist for the main processor? Wouldn't a few > RasterOp chips do wonders to speed graphics up? Surely there must be a > faster way to do area fill than to have a 68xxx step through a 2-D array > and do bit-set operations... You might be surprised. A 68000 running very carefully-written software can do some large-area graphics operations at speeds approaching the memory-bandwidth limit. RasterOp chips will not help much there. Nor will they help much for character drawing, where the drawing time is usually insignificant compared to the processing overhead. Yes, there are places where well-designed RasterOp hardware will help, but they may not be the bottlenecks in the PostScript machines. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
laser-lovers@ucbvax.UUCP (02/01/86)
>usually insignificant compared to the processing overhead. Yes, there >are places where well-designed RasterOp hardware will help, but they may >not be the bottlenecks in the PostScript machines. Yep, the problem is in making them there rasters when they aint cached.
laser-lovers@ucbvax.UUCP (02/07/86)
In article <8601301425.AA04955@uw-beaver.arpa> you write: >You might be surprised. A 68000 running very carefully-written software >can do some large-area graphics operations at speeds approaching the >memory-bandwidth limit. RasterOp chips will not help much there. Nor >will they help much for character drawing, where the drawing time is >usually insignificant compared to the processing overhead. Yes, there >are places where well-designed RasterOp hardware will help, but they may >not be the bottlenecks in the PostScript machines. What is the bottleneck for printing large documents? Is it the 9600 baud RS232c or the hostcomputer speed? When using the Appletalk connection at some 100kbaud, isn't the 68000 the bottleneck? When you talk about processing overhead over drawing time, don't you think something like a hardware matrix mulitiplier like in an IRIS 2400 workstation would speed up the whole thing? Beside this all: do you know something about conversion software from PostScript to the QUIC language on QMS' LaserGrafix printers? We could use it on this VAX (Unix BSD 4.2), on MacIntoshes/LISA, or Sun Workstations. Thank you very much, Peter Eigenraam OCE R&D Dept., Venlo, Holland
laser-lovers@ucbvax.UUCP (02/21/86)
> What is the bottleneck for printing large documents? Is it the 9600 baud > RS232c or the hostcomputer speed? When using the Appletalk connection at > some 100kbaud, isn't the 68000 the bottleneck? I don't know a lot about the LaserWriter, but other people have commented that generating bitmap fonts from the LW's internal form is probably a major bottleneck, since this is a cpu-intensive process. Also, see below. > When you talk about processing overhead over drawing time, don't you think > something like a hardware matrix mulitiplier like in an IRIS 2400 > workstation would speed up the whole thing? You miss the point: the problem is not complex calculations, but simple decision overhead. Determining what character is wanted, finding it in the font, deciding where to place it in the bitmap. A 68000 is not a Cray; doing these things takes time. On an 8 MHz 68000, a typical instruction time is a couple of microseconds. That adds up very quickly. Decision overhead is several hundred microseconds per character even in something like Rob Pike's Blit terminal, which uses very simple fonts and has *no* fancy transformations that would be helped by Iris-like hardware. Note that this implies that a 9600-baud line is plenty fast enough if all you are doing is sending characters to be drawn. (Bitmaps are another story, mind you!) That's a character arriving about every millisecond, which will be close to 100% cpu utilization in the printer even in the very best case. > Beside this all: do you know something about conversion software from > PostScript to the QUIC language on QMS' LaserGrafix printers?... Absolutely nothing, I fear. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
laser-lovers@ucbvax.UUCP (02/23/86)
>> When you talk about processing overhead over drawing time, don't you think >> something like a hardware matrix mulitiplier like in an IRIS 2400 >> workstation would speed up the whole thing? What about the machine driving the printer? We've got an Apple LaserWriter hooked up to an 11/750. I don't care if the printer can do 100 pages a minute; there's no way a 750 can generate troff output fast enough to keep up with the 8 ppm LaserWriter anyway (especially when troff is at the end of a bib|neqn|tbl pipeline). I know this isn't quite apropos to laser-lovers, but I think what we really need are faster formatters, not faster printers. From what I've seen, most formatters (troff, tex, scribe) have their own rather primitive model of what a printer is capable of and don't take advantage of the nifty things PostScript can do. They waste huge amounts of time computing the line breaks when the printer could do it better and faster.
chris@MIMSY.UMD.EDU (Chris Torek) (02/24/86)
Perhaps if you run troff on a 750, the LaserWriter is not a bottleneck; but if you run TeX on an 8600, with an Ethernet interface to an Imagen 8/300, the 8 ppm is most definitely the bottleneck. (Incidentally, I have been told `Even on a loaded 750, imagen1 [my Imagen TeX driver] runs at several times 24 pages per minute.') So while you may not need faster PostScript engines, rest assured that somewhere, someone else does. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
boyle@ANL-MCS.ARPA (James M. Boyle) (02/24/86)
[I inadvertantly deleted my copy of the message to which this is a response. Sorry if that shows.] Leaving page break computations to the laser printer to save cpu time during formatting doesn't seem practical to me. The formatter has to know where the line breaks come in order to determine the page length so that it can output footnotes and figures that are supposed to come at the bottom of a page, doesn't it?