[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

[Denis Lila]

Hi Jim.

> Did you have to modify the AFD code for this (in terms of changing
> their limit constants to get good results)?

No, I didn't. By handling non monotonic curves, the AFD algorithm
is going through more iterations, but the only way in which this
could be a problem is through accumulation of numerical inaccuracies,
and I don't think we do enough iterations for this to start causing
perceptible problems. I haven't noticed anything in all my testing.

Regards,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> Hi Denis,
> 
> On 11/9/2010 3:06 PM, Denis Lila wrote:
> > I see. In that case, I think it's a good idea if we don't make
> curves
> > "monotonic". I already did this, by moving the edgeMin/axX/Y
> handling
> > and orientation computations in addLine. This did make it slower
> compared
> > to the file you sent me, but only by very, very little. Curves were
> > affected the most, and they were only 1% slower. I think we can
> handle
> > this, especially since lines were about 1% faster. The code is also
> 70
> > lines shorter.
> 
> > The edgeM* members are used only so we don't have to iterate through
> every
> > scanline if this is not necessary, and so that we can tell
> PiscesCache
> > that the bounding box is smaller than what Renderer is given.
> However, now
> > that we keep the bucket list, I think it would be more efficient if
> we
> > got rid if EdgeM[in|ax]Y and simply computed the y bounds by looking
> at the
> > head and tail of the bucket list.
> 
> That makes sense.  We calculate that per-edge anyway so the edgeMy 
> constants are redundant.
> 
> > Also, perhaps we can keep track of edgeM[in|ax]X using the bounding
> boxes
> > of curves, instead of the lines in the flattened curves. This would
> not
> > be accurate, but I don't think it would affect rendering. It would
> simply
> > result in a few more alpha boxes than necessary. I don't think these
> would
> > be too bad, because mostly they're just going to be all 0 so they
> will
> > be skipped because getTypicalAlpha() is now implemented.
> > How do you think we should handle these 4 variables?
> 
> I think this is probably OK, but let me play with it a bit and see
> what 
> I come up with.  For one thing, the extra "slop" may not be large
> enough 
> to trigger a full tile of 0's - there would have to be 32-pixel
> borders 
> for that to happen.
> 
> If we get rid of the redundant edgeMy calculations then we might be
> able 
> to do edgeMx calculations on each edge without losing any
> performance...
> 
> 			...jim