<p>Jim,</p>
<p>Sorry for the delay: I was busy on reworking the tile generation to cache only a single line of tiles: it allows me to have ROWAARLE[32][] and touchedTile a 1d array.</p>
<p>I simply do the rendering when nextTile() detects a tile line end !</p>
<p>Now it is working and the thread local cache is smaller: 32 x 4096 ~ 512k for rowAARLE.</p>
<p>I think less memory is wasted and such arrays best fit into cpu cache.</p>
<p>Next step could be to use directly alpha data instead of RLE encoding / decoding ...</p>
<p>More details asap</p>
<p>Laurent</p>
<p>Le 24 avr. 2013 19:38, "Jim Graham" <<a href="mailto:james.graham@oracle.com">james.graham@oracle.com</a>> a écrit :<br>
><br>
> Hi Laurent,<br>
><br>
><br>
> On 4/24/13 1:59 AM, Laurent Bourgčs wrote:<br>
>><br>
>>     Originally the version that was used in embedded used RLE because it<br>
>>     stored the results in the shape itself.  On desktop I never found<br>
>>     that to be a necessary optimization especially because it actually<br>
>>     wastes memory for no gain during animations, but that was why they<br>
>>     used RLE as a storage format.  Would it speed up the code to use a<br>
>>     different storage format?<br>
>><br>
>><br>
>> Maybe it could be a very good idea: compressing alpha array to RLE and<br>
>> then decompressing it to fill byte[] tile array seems a bad idea.<br>
>> However, keeping RLE encoding may help having smaller arrays to store a<br>
>> complete tile line as I want: width = 4096 (or more) x height = 32.<br>
><br>
><br>
> Or storing the crossings more directly.  It's a little obtuse to go from crossings to a 1D linear array of alpha deltas to RLE alphas to alphas.  For one thing, the crossings were sort of compact and then they got flattened into the deltas and then the RLE part has to do a linear search to compute the run lengths.  It would seem that it would be smaller and faster to do a more direct "crossing to RLE" step or just storing the crossings themselves (which are very analogous to RLE anyway), and then generating the tile directly from the packed stored crossings.<br>

><br>
><br>
>>     Also, in the version we use in JavaFX we removed the tiling<br>
>>     altogether and return one alpha array for the entire rasterization.<br>
>>       We might consider doing that for this code as well if it allows us<br>
>>     to get rid of Ductus - it was a Ductus design constraint that forced<br>
>>     the tiling (it was again based on the expected size of the hardware<br>
>>     AA engine)...<br>
>><br>
>><br>
>> I think tiling is still interesting as such small arrays stay in the cpu<br>
>> cache ! however, I could try tuning the tile width to be larger (256x32)<br>
>> instead of (32x32 tiles) ...<br>
><br>
><br>
> An issue with that is that there are some hard-coded pieces of the HW rasterizers that expect a 32x32 tile and would need to be rewritten to adjust to different tile sizes.  Once they are fixed then it might make sense to generate tiles by multiples of scanlines and dynamically determine the horizontal size on the fly depending on the shape being rasterized.  If you rasterize a shape that is 260 pixels wide then your 256x32 tile would involve way more up-and-down in the pipeline than a 512x16.  It might be better to have a 4K tile and then have the dimensions be W x (4K/W) and have the rendering loops allow an arbitrary tile size...<br>

><br>
><br>
>> Finally,<br>
>> Who could help me working on pisces ? Could we form a tiger team ?<br>
>> or at least could denis and you have some time to help me ?<br>
><br>
><br>
> It would be great to have a tiger team, but I'm not full-time on Java2D any more and Denis was only working on it during an internship so I'm not sure what he is up to now.<br>
><br>
> We have a "graphics-rasterizer" mailing list/project that was created to come up with an OS alternative to Ductus for OpenJDK.  It went silent when we got the first version of Pisces in and so that project has technically been finished.  If we can get a group of more than, well, you working and me tossing out suggestions then we can discuss if we want to revive that group or just continue on here...<br>

><br>
>                         ...jim<br>
</p>