Bug#682426: cups: filter gs takes several minutes consuming 100 % of CPU

[James Cloos <cloos@jhcloos.com>]

On Thu, Jun 20, 2013 at 05:23:30PM +0200, Bastien ROUCARIES wrote:
> On Thu, Jun 20, 2013 at 12:34 AM, Till Kamppeter
> > This bug report should be moved to Cairo.
> 
> I respectfully disagree:
> - cairo should help here to not generate transparancy
> - ghostscript should be optimized and they are some patch to do this

I asked on the cairo list.  Adrian replied that cairo has been fixed.

Cairo now limits the size of the SMasks as much as possible, pre-composes
images which do not intersect with vector objects to white when generating
postscript, but still outputs transparency when generating pdf.

Both gs and poppler/splash (ie odf2ps and pdftops) raster the entire
page if *anything* on the page has transparancy.

There is an enhancement request upstream for gs to raster only the
necessary sections (I didn’t get a reference, and haven’t found it yet).

I don’t yet know whether there already is an enhancement request for
splash to raster only what needs to be.

For the gs bug which came from this report, Ken would like to know
whether using a smaller raster dpi (such as 300) avoids the extreme
processing times the bug reporter saw.  ps2writer defaults to 720 dpi,
splash defaults to 300 dpi.  To test, use the pdf2ps command above
with the added switch: -r300 .

Separately, thanks to this report, there was talk of gs, possibly,
adding support to use banding when ram is tight.  Such a change would
improve the gs experience for everyone using it on low-ram boxen.
(That is the same mechanism it uses in embedded mode on printers.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6