[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
james.graham at oracle.com
Tue Nov 9 15:43:55 PST 2010
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.
Did you have to modify the AFD code for this (in terms of changing their
limit constants to get good results)?
> 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...
More information about the 2d-dev