| Summary: | stroking: gs does not return any output (hangs) | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Chi Kien Uong <openssl> |
| Component: | Other Driver | Assignee: | Henry Stiles <henry.stiles> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | Keywords: | bountiable |
| Priority: | P3 | ||
| Version: | 8.51 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| URL: | http://pdf.selfip.net/seite5.pdf | ||
| Customer: | Word Size: | --- | |
| Attachments: |
seite5.pdf
vt.bmp.zip |
||
|
Description
Chi Kien Uong
2005-11-03 03:30:47 UTC
I used: time bin/gswin32c -dBATCH -dMaxBitMap=300000000 -dNOPAUSE -dSAFER - sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g2421x3306 -r150x150 - sOutputFile=xx.pnm ../test_files/688363.pdf -c quit Results: real 373m33.00s user 367m52.56s sys 0m16.89s That does seem a little excessive. Interesting that this hangs for a long time on an 'S' operation at step 20114 (using -dPDFSTEP). I will check where this is going with the debugger. I suspect shaded fill but that is just a guess. Customer field is reserved for Artifex OEM customers. retest I ran a retest on this file since there have been several improvements which might affect the file execution time. File aborted after 20 minutes. The file is spending a huge amount of time inside of intersect_al. Changing assignment to the person to the implementer of this routine. Created attachment 2158 [details]
seite5.pdf
A local copy of the test file.
intersect_al was factored out from Peter's code. With using visual trace and a C debugger one can see that the problem happens due to 'stroke' generates a lot of sector-like spot segments, which have centers at a small distance, so that the path contains a big number of lines, which differ in a small angle and have multiple intersections, which appear close each to another. One can see that on Windows running with -TF and specifying ScaleX=20 ScaleY=20 in Windows\gs_vdtrace.ini. IMHO the stroking algorithm needs an improvement. We also noticed that forcing the scanline angorithm appears some faster, but still not satisfactory. Created attachment 2159 [details] vt.bmp.zip The stroke outline snapped with visual trace -TS option (a fragment that could fit into window). gs_vdtrace.ini parameters for taking it are : [VDTRACE] OrigX=600000 OrigY=1500000 ScaleX=300 ScaleY=300 ShiftX=0 ShiftY=0 This problem happens with GraphicsAlphaBits>1 only, due to a reason explained in the comment in gspaint.c ln 370 : * The alpha-buffer device requires that we fill the * entire path as a single unit. Otherwise each stroke spot segment is painted separately, so as it doesn't need to compute so many line intersections. A work around for this is to use 4x resolution, then 'convert' the file down to the desired resolution (and don't use GraphicsAlphaBits > 1) The time required to make a 600 dpi ppm with gs was 15 seconds, and the convert time was 23 seconds (on my 3GHz P4). The command lines I used were: bin/gs -sDEVICE=ppmraw -r600 -g9684x13224 -sOutputFile=seite5-600.ppm seite5.pdf convert -resize 25% seite5-600.ppm seite-150.ppm *** This bug has been marked as a duplicate of 690531 *** |