Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!sun-barr!decwrl!adobe!gelphman From: gelphman@adobe.COM (David Gelphman) Newsgroups: comp.sys.mac.programmer Subject: Re: Meaning of visRgn in offscreen bitmaps + whinings about PrintManager. Message-ID: <1136@adobe.UUCP> Date: 31 Aug 89 11:59:19 GMT References: <1358@speedy.mcnc.org> <3925@internal.Apple.COM> Reply-To: gelphman@adobe.UUCP (David Gelphman) Organization: Adobe Systems Incorporated, Mountain View Lines: 29 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