This file runs with 8.53. 8.56 and HEAD (r7865) get an error. The tail of -dPDFDEBUG is: /Sh1 sh %Resolving: [19 0] %Resolving: [954 0] %Resolving: [1033 0] << /FunctionType 0 /Domain [ 0 1 ] /Range [ 0 1 0 1 0 1 0 1 ] /BitsPerSample 8 /Size [ 256 ] /Encode [ 0 255 ] /Decode [ 0 1 0 1 0 1 0 1 ] /Length 746 /Filter /FlateDecode >> stream %FilePosition: 1294567 endobj %Function: << /DataSource (M\013\023\000N\013\024\000O\f\024\000P\f\025\000Q\f\025\000R\r\026\000S\r\026\000T\016\026\000T\016\026\000U\017\026\000V\017\026\000V\020\027\000W\020\027\000X\021\027\000X\021\027\000Y\022\027\000Z\022\030\000Z\023\031\000[\023\032\000\\\023\032\000\\\023\033\000]\023\033\000^\024\033\000^\024\033\000_\025\033\000`\025\033\000`\025\034\000a\025\034\000b\026\034\000b\027\034\000c\030\034\000d\030\034\000d\030\035\000e\030\035\000f\031\036\000f\031\036\000g\032\037\000h\032\037\000i\032 \000i\032 \000j\032 \000k\033!\000k\033!\000l\034!\000m\035!\000m\035!\000n\035!\000o\034"\000p\034"\000q\035"\000r\036"\000r\037"\000s\037#\000t\037$\000t\037%\000u %\000v!$\000v!$\000v!$\000w"%\000w"%\000x"%\000y"&\000y"&\000z#&\000{$&\000{$&\000|$'\000}%\(\000}%\)\000~&\)\000\177'\)\000\177'\)\000\200\(*\000\201\(*\000\201\)*\000\202**\000\203+*\000\203+*\000\204,+\000\205,+\000\205,+\000\206,,\000\207,,\000\207,,\000\210--\000\211..\000\211..\000\212//\000\213//\000\213//\000\2140/\000\2151/\000\2161/\000\21710\000\22010\000\22020\000\22130\000\22140\000\22140\000\22251\000\22351\000\22352\000\22453\000\22554\000\22564\000\22673\000\22783\000\22783\000\23084\000\23084\000\23194\000\231:4\000\232;4\000\233;4\000\233<5\000\234<5\000\235=5\000\235=5\000\236>5\000\236>6\000\237?7\000\237?8\000\240?8\000\240?9\000\241?9\000\242@9\000\242A8\000\243B8\000\244B8\000\244C9\000\245C9\000\246D9\000\246E9\000\247F9\000\250F:\000\250F;\000\251F<\000\251G<\000\252H<\000\252I<\000\253I<\000\254I=\000\255I=\000\255I=\000\256J>\000\256J>\000\257K>\000\257L>\000\260M>\000\260M>\000\261N?\000\261N?\000\262O?\000\262O@\000\263P@\000\264P@\000\264QA\001\265QA\001\266RA\001\266SA\001\267TA\001\267TA\001\270UA\001\270UA\001\270UA\001\271VB\002\271VB\002\272WB\002\272XB\002\273YB\002\274YC\002\274YD\002\275YE\002\276ZE\002\276[D\003\277\\D\003\277]D\003\300^E\003\300^E\003\301_E\003\302`E\004\302aE\004\303aE\004\304bF\004\304bF\004\305bF\004\306bG\005\305cG\005\306dG\005\307eH\006\307fI\006\310eJ\007\311gI\007\311hJ\007\312gL\b\313iL\t\313jM\t\314iM\t\315jN\n\315lN\013\315lO\013\316lP\013\317mO\013\317nP\f\317mQ\r\320nR\016\321oR\016\321oR\016\322pS\017\322rT\020\323sT\021\323sT\021\324tU\022\325uU\023\325tV\024\326uX\025\326vW\025\326wW\025\326vX\026\327wY\027\330xY\030\330xY\030\330yZ\031\331zZ\032\331y\\\033\331{]\034\332|[\034\332{\\\035\333|^\036\334~^\037\334~^ \334~^ \334\177^!\335\200_"\336\201_#\336\201_#\336\202`%\337\203`&\337\202b'\337\203b\(\340\205a\(\340\204b\)\341\205c+\341\206c,\341\207c,\342\210d-\342\211d/\342\211e/\343\210f1\343\212f2\344\213f2\344\212g3\344\213h5\345\214h6\345\214h6) /BitsPerSample 8 /Encode [0 255] /Length 746 /FunctionType 0 /File -file- /Domain [0 1] /Size [256] /Filter /FlateDecode /FilePosition 1294567 /Decode [0 1 0 1 0 1 0 1] /Range [0 1 0 1 0 1 0 1] >> Error: /unregistered in --shfill--
Created attachment 2905 [details] Anniversaire.pdf
The bottom pf the problem : trianghle_by_4 performs tinny subdivision of the smallest side of the triangle. It causes a run over LAZY_WEDGES_MAX_LEVEL, and (as a consequence) wedge_vertex_list_elem_buffer overflow. To be fixed with defining triangle_by_2 if the smallest side is smaller than pixel.
A better way is to divide a big triangle in 2 parts if the longest side is more than twice longer than the shortest side. Applying triangle_by_4 to small triangles is faster.
Ray, Please attach the user's command line. I've got a patch, but I need to test the user's case exactly.
The patch : http://ghostscript.com/pipermail/gs-cvs/2007-May/007472.html fixes the failure, rather the performance is still unsatisfactory.
Another patch to HEAD that partially improves the performance : http://ghostscript.com/pipermail/gs-cvs/2007-May/007475.html
More performance improvements : http://ghostscript.com/pipermail/gs-cvs/2007-May/007476.html http://ghostscript.com/pipermail/gs-cvs/2007-May/007477.html http://ghostscript.com/pipermail/gs-cvs/2007-May/007478.html Now we can see 2 possible further performance improvements : 1. Account the clipping rect when computing the radial shading's parameter interval. The current code fills entire shading's Domain. 2. Store the shading raster in the pattern cache. Likely this test applies same shading for many objects.
Created attachment 2935 [details] Profile_main_release_sorted.txt Attaching a profile made with revision 7895. I sorted it by "Func+Child Time". Exact shadings spend 45.5% of time (see _fill_patch). Other 50+ persents are spent in clipping, stream reading, etc. So optimizing the shadings rasterization only won't give a rocket speed-up. As Ray pointed out in another mesage, the shading code calls color convertion functions too many times. A possible improvement is to reuse device colors in the shading rasterizer. Will see how to improve it. In same time, there are 2 other bugs, which would speed up the rendering : Bug 687414 "An analythic implementation for gs_direct_color_space::is_linear" and Bug 689211 "PDF interpreter creates redundant shadings". Will bump their priorities.
Revision 8008 provides a better performance. Further performance issues to be addressed to bug 689206, which apparently refers same document.