[OpenJDK Rasterizer] Rasterizer replacement proposal

[Roman Kennke]

Hi Jim,


> - It's also very basic in its mathematical techniques, though.  The math 
> to trace the slope of a line is inefficient and inaccurate and it 
> flattens everything before tracing.  There is a lot of room for 
> improvement here.

Indeed, that's true.

> - It uses a push technology - you call it with something to render, it 
> then calls something else with the data to render.  This is opposite the 
> designs in our pipeline which call the rasterizer and ask it to return 
> the path coverage information and then hand the path coverage 
> information off to a pixel pusher.  It will be hard to turn that calling 
> sequence around for this code unfortunately to make it match the way we 
> do things in our pipelines currently (via AATileGenerator).  Not 
> impossible, it will just require slicing up the code a bit on one side 
> or another.

Yeah right. That shouldn't be a problem to change.

> - It ignores the winding rule of the path, shouldn't be too hard to add 
> support for non-zero winding, though.

Right.

> - Clipping is managed by rasterizing both the shape and the clip at the 
> same time.  The advantage of rasterizing the clip along with the shape 
> is that you can rasterize the clip at a higher resolution when doing AA, 
> but it comes with some drawbacks:
> 
>      - It's easy for the Shape rasterizer to rasterize both at the
>        same time, but other parts of the pipeline (text and imaging)
>        won't be so lucky without a lot of added support code.

Yeah I was thinking about that too. However, 'our' (== aicas) rendering
renders everything using this rasterizer. For text it fetches the
outline shape of the glyphs and rasterizes them and for images it does
something like rendering a rectangle with a Texture-like Paint. For
target systems that offer better/optimized functions for these cases we
use the native libs of course.

>      - Clipping should restrict the same regardless of pipeline and
>        attributes set, but this clipping will restrict AA and non-AA
>        rendering differently (due to different resolutions).  It might
>        also restrict rendering of text and image differently unless
>        they duplicate its code.
> 
>      - There are a lot of calculations involved in rasterizing the
>        clip each time something is rendered - a big performance hit.

True. However, the clipping can simply be ignored or ripped out of you
don't need this. Should make the code simpler and faster.

> - There is little to no handling of large coordinates, the results of 
> handling them are a by-product of the calculation used to convert them 
> to fixed point.

It should be easy to do all calculations using float or double rather
than fixed point.

> - The slope calculation doesn't carry very much precision at all - it 
> looks like the error can be as much as +/- 1 pixel for every 64 
> samplings.  There are much better ways to manage the math there that 
> provide much more accuracy.  The code in 
> src/share/native/sun/java2d/pipe/ShapeSpanIterator.c traces the slope of 
> flattened shapes much more accurately.

I'll have a look there.

> - We found some performance improvements in directly tracing the curves 
> rather than flattening them.  These techniques are evidenced in the 
> src/share/classes/sun/java2d/loops/ProcessPath.java code (also mirrored 
> at the native level in src/share/native/sun/java2d/loops/ProcessPath.c).

Cool, I will study that too :-)

> I'd say for the short term, it might help get us off the ground wrt 
> satisfying the AATileGenerator interface, but there are probably some 
> simpler ways to achieve that end.  I have a quick and dirty prototype of 
> using Region objects to generate alpha tiles that I'll try to clean up 
> and throw out here for another straw man.  It performed about .1 to .5x 
> of the speed of the production code, but it was small and simple and 
> took Ductus out of the equation.

Nice.

I ask myself if it is worth the effort to continue with my
ScanlineConverter and friends classes. There are not only the technical
issues that you outlined above (plus more that might creep up), it also
seems to be difficult to find a quick-enough solution for the legal
stuff. An anti-aliasing rasterizer shouldn't be too much code anyway,
and it might be worth starting from scratch (or from your prototype),
with the special need of OpenJDK (and existing code in OpenJDK) in mind.
What do you think?

> The one piece that neither my quick Region hack nor this Rasterizer that 
> you are offering here satisfy is an alternate implementation of line 
> widening...

Yeah, my implementation relies on BasicStroke for that. Too bad. I
haven't really looked into the geometry of that path stuff.

How's the read-only HG and/or SVN workspace for Java2D going?

/Roman


-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt