[OpenJDK Rasterizer] Marlin renderer contribution for review

[Laurent Bourgès]

Jim,

2015-03-30 20:34 GMT+02:00 Jim Graham <james.graham at oracle.com>:

> Looks like it is good to go into the graphics-rasterizer repo, then.
>
> Thanks for the hard work on the cleanup Laurent!
>

Thanks for your reviews too, but I am really happy that marlin goes in
(back).
What kind of performance / regression tests do you plan to run (j2dBench) ?

I hope testers and then users will enjoy its performance and its
scalability !


We'll need to get people testing this with their programs and start looking
> into any additional cleanup.


Excellent. Could you give how to properly commit this patch as I never did
it before (hg push) ?

FYI I have run all my regression tests last night and they passed (same
output image as pisces) : createStrokedShape, very large dashed shape
(spiral with 800k segments), winding rule (even odd / non zero) and many
complex affine transforms (tx, shear, rotate ...).


Did you have a list of things you were planning on working on?
>

Here is my list of ideas to be discussed:

First:
- improve coordinate rounding ie ceil(x - 0.5) or better ?
Maybe ceil/floor(float) intrinsics could help but let's discuss that in the
core-libs mailing list...
I have found another trick about float rounding:
http://stereopsis.com/sree/fpu2006.html
Or you may have other ideas as you did in your JavaFX renderer ?

- overflow handling: support NaN or very large coordinates => use subpixel
offsets vs boundaries to avoid overflow ...

- set reference to weak by default and maybe tune a bit initial array
capacities ...

- tweak tile size and x/y subpixels: it seems using 256 subpixel on x-axis
is free (no performance penalty)

- do some improvements to array caches (dirty vs clean caches): after your
comments, it appears few int[] arrays could use a dirty cache => no need to
zero-fill but it needs a new dirty IntArrayCache
- improve array cache access according to the array length: use some bit
magic tweak to avoid testing array length (in loop).

Last (R&D):  Improve rendering quality
    - adaptive scanline step to refine nearly horizontal edges up to 1/256
precision depending on the edge slope ~ adaptive resampling.
    - gaussian 1/2 filtering ie 1.5x1.5 pixels (ie mixing 3 scanlines) ~
use resampling filter better than the box filter
    - gamma correction in alpha & color coverage blending (as demonstrated
a while ago) at least on buffered image output (or quality color rendering
ie slow but more accurate)

Of course, I would appreciate having some help from other contributors on
these tasks.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20150330/46b4e90a/attachment-0001.html>