| Summary: | Very slow rendering of stroke with thousands of subpaths. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Ray Johnston <ray.johnston> |
| Component: | Graphics Library | Assignee: | Robin Watts <robin.watts> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | 532 | Word Size: | --- |
| Attachments: |
14.pdf
14_Coupe-profile.txt |
||
Created attachment 7138 [details]
14_Coupe-profile.txt
Profile of the entire file (14_Coupe_T2_Atelier_2-file.pdf) on peeves using
a 'pg' build and gprof. Different than what 'sleepy' showed on Windows, but
MUCH more trustworthy
Fixed in revision 12038. The code contains an optimisation to allow us to spot the case where strokes are being rendered solid with a normal blend mode, and to allow us to use the fast path through the code. In this case we were using "compatible" blend mode, which is supposed to be the same as normal, but wasn't triggering the fast code. The fix is simply to map "Compatible" -> "Normal" within the code. The change allows me to run the 14_Coupe... file that used to take 212 seconds
to complete in 28 seconds (on the same glacial laptop).
I suggest adding a comment about what we are doing and why. For example:
/* Map Compatible to Normal so other code treats Compatible as Normal */
/* Often BLEND_MODE_Normal is checked for optimized handling, and */
/* Compatible is now specified to be the same. */
Comment committed as part of revision 12039. Thanks. |
Created attachment 7136 [details] 14.pdf Command line: gs -r600 -sDEVICE=ppmraw -dBandHeight=128 -o nul: -Z: 14.pdf This reports (on a 1.6GHz Celeron): % Outputpage start time = 8.359 % Outputpage end time = 143.859 Note that running with -dNOTRANSPARENCY completes in 16.594 sec