[OpenJDK Rasterizer] Marlin renderer contribution for review

[Laurent Bourgès]

Jim,

2015-03-18 23:03 GMT+01:00 Jim Graham <james.graham at oracle.com>:

>
>
> 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...?


As you pointed, 90% arrays can be considered "dirty" and I tried to add a
comment like "// dirty" (maybe I forgot some of them):
I think it is a very good idea to adopt a convention like array_d ...

However, there are zero-filled arrays (of course) for important reasons:
- coverage / tile accumulator (alpharow, touchedTile)
- growable arrays that need to be zero-filled (edgeBuckets,
edgeBucketCounts)
- growable arrays can exceed their initial array capacity => they use
...ArrayCache and these must stay "clean": zero-filled in put() for the
dirty range [from, usedMark]

I advocate it is a bit tricky and looks like C (unsafe) than java code.

To conclude, it is maybe more important to indicate "clean" arrays than
dirty ones...

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20150318/b5fe28c4/attachment-0001.html>