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
