Follow-on bugs

[Laurent Bourgès]

Jim,

There is one thing I think you should look at, though, and I wasn't sure if
> I should file a bug.  If you've downloaded the Rasterization verifier from
> the old JBS bug for non-AA rendering, try running it with the 4quads mode
> (-quad argument I think).  It looks like it averages slightly more failures
> on Marlin than jpisces or npisces.  (3 bad pixels per shape rather than 2 -
> or 4 vs. 3 - I forget the exact numbers).  This may simply be a difference
> in the DEC_INC_BND settings and an easy fix.  File a bug if you find
> something to fix...
>


I made tests related to nonAA quality and the related quad decimation
thresholds:
The quad decrement threshold seem a bit too high => lowering to 0.5
subpixel leads to 2.07 error:

OpenPisces:
bad paths (78759/100000 == 78,76%, 177046 bad pixels (avg = 2,25), 6524
warnings (avg = 0,08)

MarlinFX:
bad paths (90332/100000 == 90,33%, 288202 bad pixels (avg = 3,19), 6702
warnings (avg = 0,07)

MarlinFX with DEC_BND=0.5:
bad paths (77342/100000 == 77,34%, 164702 bad pixels (avg = 2,13), 6649
warnings (avg = 0,09)

So the trivial fix consist in lowering the threshold.

HOWEVER, it led me having a look again at the algorithmic approach:
The (Sun) paper (Lien 87) describes this approach (AFD) to draw curves
pixels by pixels so the original thresholds were defined to 1 / 0.5 pixels
and it indicates that this algorithm generates at least 1 point per pixel
... so is not related to any error bound nor really the good approach to
minimize the number of segments when the curve is "flat".

Moreover, this test performs path fills (no stroke) so I am asking several
questions about the algorithmic approach:
- AFD thresholds are in fact related to delta X/Y or speed and are ensuring
small displacements (subpixel) unrelated to any error (ROC ?) between the
segment and the curve => it will generate lots more segments than needed
except when the curve has cups or inflexions ...
- subdividing curves may be a more appropriate approach (agg, QT...) as
there are several flatness tests (intermediate point distance like in
ShapeSpanIterator.c) to ensure the curve is under-control ie within the
tolerance
- in Stroker, the curve is subdivided at cups, inflexion points, roots to
have monotonic cuves but in the case of path fills, the curve is directly
processed by the Renderer: maybe we should first subdivide the curves at
those extrema and then use the current approach to improve the affinity at
these special points.

Finally the curve segments are generated with the floating-point maths so
the pixel accuracy is also strongly related to rounding points on the grid
(at pixel centers), so this implies to have small tolerance to compensate
rounding issues.

Jim, do you have advices on:
- how to improve both curve accuracy but also minimize the number of
generated segments ? which algorithm ?
- which flatness test has your recommendations ?
- do you know an adaptive AFD variant that determine the step size
according to radius of curvature ? (like in Graphics Gem I: p594 Wallis
Tutorial on Forward Differencing)

Laurent