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

[Laurent Bourgès]

Jim,

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.

I simply do the rendering when nextTile() detects a tile line end !

Now it is working and the thread local cache is smaller: 32 x 4096 ~ 512k
for rowAARLE.

I think less memory is wasted and such arrays best fit into cpu cache.

Next step could be to use directly alpha data instead of RLE encoding /
decoding ...

More details asap

Laurent

Le 24 avr. 2013 19:38, "Jim Graham" <james.graham at oracle.com> a écrit :
>
> Hi Laurent,
>
>
> On 4/24/13 1:59 AM, Laurent Bourgčs wrote:
>>
>>     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?
>>
>>
>> Maybe it could be a very good idea: compressing alpha array to RLE and
>> then decompressing it to fill byte[] tile array seems a bad idea.
>> However, keeping RLE encoding may help having smaller arrays to store a
>> complete tile line as I want: width = 4096 (or more) x height = 32.
>
>
> 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.
>
>
>>     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)...
>>
>>
>> I think tiling is still interesting as such small arrays stay in the cpu
>> cache ! however, I could try tuning the tile width to be larger (256x32)
>> instead of (32x32 tiles) ...
>
>
> 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...
>
>
>> Finally,
>> Who could help me working on pisces ? Could we form a tiger team ?
>> or at least could denis and you have some time to help me ?
>
>
> 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.
>
> 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...
>
>                         ...jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130429/a85b33ca/attachment.html>