Bug 695176 - gs runs forever with -dGraphicsAlphaBits=4
Summary: gs runs forever with -dGraphicsAlphaBits=4
Status: RESOLVED WORKSFORME
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Regression (show other bugs)
Version: 9.05
Hardware: PC Linux
: P4 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-19 11:18 UTC by Eduardo suarez
Modified: 2014-04-21 00:33 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
test file (605.15 KB, application/postscript)
2014-04-19 11:22 UTC, Eduardo suarez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eduardo suarez 2014-04-19 11:18:28 UTC
This runs forever in gs 9.05 (Debian Jessie) and gs 9.10 (Fedora 19)

gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -dMaxBitmap=2147483647 -dUseFastColor=true -dGraphicsAlphaBits=4 -dTextAlphaBits=4 example_19.ps 2>out

Without -dGraphicsAlphaBits=4 works OK:
Comment 1 Eduardo suarez 2014-04-19 11:22:16 UTC
Created attachment 10841 [details]
test file
Comment 2 Ken Sharp 2014-04-20 09:00:59 UTC
This looks like a duplicate of #694811 and #694848, the fix was committed as:

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=abd38464f9b058502c9491873ff7f01f00c406d7

and is present in the master code as well as the last release (9.14) I would suggest you try the current release, the current code works for me.
Comment 3 Eduardo suarez 2014-04-20 09:33:35 UTC
I've tested binary gs-914-linux_x86 and my problem is still there: 10 minutes and gs still running.
Comment 4 Ken Sharp 2014-04-20 11:22:41 UTC
(In reply to comment #3)
> I've tested binary gs-914-linux_x86 and my problem is still there: 10
> minutes and gs still running.

I'll have to boot up a VM to test Linux, I'll give it a try tomorrow.
Comment 5 Ken Sharp 2014-04-21 00:33:09 UTC
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.