[OpenJDK Rasterizer] Rasterizer replacement proposal
Jim.A.Graham at Sun.COM
Wed Jun 13 21:46:51 PDT 2007
Some preliminary thoughts in looking over the ScanlineConverter...
- It does quite a lot for such a small piece of code - very cool.
- 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
- 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
- It ignores the winding rule of the path, shouldn't be too hard to add
support for non-zero winding, though.
- 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.
- 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.
- Since our pipelines manage clipping outside of the AATileGenerator,
the clipping code could be ignored when adapting this code as a plugin
for the AATG, so the above drawbacks won't have any immediate impact in
the short term and we can discuss them for longer term use when we get
to more extensive efforts at coming up with a new "best of breed"
renderer. In the end, I think we'll probably want to stick with our
Region based clipping for performance and ease of integration, but that
all remains TBD.
- 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.
- 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.
- 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).
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.
The one piece that neither my quick Region hack nor this Rasterizer that
you are offering here satisfy is an alternate implementation of line
More information about the graphics-rasterizer-dev