Summary: | Memory/Resource usage with transparency | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Hin-Tak Leung <htl10> |
Component: | Vectors | Assignee: | Ray Johnston <ray.johnston> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | christinedelight.top85 |
Priority: | P4 | Keywords: | bountiable |
Version: | master | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- |
Description
Hin-Tak Leung
2009-11-22 18:12:32 UTC
The pxl device (as well as other gdevvec devices, and x11* and display do not use the clist device, so transparency can use large memory. I think there is another bug about this, I'll see about combining these. I think the main culprit is pdfwrite, the bug #689805 is a place holder for a number of issues relating to pdfwrite not using the clist when flattening transparency. I tried -K500000k -Zv and various resolutions; at least with Bug689581.pdf, it is just allocating 4 channels on pdf_open() and then again on seeing the first graphic object, I think, so that's 8 x width x height bytes right away. The resource usage is not a problem anymore. They all works within reasonable time with x11 (just plain 'gs *.pdf' without arguments) now. timing "gs -r600 -sDEVICE=pxlcolor -o /dev/null ..." gives Bug688778.pdf 3:14.72 Bug689581.pdf 7:40.99 Bug689982.pdf 2:23.52 Bug690379.pdf 2:28.20 or 2 minutes to 8 minutes with maximum resident set size ~ 56MB. This seems to fit the description of bug 689805 . Ken's suggestion of this being a duplicate is good enough for me. There are a few rendering issues AFAIK with clist-based transparency but they are tracked elsewhere. *** This bug has been marked as a duplicate of bug 689805 *** |