Bug 693310 - Excess memory usage with transparency and display device
Summary: Excess memory usage with transparency and display device
Status: NOTIFIED DUPLICATE of bug 689805
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: MS Windows Display Driver (show other bugs)
Version: 9.04
Hardware: PC Windows 7
: P2 enhancement
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-30 15:10 UTC by Marcos H. Woehrmann
Modified: 2014-02-17 04:45 UTC (History)
1 user (show)

See Also:
Customer: 581
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2012-08-30 15:10:45 UTC
The customer original reported:

attached is a sample file that results with Ghostscript 9.04 in

Unrecoverable error: stackunderflow in .begintransparencygroup
Operand stack:
    --nostringval--
pdf_page failed

with this command line

gswin32c -sDEVICE=display -dDisplayResolution=300 -dPrinted -sPAPERSIZE=letter file.pdf


The page dictionary contains a group attributes dictionary for transparency
and the resources contain an image with SMask. Deleting either the group
attributes dictionary or the image (not only in the content stream but also
in resources) solves the problem.
Comment 1 Marcos H. Woehrmann 2012-08-30 15:12:02 UTC
I found that -dMaxBitmap=30000000 fixes the error and reported this to the customer who responded:

thank you. I see it is also working with the display device in case of 100dpi resolution setting.

It seems the Group entry in the page and the smask image result in a much larger demand in memory.
Without the Group entry the page can be rendered at 200 dpi on my system.

What we currently use is the display device and most customer need 300dpi. Unfortunately the MaxBitmap setting is no solution because the default with value 0 seems to be already the one with minimum memory usage.

We will be happy if there is a way to use Ghostscript more memory efficiently. It seems we also have to look at using the TIFF device for large pages as workaround. Or maybe in future 64 bit.
Comment 3 Ray Johnston 2012-08-30 16:48:10 UTC
First, this is probably a duplicate of bug 689805 which stems from the
fact that some devices that render don't use the clist to avoid the need
for full page transparency buffers.

I do question the need for going to a 300 dpi display (even 'retina' displays
aren't that big).

Rendering to a png or tiff and using a viewer such as XnView is generally
better.

With -dMaxBitmap=30000000, I don't understand how it fixes the problem since
MaxBitmap is a clist (gx_device_printer) parameter and is ignored by the
'display' device which is NOT a subclass of the gx_device_printer (a 'page'
device).

Marcos, are you _sure_ this works ???

I'll add this customer to the bug 689805 and close this as a duplicate.

*** This bug has been marked as a duplicate of bug 689805 ***