ps2raster/gs runs forever
|Target version:||Candidate for next bugfix release|
In certain cases ps2raster runs (almost) forever. I don't know if this is due to ps2raster or ghostscript.
time ps2raster -A -P -E150 -Tf example_19.ps
time ps2raster -TG example_19.ps
time ps2raster -A -TG example_19.ps
time ps2raster -A -P -TG example_19.ps
time ps2raster -A -P -E150 -TG example_19.ps
time ps2raster -TG -Qg4 -Qt4 example_19.ps
time ps2raster -P -TG -Qg4 -Qt4 example_19.ps
time ps2raster -P -E150 -TG -Qg4 -Qt4 example_19.ps
I've interrupted this
time ps2raster -A -P -E150 -TG -Qg4 -Qt4 example_19.ps
^Cps2raster: System call [gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -dMaxBitmap=2147483647 -dUseFastColor=true -dGraphicsAlphaBits=4 -dTextAlphaBits=4 example_19.ps 2> ./ps2raster_20234c.bb] returned error 2.
ghostscript 9.05~dfsg-8+b1 Debian jessie
#2 Updated by Paul over 3 years ago
- Status changed from New to Feedback
I tried Adobe Distiller and it did a great job in just a ~5 seconds. Just running gs example_19.ps is the same thing. That is for PDF of course, and ps2raster matches that speed. So what is slow is rasterizing to an image and clearly the cause is the patterns, since if I replace that with a constant color it is fast. In particular, it is must slower because of the circuit.ras file which have larger dimensions (135x94) than the built-in patterns (64x64) and is also in color. So somehow that implementation in gs is slow.
For PDF, using the -A option adds a little bit of time. On my Mac it takes ~2 secs without -A and ~6.5 with -A. Those 4-5 seconds also adds to any other format. So it is mostly interpreting and resampling the circuit pattern that slows things down.
I've added more output when -Vd is run (r13069) so we can see all the intermediate system calls. I wonder if it is any point to passing those antialiasing options when we just are determining the bounding box? Perhaps save those for the real action later? In the case of your hung call (the last one), if I remove those options from the BB call then that part finishes quickly.
#3 Updated by Eduardo over 3 years ago
the problem is with sDEVICE=bbox + -dGraphicsAlphaBits=4
time gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -dMaxBitmap=2147483647 -dUseFastColor=true example_19.ps 2> ./ps2raster_21778c.bb
time gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -dMaxBitmap=2147483647 -dUseFastColor=true -dTextAlphaBits=4 example_19.ps 2> ./ps2raster_21778c.bb
this opens a remote display in my machine, but works
time gs -q -dSAFER -dNOPAUSE -dBATCH -dMaxBitmap=2147483647 -dUseFastColor=true -dGraphicsAlphaBits=4 example_19.ps 2> ./ps2raster_21778c.bb
#4 Updated by Eduardo over 3 years ago
well, as I suspected it isn't GMT, is ghostscript
time gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -dMaxBitmap=2147483647 -dUseFastColor=true -dGraphicsAlphaBits=4 -dTextAlphaBits=4 example_19.ps 2> ./ps2raster_21778c.bb
with ghostscript 8.71~dfsg2-9+squeeze1 Debian Squeeze.
#5 Updated by Eduardo over 3 years ago
I've created a ticket on ghostscript bugtraq and this is their answer:
— Comment #5 from Ken Sharp <> —
"OK the basic answer is that this is to do with resolution.
In order to get accurate bounding box information the bbox device runs at a
very high resolution (4000 dpi). Since the device doesn't normally actually
render anything, this doesn't cause any performance problems.
However, if you set GraphicsAlphaBits, the code takes a slower rendering path.
In addition, it is forced to degenerate patterns into a sequence of trapezoids
in order to anti-alias the images contained in the patterns specified in the
Degenerating into trapezoids is a resolution-dependent operation (and its
comparatively slow), the higher the resolution, the greater the number of
trapezoids required to cover the area. So rendering at 4000 dpi is
There really isn't any point in setting -dGraphicsAlphaBits or -dTextAlphaBits
with the bbox device, it doesn't do anything useful. My recommendation is to
omit both those parameters. Alternatively (or if you want to test my
conclusions) you can set the resolution to a lower figure, setting -r72 causes
the job to complete in a matter of seconds for me, even with
-dGraphicsAlphaBits. Of course, the calculated bounding box will not be very
accurate that way.
I believe that if you wait a very long time, the program will complete even
with the original command line, it hasn't locked up its just very, very slow
because its doing many billions of operations."