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.
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...
...jim
