kk@mcnc.org (Krzysztof Kozminski) (08/22/89)
In article <3733@internal.Apple.COM> parent@apple.com (Sean Parent) writes: >In article <1336@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: >>As far as I can tell, IM is not correct: drawing does get clipped to visRgn. >>I have fresh a recollection of creating an off-screen bitmap to produce image >>for printing and doing CopyBits to the printer port just to find out that >>I was getting 640x480 pixel image ... > >Inside Mac is correct. Drawing does not get clipped to visRgn on an off >screen Bit/PixMap with one exception. StdBits (not CopyBits) will obey the >visRgn. > >Sean Parent Then how come that the following: OpenPort(&offBitsPort); ... initialize it to be exactly the size of a LaserWriter page ... SetPort(&offBitsPort); FillRect(&offBitsPort.portRect,gray); PrOpenPage(ThePrintPort,NULL); CopyBits(&offBitsPort.portBits,&ThePrintPort->gPort.portBits ,&offBitsPort.portRect,&offBitsPort.portRect,srcCopy,NULL); PrClosePage(ThePrintPort); Results in a printout *clipped to visRgn* ????? Also: how come that doing this CopyBits in chunks < 3.5kBytes (I know, it isn't really necessary) is THREE times slower than doing it in one huge piece? Also: how come a page-sized bit map (filled gray) prints on a LW in ~9 seconds at 100% scale, ~50 seconds at 50%, and ~80 sec at 25%? Shouldn't the ratios be more like 1 : 4 : 16 ? Why is it so damn slow anyway ? I'd think that just dumping a bitmap is the fastest thing that can be done (is it communications problem or what? Even at 25%, the LW page is < 1Mbyte - should transfer real fast) All the above times on a Mac II with 5 Mbytes of RAM and lots of disk space and LW II NT, with graphics smoothing OFF and precision bitmap alignment ON. Finally: am I the only person who thinks that saying in the Inside Mac, vol. 2, something to the effect "you draw to a printing port just as if it was a screen" just to follow it 3 pages later with making 95% of really useful QuickDraw calls (transfer modes & region operations) invalid on a LaserWriter is, well, inconsistent? Does anybody has a good method of doing 'patOr' on an LW short of drawing into your own off-screen port and then CopyBiting it? KK -- "The party was a masquerade; the guests were all wearing their faces."
parent@apple.com (Sean Parent) (08/23/89)
In article <1342@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: > Then how come that the following: > > OpenPort(&offBitsPort); > > ... initialize it to be exactly the size of a LaserWriter page ... > > SetPort(&offBitsPort); > FillRect(&offBitsPort.portRect,gray); > PrOpenPage(ThePrintPort,NULL); > CopyBits(&offBitsPort.portBits,&ThePrintPort->gPort.portBits > ,&offBitsPort.portRect,&offBitsPort.portRect,srcCopy,NULL ); > PrClosePage(ThePrintPort); > > Results in a printout *clipped to visRgn* ????? You are right, myself and InsideMac are wrong, the visRgn is obeyed on off screen bitmaps. > Also: how come a page-sized bit map (filled gray) prints on a LW in ~9 > seconds at 100% scale, ~50 seconds at 50%, and ~80 sec at 25%? > Shouldn't the ratios be more like 1 : 4 : 16 ? Why is it so damn slow > anyway ? I'd think that just dumping a bitmap is the fastest thing > that can be done (is it communications problem or what? Even at 25%, > the LW page is < 1Mbyte - should transfer real fast) I believe that the ratios are odd because of the overhead involved in scalling the image. At 100% you have a lot of scaling to do and very little data, 50% you have 4 times as much data and less scaling, 25% much more data but no scaling. This is just a guess, I am not a PostScript person. BitMaps are slow because they are sent as Hex data as required by PostScript. In the 7.0 architecture there will be specific drivers so Binary data can be sent to printers that can support it. > Also: how come that doing this CopyBits in chunks < 3.5kBytes (I know, it > isn't really necessary) is THREE times slower than doing it in one huge piece? The only reason I can think of for this is that the PostScript has a large overhead on the image operator. There are some improvements that can be made for the 7.0 architecture here also. > Finally: am I the only person who thinks that saying in the Inside Mac, > vol. 2, something to the effect "you draw to a printing port just as if > it was a screen" just to follow it 3 pages later with making 95% of > really useful QuickDraw calls (transfer modes & region operations) > invalid on a LaserWriter is, well, inconsistent? Does anybody has a > good method of doing 'patOr' on an LW short of drawing into your own > off-screen port and then CopyBiting it? PostScript does not have the concept of transfer modes. PostScript also does not have anything like regions. Solutions to these problems are being looked into. One of the goals of the 7.0 architecture is to build a consistent printing platform. Sean Parent
kk@mcnc.org (Krzysztof Kozminski) (08/23/89)
In article <3801@internal.Apple.COM> parent@apple.com (Sean Parent) writes: >In article <1342@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: >> [bitching about sloooooooooow printing of bitmaps on LW] > >I believe that the ratios are odd because of the overhead involved in >scalling the image. Yes, but the scaling is the simplest possible when 'exact bimap image' is turned ON: 1 pixel of image maps into 4x4, 2x2 and 1x1 at the 100%, 50%, 25%. Why isn't there a CASE in the LW driver to handle these special values efficiently? (BTW, 100% with 'exact bimap image' turned OFF takes ~10 times longer than with ON - this I can easily understand). >BitMaps are slow because they are sent as Hex data as required by PostScript. I've just looked it up in the Adobe manuals: Hex or binary turns out to be the same bits (unless LW driver tries to do some fancy data compression while sending it over). The way I figure it out, it should take about 3 seconds to print a full-page bitmap at 25% reduction with 'exact bimap image' turned ON. (this is assuming transfer rate about .5Mbytes per second - I seem to recall this value from somewhere in the IM). Can anybody tell me why it ain't so? >> [more bitching from KK about castrated QuickDraw for LaserWriter] >PostScript does not have the concept of transfer modes. Yes, perhaps I should be more specific: how come 'srcOr' is supported (the only mode not supported for bit image transfer is 'srcXor') and 'patOr' is not? For a while I had a little routine that implemented 'patOr' for 'PaintRect' by filling a small 16x16 bitmap with the desired pattern, and then repeatedly doing CopyBits from it to cover the destination rectangle, while taking care of the proper alignment as well. Before even getting this to work, I've found out that doing my own entire image and copying it over is faster. Now what is so complicated about the above that it could not be implemented by Apple in the first place? KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."
parent@apple.com (Sean Parent) (08/25/89)
Let me preceed this by saying that I am not a PostScript expert. I don't work with PostScript at all, however, I do work in the PrintShop. In article <1346@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: > Yes, but the scaling is the simplest possible when 'exact bimap image' is > turned ON: 1 pixel of image maps into 4x4, 2x2 and 1x1 at the 100%, 50%, 25%. > Why isn't there a CASE in the LW driver to handle these special values > efficiently? (BTW, 100% with 'exact bimap image' turned OFF takes ~10 times > longer than with ON - this I can easily understand). The LW driver does not scale the BitMap PostScript does. What would the case statement do? Remember the LaserWriter Driver is written as a general purpose PostScript Driver. It drives the LaserWriter Classic, +, NT, NTX with variouse ROM revisions and the QMS ColorScript, and variouse other PostScript devices. Sometimes it has to talk to the device through a server. > I've just looked it up in the Adobe manuals: Hex or binary turns out to be > the same bits (unless LW driver tries to do some fancy data compression > while sending it over). No, the hex data is twice the size of binary data. That is the data is sent as ASCII digits like: 4F56 Each nibble requires 1 byte to transmitt. > The way I figure it out, it should take about 3 seconds to print a full-page > bitmap at 25% reduction with 'exact bimap image' turned ON. (this is assuming > transfer rate about .5Mbytes per second - I seem to recall this value from > somewhere in the IM). Can anybody tell me why it ain't so? Yes, it should take only 3 seconds. Or even 6 seconds sent as HexData. But there is overhead in packaging the data, overhead in sending it (can you say busy networks and protocall layers), then PostScript gets its grubby little hands on it and takes a merry amount of time :-P > Yes, perhaps I should be more specific: how come 'srcOr' is supported > (the only mode not supported for bit image transfer is 'srcXor') and > 'patOr' is not? For a while I had a little routine that implemented > 'patOr' for 'PaintRect' by filling a small 16x16 bitmap with the > desired pattern, and then repeatedly doing CopyBits from it to cover > the destination rectangle, while taking care of the proper alignment as > well. Before even getting this to work, I've found out that doing my Well, that would work fine for rectangles but what about Ovals Arcs, RoundRect, Polygons? These are handled by creating a spot function in PostScript that mimics the pattern and draws the object with this spot function. > own entire image and copying it over is faster. Now what is so > complicated about the above that it could not be implemented by Apple > in the first place? There is nothing so complicated about it. In fact, the fastest thing would be to image the entire page with QuickDraw and send one big BitMap to your device. But then you have to know the printers resolution and build a Raster Engine into the LaserWriter Driver (Oh I wish QD could scale objects correctly) And then you can't handle PostScript in the document and QuickDraw doesn't currently support outline fonts (but will soon) and QuickDraw doesn't currently support rotation. You could pre-scan a page for these items and transfer modes and such and decide what image to send to the printer. But what if an App wants to send everthing? How do you explain that the entire page looks slightly differently when they use XOR on an object? (Apple Outline Fonts and PostScript do not look identical, niether do QD ovals and the ones drawn by PostScript). These are difficult problems and the 7.0 architecture will help by allowing specific drivers to be written to support a device to the fullest extent possible. Printing is getting better all the time (compare the 6.0 LaserWriter driver to the previous version (5.2?)). Sean Parent I have my opinions and my employer has his/hers.
kk@mcnc.org (Krzysztof Kozminski) (08/25/89)
[Had to kill references list - rn would give me internal errors - KK] In article <3906@internal.Apple.COM> parent@apple.com (Sean Parent) writes: >> [KK, in an earlier article: Why isn't there a CASE in the LW driver to >> handle 100%. 50% and 25% scaling of bitmaps efficiently] > >The LW driver does not scale the BitMap PostScript does. What would the >case statement do? It would tell the printing engine: "here are bits, stick'em directly into your image, don't do any extra processing" >Remember the LaserWriter Driver is written as a general purpose PostScript >Driver. It drives the LaserWriter Classic, +, NT, NTX with variouse ROM >revisions and the QMS ColorScript, and variouse other PostScript devices. >Sometimes it has to talk to the device through a server. Either the LaserWriter in the System folder, or the software in the LaserWriter hardware knows the actual physical resolution of the device (I suspect both do). I see no reason why this knowledge should not be used to speed up bitmap printing. Probably the PostScript software in the LW (hardware) should be smart enough to notice that the dimension of the bitmap is exactly the same as it destination rectangle. >No, the hex data is twice the size of binary data. OOPS, my error. >Yes, it [printing a full page bitmap - KK] should take only 3 seconds. Or >even 6 seconds sent as HexData. But >there is overhead in packaging the data, overhead in sending it (can you >say busy networks and protocall layers), then PostScript gets >its grubby little hands on it and takes a merry amount of time :-P Yes, like additional 2 minutes. And I have a single Mac connected to a single LW, with no other business on the network than transmitting my bitmap. So what causes a 2000% time overhead? >> [A simple method of doing patOr on LW for rectangles] >Well, that would work fine for rectangles but what about Ovals Arcs, >RoundRect, Polygons? (...) >There is nothing so complicated about it. In fact, the fastest thing would >be to image the entire page with QuickDraw and send one big BitMap to your >device. And that's what I wind up doing anyway, unless somebody can tell me how to emulate patOr more efficiently. I can see the problems on the QuickDraw - PostScript interface, but sloooooooooooooooooooow copying bitmaps should not be one of them. On a side: what is so complicated about rotating bitmaps that QuickDraw does not have a routine to do it ? How about drawing text vertically? KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."
parent@apple.com (Sean Parent) (08/26/89)
In article <1358@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: > >The LW driver does not scale the BitMap PostScript does. What would the > >case statement do? > > It would tell the printing engine: "here are bits, stick'em directly into > your image, don't do any extra processing" I agree, but I don't believe that there is any way to tell PostScript to do this (though I do know that printing a Binary image is much faster). You can query the printer to find out it's resolution at print time assuming it is not hooked up to a spooler and the PostScript is not being routed via a file as is so commen today (command K stuff). Still know way around the PostScript engine though (well, there are some ways if you know exactly what device you are talking to. Cases like this is why there will be specific drivers in the 7.0 architecture as well as a general purpose PostScript driver that just assumes lowest commen denominator PostScript. > Either the LaserWriter in the System folder, or the software in the > LaserWriter hardware knows the actual physical resolution of the device > (I suspect both do). I see no reason why this knowledge should not be > used to speed up bitmap printing. Probably the PostScript software in the > LW (hardware) should be smart enough to notice that the dimension of the > bitmap is exactly the same as it destination rectangle. Yes, the PostScript software should be smart enough to notice that the dimension of the bitmap is exactly the same as its destination rectangle. But it isn't (at least not today). > bitmap. So what causes a 2000% time overhead? I don't know for sure. I will speak at length about this with the people working on the PostScript Imaging Engine for the 7.0 architecture. Speed is a high priority in 7.0 (although quality comes first). > On a side: what is so complicated about rotating bitmaps that QuickDraw > does not have a routine to do it ? How about drawing text vertically? Nothing. I like vertical text. I believe we are in violent agreement. Sean Parent My opinions are mine. Apple has its own.
gelphman@adobe.COM (David Gelphman) (08/31/89)
In article <3925@internal.Apple.COM> parent@apple.com (Sean Parent) writes: >In article <1358@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: ... >> used to speed up bitmap printing. Probably the PostScript software in the >> LW (hardware) should be smart enough to notice that the dimension of the >> bitmap is exactly the same as it destination rectangle. > >Yes, the PostScript software should be smart enough to notice that the >dimension of the bitmap is exactly the same as its destination rectangle. >But it isn't (at least not today). ... >Sean Parent The PostScript interpreter DOES recognize when the bit image would exactly fit in the 'destination rectangle' and there is a performance win in that case. Of course that assumes that you are really matched with device resolution. Most Macintosh applications are working with bit images at 72 dpi and when you try to maintain the same physical image size on a 300 dpi device, there is not a one to one correspondence between a bit in the source data and a bit in the frame buffer. The performance win also occurs in a number of cases such as 90 degree rotations and some other simple transformations. As far as I know, all implementations have the optimization for the most simple cases, more recent implementations have a number of other cases optimized. Note that this only applies to one bit per pixel images and I'm not certain if it applies to imagemask which is used heavily by the Apple printshop. David Gelphman Adobe Systems Incorporated