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.gra...@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
