[OpenJDK Rasterizer] Marlin renderer contribution for review

[Jim Graham]

On 3/18/15 2:50 PM, Jim Graham wrote:
> On 3/18/15 9:17 AM, Laurent Bourgès wrote:
>>     -------- Here are some "things to consider later" ---------
>>
>>     I just realized the main case where we want to deal with cleaning
>>     out dirty arrays and it would be the crossings accumulation arrays.
>>     It seems to me that those are special cases and so we should
>>     concentrate the cleaning code on those explicitly and not have a
>>     global "lets clean all arrays everywhere" setting.
>>
>> Agreed.
>> Let's clarify my approach in marlin: it uses mainly reused arrays (int,
>> byte, float) => no allocation (GC overhead).
>> To achieve the best performance, it only clears dirty parts ie used ones
>> (see the many used mark fields).
>>
>> Dirty arrays are named "dirty" to indicate that these arrays are used in
>> a "unsafe" manner ie never zero-filled (always junk). It means the code
>> must be good enough to always set values and get those that have be set.
>
> Perhaps a naming convention for the variable so that we can spot code
> that might rely on cleared data being used on an array that isn't
> necessarily cleared then?

Thinking more about this - actually all arrays are (potentially) used in 
a dirty manner.  Some arrays naturally wouldn't care if the data is 
dirty because they are filled from the start and only access the part 
that is filled.  Others like the coverage accumulation arrays may be 
more randomly accessed and so having a predefined start state is 
important to them.

So, all arrays would qualify as "dirty" as per your description unless 
I'm missing something...?

			...jim