Summary: | Ghostscript uses a large amount of memory converting file | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | General | Assignee: | Ray Johnston <ray.johnston> |
Status: | NOTIFIED FIXED | ||
Severity: | enhancement | CC: | henry.stiles, robin.watts |
Priority: | P2 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | 850 | Word Size: | --- |
Description
Marcos H. Woehrmann
2011-03-03 21:22:16 UTC
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. |