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

Jim Graham james.graham at oracle.com
Wed Apr 24 17:38:36 UTC 2013

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 

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


More information about the 2d-dev mailing list