[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

[Jim Graham]

I ended up going with:

- get rid of edgeMxy in all methods but addLine()
- addLine computes min/max of first/lastScanline
- addLine also computes min/max of x1,x2 values

this turned out to be just about the same speed for my FX rendering 
version (which I believe is more sensitive than the way it is integrated 
into JDK, so it should be even less noticeable in JDK).  It also paved 
the way for a couple of other optimizations that ended up netting about 
1FPS for my current test case that I use so I'm happy for now.

The code is a lot simpler now...

			...jim

On 11/9/2010 3:26 PM, Denis Lila wrote:
> 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"<dlila at 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.graham at 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