True. However, the clipping can simply be ignored or ripped out of you
don't need this. Should make the code simpler and faster.
It won't be needed to satisfy the needs of the RenderingEngine plugin
API that I sent out a few days ago. Longer term we may want to stick
with Region clipping as well, but the other bullet items I wrote on the
subject will represent the start of a design discussion on that front.
- 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.
There really aren't many calculations to do in fp/double in the first
place. If you look at the code pointers I sent out they go straight to
integer incremental calculations fairly directly from the output of the
flattening code. The odd thing about what you had written is that you
actually caused quite a lot of floating point calculations to be done
when you asked the starting shape for a flattened iteration - that is
done by subdividing in floating point, which is a lot of calculations -
certainly more than are required to take the flattened results and
calculate scanline stepping values from it.
(With respect to the 2 pieces of code that I pointed you to, the
ProcessPath stuff is newer but rounds to integers right after flattening
the shape - the ShapeSpanIterator stuff is older, but it maintains
sub-pixel accuracy even as it traces the flattened outline. The primary
improvements in the ProcessPath stuff are the way that it traces the
curves to generate the line segments and how it deals with STROKE_PURE
vs. STROKE_NORMALIZE to keep the curves rounder...)
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?
My prototype doesn't perform well enough to be seriously considered. I
checked it into the workspace so that it will arrive in the OpenJDK
repository (hopefully) at the same time as the Pluggable interface does.
You will find it in src/share/demo/java2d/. It's mainly there to
prove that the Pluggable interface can be plugged with alternate code,
but in terms of a serious contender for the OpenJDK plug I think a
modified version of your code with the accuracy problems fixed and
turned into a pull technology instead of a push technology is likely
more promising from a performance perspective.
That, or the ME code that we've been evaluating internally, but that is
about as far from what we need as your code and it relies on fixed point
in a more systemic way that will be harder to factor out.
How's the read-only HG and/or SVN workspace for Java2D going?
I'm not working on that - I'll ping the people involved...
...jim
