[OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

[Laurent Bourgès]

Jim,

I am preparing an updated patch that will contain less syntax changes and
boiler plates. Sorry again.

I have optimized few array cleaning and it perform as fast as ductus on the
biggest map test : in average equals !!

i will send results and comparisons tomorrow.

Hint: alpha array cleaning in renderer endRendering can be optimized by
filling only dirty part as i already do in the given patch. This small
change can be applied easily...

Le 22 avr. 2013 23:05, "Jim Graham" <james.graham at oracle.com> a écrit :
>
> One thing about modifying the iterators.  I originally commented that I
thought an object there was a bit much but it helped Denis, who was doing
all the work after all, keep the code organized in his mind.  I'm not sure
what kind of measurements he made, but he didn't feel that they were
hurting performance at the time.  If you are finding that the allocation of
the iterators is costing us then I'd just as much like to see that paradigm
go away, though your fix to allocate them once and then re-init them does
save the memory costs.
>
> Other renderers I've worked on an written have done essentially the same
work inline rather than farming it out to another object.
>
> I also think it's a good suggestion to keep fixes on code like this more
focused on isolating the fix itself rather than reorganizing the code to a
personal style to fix a few issues.  So, as far as the code organization
changes I agree with Clemens there.  When it comes down to "a quick fix
that doesn't touch many lines of code" like your init() solution vs.
"rewriting that part of the code to no longer need the operations that were
causing problems" then it gets grayer.  I would have probably eliminated
the iterators altogether because I would view it as reducing the complexity
of the code, but your solution would probably touch fewer lines of code (if
you factor out the reorganization).  I at least wanted to throw that idea
out as a suggestion..

Agreed. I will try to provide smaller changes but it is difficult to
isolate efficient changes.

Last idea: I think reusing arrays is efficient because they reside in the
cpu cache... and less gc.

I would like to try perform the rendering / cache / tile generation by
chunks corresponding to 32 scan lines to have / reuse a smaller rowAARLE
array...

Finally I looked a bit at clipping shapes and I think it should be done
first in the Stroker segment processing.

Regards,
Laurent

>
>                         ...jim
>
>
> On 4/17/13 9:52 PM, Laurent Bourgčs wrote:
>>
>> Hi clemens
>>
>> Le 17 avr. 2013 23:16, "Clemens Eisserer" <linuxhippy at gmail.com
>> <mailto:linuxhippy at gmail.com>> a écrit :
>>
>>>
>>> Hi Laurent,
>>>
>>>> thanks for having some interest for my efforts !
>>>> As I got almost no feedback, I felt quite disappointed and was
thinking that improving pisces was not important ...
>>>
>>>
>>>
>>> Glad to see work is ongoing to improve pisces's performance :)
>>>
>>
>> Thanks a lot: I am working on pisces during my spare time and
>> congratulations is very important for my motivation.
>>
>>> I had a look at the patch just to be curious (I don't have reviewer
status), but to be honest I had troubles finding the relevant parts.
>>
>>
>> I agree I modify the code to help me understanding it : @override,
>> grouped fields, constant first, debug logs ...
>>
>> I can revert most of these boilerplates ... during cleanup.
>>
>> I sent the patch as webrev to let other people evaluate its performance
>> using their own platform, work load, benchmarks ...
>>
>>> Having not followed the discussion that closely, it was almost
impossible for me to extract the real modifications from
boilerplate/refactoring as your patch weights almost 3000 modified lines.
>>
>>
>> I looked at the webrev and I advocate I can discard many line changes.
>> As I use netbeans, it modified the code so easily... nevermind.
>>
>>> I am just an intrested observer without any official state, yet
personally I would prefer smaller pieces with clear description/title.
>>> However, I wouldn't want to cause you additional work and it's just a
single opinion.
>>>
>>
>> Ok. I mainly modified memory handling: use a renderer cache to reuse
>> arrays and pisces class instances to avoid too much allocations and
>> resizing ... stored in thread local or concurrent queue.
>>
>>> Thanks for working on pisces!
>>
>>
>> Thanks for your feedback too.
>>
>> Laurent
>>
>>>
>>> Regards, Clemens
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130423/c9b67046/attachment.html>