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

[Jim Graham]

Hi Laurent,

Originally the version that was used in embedded used RLE because it 
stored the results in the shape itself.  On desktop I never found that 
to be a necessary optimization especially because it actually wastes 
memory for no gain during animations, but that was why they used RLE as 
a storage format.  Would it speed up the code to use a different storage 
format?

Also, in the version we use in JavaFX we removed the tiling altogether 
and return one alpha array for the entire rasterization.  We might 
consider doing that for this code as well if it allows us to get rid of 
Ductus - it was a Ductus design constraint that forced the tiling (it 
was again based on the expected size of the hardware AA engine)...

			...jim

On 4/23/13 2:58 PM, Laurent Bourgès wrote:
> 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
> <mailto: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>
>>> <mailto: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
>>>>
>>>>
>>>
>