Hi again. I just thought of this: if we're really concerned about the accuracy of the edgeMinX edgeMaxX variables, we could find the curves' critical points and use them to compute the min/max X values. After all, we're creating (or rather "setting") the Curve objects anyway. This isn't as fast as using the bounding boxes, but it's close and much more accurate.
Regards, Denis. ----- "Denis Lila" <dl...@redhat.com> wrote: > 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
