Hi Jim. > All lines generated from a given "allegedly monotonic" curve are > recorded with the same "or" (orientation) value. But, if the curves > are not truly monotonic then it might be theoretically possible to > generate a line that is backwards with respect to the expected orientation. > It > would then get recorded in the edges array with the wrong orientation > and slope and then rasterization might unravel.
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. 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? Thank you, Denis. ----- "Jim Graham" <james.gra...@oracle.com> wrote: > Hi Denis, > > On 11/8/2010 2:39 PM, Denis Lila wrote: > >> Finally, I discovered (while testing for other problems) that the > >> curves are not truly monotonic after slicing them. I realized this > years ago > >> when I was writing my Area code (see sun.awt.geom.Curve) and put > in > >> tweaking code to make them monotonic after they were split. They > are > >> never off by more than a few bits, but you can't trust the curve > >> splitting math to generate purely monotonic segments based on a t > >> generated by some unrelated math. Sometimes the truly horizontal > or > >> vertical t value requires more precision than a float (or even a > >> double) can provide and splitting at the highest representable > float less than > >> the t value produces a pair of curves on one side of the hill and > >> splitting at the next float value (which is greater than the true > t > >> value) produces curves on the other side of the hill. Also, when > the > >> curve has been split a few times already, the t values loose > accuracy > >> with each split. This will all be moot if I can eliminate the > >> splitting code from the renderer, but it may also play a factor in > the > >> stroke/dash > >> code... > > > > Making curves monotonic is only used for optimization purposes, > > so it can't see how it would affect rendering correctness. > > Fortunately, the non-monotonicity is limited to a few bits of > precision > so this may never generate an errant edge in practice unless > flattening > gets really fine-grained... > > ...jim
