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

[Jim Graham]

FYI - we have a bug to integrate some optimizations from JDK6 for wide 
lines and transformed rectangles.  In 6 I did some work a year ago or so 
to detect simply wide lines and transformed rectangles and to issue a 
"fillParallelogram" internal method.  OGL and D3D can then implement 
these directly and I wrote new software loops for doing pgrams as well. 
  We are right now going through our list or 6 bugs and integrating them 
into 7 so this code should get integrated in the next month or so.  At 
that point I think that horizontal lines may be moot...

			...jim

On 11/10/2010 2:01 PM, Denis Lila wrote:
> Hi Jim.
>
>> - 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...
>
> I also implemented what you describe and those are exactly my results too.
> I implemented my ideas for optimizing edgeM[in|ax]Y too, but it turned out
> not to make any difference whatsoever.
>
> I should note that my benchmarks say the performance on horizontal lines has
> decreased by 32% compared to the version where we qsorted everything. The
> benchmark report says the overall performance has stayed the same because
> every test other than horizontal lines is performing better by about 2-6%.
>
> Regards,
> Denis.
>
> ----- "Jim Graham"<james.graham at oracle.com>  wrote:
>
>> I ended up going with:
>>
>> 			...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