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

[Jim Graham]

Hi Denis,

The problem is that pruning complicates the inner loop that advances the 
scanline and you can't tell without scanning every segment in play 
whether you need to do it in its own loop.  Thus, for one of my test 
cases it was really expensive without some up front record of whether or 
not the pruning was needed.

Also, I keep a count so I can amortize the "widenArray" call.  Before I 
was calling "widen(..., 1)" inside the loop that drew new edges in from 
the bucket.  I could also have added an additional loop to count the new 
edges, but that would have been expensive as well...

			...jim

On 11/8/2010 3:23 PM, Denis Lila wrote:
> Hi Jim.
>
> I like the new Renderer, but I have a question about edgeBucketCount.
>
> As far as I can see it is only used so that we can tell whether
> any given bucket contains only edges that go all the way to the last
> (or beyond) scanline. Is this really common enough that we gain by
> treating it as a special case? Would it not be better to assume that
> every bucket needs pruning and save some memory (and possibly resulting
> in better cache performance)?
>
> Thanks,
> Denis.
>
> ----- "Jim Graham"<james.graham at oracle.com>  wrote:
>
>> It's still a work in progress, but I've cleaned up a lot of logic and
>>
>> made it faster in a number of ways.  Note that I've abstracted out the
>>
>> cache stuff and created an "AlphaConsumer" interface which may evolve
>>
>> over time.
>>
>> In FX we actually consume alphas in larger chunks than the code in JDK
>>
>> which was driven by Ductus's 32x32 mandate, so I would have had to
>> make
>> completely incompatible changes to emitRow - so I moved it behind an
>> interface.  For the JDK code, if you want to integrate this version, I
>>
>> would have the cache implement the new interface and move your version
>>
>> of emitRow into the Cache object.  I'd send you the new code for my
>> AlphaConsumer, but it is incompatible with what you need to cache so
>> it
>> won't help you.
>>
>> You'll also need a bit of un-translation cleanup as we have mirrors of
>>
>> all of java.awt.geom with special new APIs that FX needs.
>>
>> 			...jim
>>
>> On 11/8/2010 6:40 AM, Denis Lila wrote:
>>> Hi Jim.
>>>
>>>> Also, I've gotten another 20% improvement out of the design with a
>> few
>>>> more tweaks.  (Though I measured the 20% in the stripped down
>> version
>>>> that I'm prototyping with FX so I'm not sure how much of that 20%
>>>> would show up through the layers of the 2D code.  Overall, I've
>> about
>>>> doubled the frame rates of the prototype since your first drop that
>> you
>>>> checked in to the OpenJDK repository.)
>>>
>>> Can I see your new version?
>>
>> Attached.
>>
>>>> How about looking more at the stroking end of the process and I'll
>> dig
>>>> a little more into optimal rasterization code.  I have a lot of
>>>> experience with optimizing rasterizer code (and JNI if it comes to
>> that), but
>>>> very little with the curve manipulations involved in stroking (math
>> is so
>>>> *hard* at my age ;-)...
>>>
>>> Sounds good. Have you implemented your idea of processing one pixel
>> row at a
>>> time, as opposed to processing subpixel rows? If not, I could do
>> that.
>>
>> Not yet.  Right now I've gotten a lot of mileage out of a few tweaks
>> of
>> the bookkeeping of the sample-row-at-a-time version.  I'm still
>> mulling
>> over exactly how to make that go faster.
>>
>> 				...jim