Summary: | Memory and CPU problem when converting a specific page in TIFF or PS format | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Jean-Luc Hofman <jean-luc.hofman> |
Component: | General | Assignee: | Robin Watts <robin.watts> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | christinedelight.top85, donnayf, jackie.rosen, robin.watts |
Priority: | P3 | Keywords: | bountiable |
Version: | 8.54 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Customer: | Word Size: | --- | |
Attachments: |
Page causing GhostScript to use increasing memory and to stop
screenshot.png |
Description
Jean-Luc Hofman
2007-02-22 02:45:57 UTC
Created attachment 2779 [details]
Page causing GhostScript to use increasing memory and to stop
Do you have reproduced the problem? Thanks in advance, Francois Have you any news for us? Created attachment 2844 [details]
screenshot.png
Adobe Acrobat Reader 7.0 on my 64 bit Linux box fails in a similar way (see
screenshot.png). It initially loads the PDF okay, but when I try to zoom in it
consumes and more and more memory (I killed it at 2 gigs).
The file contains the following fragment: [0.075756 0.028408 ] 0 d -907.772 786.549 m % Repeated 128 times 9646.9238 -15043.7656 l % with small variations. S i.e strokes a dashed line with 32M dashes. No wonder the file needs so much memory. IMHO the file is invalid. Some additional DEBUG (PDFSTEP output): 4 0 0 4 0 0 cm step # 201335 ? [ step # 201336 ? 0.075756 0.028408 ] step # 201337 ? 0 d step # 201338 ? -907.772 786.549 m step # 201339 ? 19646.9238 -15043.7656 l step # 201340 ? Then the sequence of 'm' and 'l' repeats as Alex mentions, then finally the 'killer' processing starts with: S step # 201495 ? _____________________________________________________________ Does it make sense to eaxmine the dash settings and when the entire dash sequence is less than 2 device pixels, turn it into a solid line ? Also the order in the graphics library must be converting the entire line to dashes, even if it is outside the clip path. At 300 dpi, the dash pattern implied by: [ .075756 .028408 ] is 1.7367 device pixels. At this same scale, the stroke segments deltas are 175911.5 in X and 263838 in Y. The entire page (A4) is only 2480x3508 pixels. Ignoring dash expansion outside the clip path (accumulating position, but don't add individual segments to the path) would optimize this somewhat. ______________________________________________________________ With the following (experimental) patch, I was able to convert the file to tiffg4 at 300 dpi in 23 seconds using less than 10Mb. *** lib/pdf_draw.ps Thu Jun 21 19:36:18 2007 --- ./pdf_draw.ps Sat Jul 7 11:15:20 2007 *************** *** 287,293 **** /i { 1 .min setflat } bdef /J /setlinecap load def ! /d /setdash load def /j /setlinejoin load def /w /setlinewidth load def /M { 1 .max setmiterlimit } bdef --- 287,298 ---- /i { 1 .min setflat } bdef /J /setlinecap load def ! /d { 1 index length 0 gt { ! 1 index 0 exch { add } forall ! dup dtransform pop ! 2 lt { exch pop [ ] exch } if % set to solid ! } if setdash ! } bind def % /setdash load def /j /setlinejoin load def /w /setlinewidth load def /M { 1 .max setmiterlimit } bdef _______________________________________________________________________ Ressigning to Igor to consider making the optimizations in the graphics library where they will benefit PCL as well as PS and PDF. Actually, thinking about it a bit more, it probably suffices to treat any dash pattern with the largest 'space' being less than one pixel since the 'any part of pixel' painting rule will effectively paint all pixels. Also, the file probably isn't really 'invalid', but probably just a scaled down version of a map that was intended for rendering much larger. Reassigning to Alex for patch review. Graphics library optimizations can be left to Igor (reassigning the bug back to him then after the consideration of the patch) This approach doesn't work because CTM can change between setting the dash pattern and drawing the line. Testing shows significant regressions. OK, so I guess what is needed is to put the logic down in the C code when the line is drawn (to ignore small dashes that would just be solid anyway). Thanks, Alex, for pointing out the issue with doing it when 'setdash' is invoked. Sounds like a graphics lib issue. Solved in: commit dcc172feb018bfe0613f90ce76ce25dd1eafe3ce Author: Robin Watts <robin.watts@artifex.com> Date: Tue Oct 1 17:52:43 2013 +0100 Bug 689098: Only dash paths when the dashing would be visible. If the ctm doesn't expand the dash lengths to be > 1 pixel, then they can't be seen, so don't bother. Many thanks. |