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

[Igor V. Melichev]

Oops, there is some unequivalence of PSEUDO_RASTERIZATION 1 to 0.
It is in gxfill.c lines 2061 - 2071 :


#  if !PSEUDO_RASTERIZATION
  if ((xli = fixed2int_var_pixround(xltop)) ==
      fixed2int_var_pixround(xlbot) &&
      (xi = fixed2int_var_pixround(xtop)) ==
      fixed2int_var_pixround(xbot)
      )   /* Rectangle. */
#  else
  xli = fixed2int_var_pixround(xltop);
  xi = fixed2int_var_pixround(xtop);
  if (xltop == xlbot && xtop == xbot)
#  endif

The old code first rounds coordinates to pixels,
then checks for rectangularity, and apply fill_rectangle if so.
The new code checks rectangularity with unrounded values.
Due to this, the new code generates trapezoids for
some cases, in which the old code generates rectangles.
This was done intentionally against dropouts.

I've measured time with enforcing the old code in this fragment,
with PSEUDO_RASTERIZATION both 0 and 1. In both cases the slowdown persists.
So I still believe that the slowdown is the compiler's code optimizer overhead.

IMO the right way is to rewrite shfill with
a better subdivision algorithm. I don't like how the existing
algorithm applies fill_adjust against dropouts during shfill :
the subareas overlap and many pixels are painted redundantly.
IMO this is the exact reason of the performance flow,
in both old and new code. A right subdivision would
speed up in 2-3 times.

> From: "Jeong Kim" <jeong at artifex.com>
> To: "'Igor V. Melichev'" <igor.melichev at artifex.com>; "'gs-devel'" <gs-devel at ghostscript.com>;
"'Ray Johnston'" <ray at artifex.com>
> Sent: Saturday, April 12, 2003 5:56 PM
> Subject: RE: [gs-devel] Performance Comparison Report on Adobe CPSI, Jaws and Ghostscript.


> Igor,
>
> I also use MSVC6.
>
> Is it possible that we get different results because of a compiler
> problem?

Very likely. Also the processor type have sense.

Igor.