Bug #544

ps2raster/gs runs forever

Added by Eduardo over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:2014-04-17
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.x-svn Platform:Linux

Description

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

real 0m21.166s
user 0m13.492s
sys 0m4.868s

time ps2raster -TG example_19.ps

real 0m53.148s
user 0m50.192s
sys 0m1.220s

time ps2raster -A -TG example_19.ps

real 1m8.061s
user 0m59.980s
sys 0m6.004s

time ps2raster -A -P -TG example_19.ps

real 1m9.244s
user 0m59.844s
sys 0m6.292s

time ps2raster -A -P -E150 -TG example_19.ps

real 0m28.593s
user 0m20.900s
sys 0m5.488s

time ps2raster -TG -Qg4 -Qt4 example_19.ps

real 0m54.893s
user 0m50.416s
sys 0m1.232s

time ps2raster -P -TG -Qg4 -Qt4 example_19.ps

real 0m52.196s
user 0m50.148s
sys 0m0.948s

time ps2raster -P -E150 -TG -Qg4 -Qt4 example_19.ps

real 0m11.814s
user 0m10.996s
sys 0m0.308s

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.

real 244m4.108s
user 234m2.788s
sys 2m49.132s

ghostscript 9.05~dfsg-8+b1 Debian jessie

Associated revisions

Revision 13078
Added by Paul over 3 years ago

Not use alphabits during BB calculation; see issue #544

History

#1 Updated by Eduardo over 3 years ago

I have the same problem on Linux Fedora 19 with ghostscript 9.10-5.fc19

#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

real 0m6.268s
user 0m6.220s
sys 0m0.024s

time gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -dMaxBitmap=2147483647 -dUseFastColor=true -dTextAlphaBits=4 example_19.ps 2> ./ps2raster_21778c.bb

real 0m6.264s
user 0m6.217s
sys 0m0.026s

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

real 0m16.902s
user 0m1.948s
sys 0m0.033s

#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

real 0m25.062s
user 0m23.365s
sys 0m1.696s

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:

http://bugs.ghostscript.com/show_bug.cgi?id=695176

— 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
PostScript program.

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
excruciatingly slow.

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."

#6 Updated by Paul over 3 years ago

  • Status changed from Feedback to In Progress

I have removed the alphabits stuff from the BB calculation. Let me know how it works for you. In r13078.

#7 Updated by Eduardo over 3 years ago

It works for me!

#8 Updated by Eduardo over 3 years ago

time ps2raster -A -P -E150 -TG -Qg4 -Qt4 example_19.ps

real 0m25.909s
user 0m20.796s
sys 0m4.736s

as it was in the beginning

#9 Updated by Paul over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Moving this to resolved. If no further issues I will close in a few days.

#10 Updated by Paul over 3 years ago

  • Status changed from Resolved to Closed

Closing this one.

Also available in: Atom PDF