Converting the attached file to a 300 DPI 24 bpp uses about a lot of memory (over 500 megs). The customer would prefer it used less. The memory usage pattern is kind of odd, it goes to 1 gig of memory almost immediately and then falls down to 370 megs. However, it then alternates between using 370 megs and 550 megs as the file is processed. The command line I'm using: bin/gs -sDEVICE=tiff24nc -o test.tif -r300 ./57652.pdf Older versions of Ghostscript (i.e. 8.54) use less memory (peaking at ~200 megs).
It looks like the memory usage increased with r8426: r8426 | leonardo | 2007-12-07 15:39:06 -0800 (Fri, 07 Dec 2007) | 44 lines Fix (clist interpreter) : Skip idle compositors, step 3. DETAILS : The clist writer writes the 'create compositor' operation to all bands, including ones that are not covered by a transparency. It does so because this operation changes the number of color components. . . .
(In reply to comment #2) > It looks like the memory usage increased with r8426: > > r8426 | leonardo | 2007-12-07 15:39:06 -0800 (Fri, 07 Dec 2007) | 44 lines > > Fix (clist interpreter) : Skip idle compositors, step 3. > > DETAILS : > > The clist writer writes the 'create compositor' operation to all bands, > including ones that are not covered by a transparency. > It does so because this operation changes the number of color components. Its another crazy Cairo produced PDF file, the page is defined as being transparent with a BBox covering the entire media. The page content is a form, which is transparent with a BBox covering the entire media, the form uses ~66 XObject, each XObject is defined as a form, which is transparent with a BBox covering the entire page. These mostly seem to consist of patterns tiled across the entire media. Watch how slowly Acrobat draws this at screen resolution..... In short, it uses a lot of memory because it needs to. Maybe Michael's new code will do something to reduce the problem.
With the pattern trans clist code merged down to the trunk this now runs in much less memory; approximately 30Meg maximum at 300dpi. Still slow though (slower than Acrobat, which is itself slow), so I've opened an enhancement bug (bug #692249) for optimising the speed of the transparency blending functions.