[OpenJDK Rasterizer] Rasterizer replacement proposal
Phil.Race at Sun.COM
Thu May 24 16:27:01 PDT 2007
Thanks for this. Jim Graham is the best person to comment
on this but he's on vacation until next week some time.
And congrats on getting married.
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:
> Legal note: Right now this is ripped straight out of GNU Classpath, to
> which this code originally belongs. It is licensed under GPL+exception.
> The FSF holds the copyright to that code through their copyright
> assignment thingy. However, I am the original author of all of the code
> and will do the copyright grantback procedure and sign the SCA (I think
> my employer (aicas) already did so for me even) to make this code
> available to OpenJDK. I would like to hear your opinion on the code
> first, though. If that doesn't look feasible at all, then I can avoid
> doing all that.
> 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
> variable. The 'frontend' is ScanlineConverter.renderShape(), the
> 'backend' is specified by the interface Pixelizer. The Pixelizer
> implementation is responsible for actually modifying the surface pixels.
> It gets called once for each scanline. The coverage information is
> carried by ScanlineCoverage instances. Use ScanlineCoverage.iterate() to
> get the actual coverage information, and use getMaximumCoverage() to get
> the scaling right.
> - 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
> - 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.
> - 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.
> - 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).
> I will still be around tomorrow, and starting from saturday I will be
> offline for 2 weeks (or, at best be online sporadically) because I'm
> going to marry, yay! If you have urgent questions it's a good idea to
> ask them ASAP. Otherwise, I'll be curious to hear your opinions in two
> weeks then.
> Cheers, Roman
More information about the graphics-rasterizer-dev