[gs-devel] Performance Comparison Report on Adobe CPSI, Jaws and Ghostscript.

[Igor V. Melichev]

> From: "Jeong Kim" <jeong at artifex.com>
> To: <gs-devel at ghostscript.com>; "Ray Johnston" <ray at artifex.com>
> Sent: Saturday, April 12, 2003 3:58 AM
> Subject: [gs-devel] Performance Comparison Report on Adobe CPSI, Jaws and Ghostscript.


> test3.eps 470KB 125.90x131.36cm Vector (Many shfills)

> Adobe CPSI (3010.108)
> test3.eps (720dpi) 12.54 109.06 121.6
> Ghostscript (current head - PSEUDO_RASTERIZATION) 
> test3.eps (720dpi) 217.29 261.3 478.59
> Ghostscript (current head - No PSEUDO_RASTERIZATION) 
> test3.eps (720dpi) 110.94 210.53 321.47

shfill subdivides the gradient area with areas of constant color,
then applies fill. When performing fill with a non-character path 
(particularly with a shfill subarea), the pseudo-rasterization is off.


I guess, the slowdown happens because shfill of a character applies 
a *clipped* fill to subareas of the gradient. With pseudo-rasterization on, 
the number of character's trapezoids is some bigger, and the number of calls to 
the clipped fill appears some bigger. This is the observed slowdonw.

IMO the logics used in GS in entirely wrong for the case of character shfill.
A right algorithm first rasterizes a character to alpha image,
then renders the gradient with the alpha mask in same way as transparency does.
(With TextAlphaBits=1 the alpha image is a bitmap). 
With this algorithm the speed of shfill doesn't depend on pseudo-rasterization on/off .
Therefore the exact reason of the observed slowdown is the cache logics 
rather than pseudo-rasterization.

Could you please send test3.eps to me ? 
I'd like to trace it with C debugger to prove or disprove my hypothesis.
Also I am interesting to run it with GS+FT.

Igor.