I'm starting to look at this now, but first I wanted to give some
feedback on the technical notes below:
Roman Kennke wrote:
I finished up what I wanted to add to my rasterizer and want to make it
available to anybody who would like to review it or play with it. You
can download the code here:
http://kennke.org/~roman/rasterizer-rkennke-2007-05-24.zip
Technical notes:
- The entry point is the ScanlineConverter class. I have an instance of
this in my Graphics2D implementation and store it as a thread local
I'd rather see it stored in a global cache so that we don't leak one if
a thread does a little bit of rendering and then goes off to do only
non-rendering tasks from that point onward.
- In order to convert this information to the tiles that you need, it
shouldn't be too hard to implement a Pixelizer that aggregates a couple
of scanlines into tiles. The interesting task here is to do this
efficiently.
If we stick with a 32x32 tile size to be kind to the current tradeoffs
in the OpenGL pipeline then it would need enough memory to rasterize 32
scanlines at a time. That's not huge, but it would be nice to do
better. For the short term, I think it would work nicely.
- The rasterizer is a generic Shape rasterizer. I believe it is very
efficient for rasterizing arbitrary Shape objects, plus transform and
clipping. It uses a sophisticated scanline algorithm (if you want it, I
can write more about this, but this is going to be a small essay
then.. ;-) ). However, it is not (yet) optimized for certain frequent
special cases. Most importantly, I think lines and rectangles could be
done much faster in certain settings. I'll add that in the future.
It would be nice to have special case rasterizers for common objects if
they can be managed in a small space.
I'll probably see as I review the implementation, but one question I
have off hand is whether or not it handles STROKE_NORMALIZE vs.
STROKE_PURE? Also, does it work for stroking shapes directly, or does
it rely on BasicStroke.createStrokedShape(), or is there another
rendering process entirely for stroked shapes?
- Most calculations are done using fixed point arithmetics (that's
because the original target have been platforms without FPU). I don't
know if that does any good for performance on usual desktop systems, but
it won't do any harm either.
I think that all of our code uses fixed point in the final rendering
loops, but it does most of the geometrical calculations in float or double.
We are currently evaluating another renderer from the embedded group
that also converts to fixed point very early on.
One of the things we would have to evaluate for either body of code long
term is if it can deal with large coordinates gracefully or if it
overflows or crashes. Our current code has (mostly, if not entirely)
been vetted to deal with arbitrarily large coordinates (I say mostly
because I don't know that we have full coverage on the testing of that
support yet).
Long term we'd also like to share a rendering system with the embedded
markets that would have the same restriction that you were worried about
- missing or very poorly performing FPU. We may want to have one body
of code that can work both ways depending on the target for a given
integration - but that may involve either doing it all natively or
coming up with some kind of Java preprocessor so the code could be
refactored for different numeric strategies prior to compilation.
- Datastructures are reused in almost all cases. That means that the
scanline converter doesn't allocate any new memory once it has its
datastructures set up after a couple of rendering cycles. New
allocations only happen when the datastructures need to be extended
(e.g. for extraordinary complex shapes).
How large can this grow? Is it a potential problem if a program draws
one really really huge shape and then goes back to really small shapes
for the rest of its lifespan?
...jim
