[OpenJDK Rasterizer] Rasterizer replacement proposal
roman.kennke at aicas.com
Tue Jun 12 10:42:59 PDT 2007
> The status on the pluggability API is that it is now completed and in
> our 2D integration workspaces waiting to go through the testing and
> promotion queues. The best current estimate as to when all of that
> process will be done is that it will probably appear on the OpenJDK
> project site the end of next week.
> In the meantime, I'm attaching a zip file of the javadoc output on the
> new classes so you can start looking at the API.
Great! I'll have a look at how to fit my rasterizer to this.
> Keep in mind that I
> mentioned earlier that this was not intended to be the eventual final
> API that allows alternate implementations to play nicely on a level
> playing field in the long run, but more of a stopgap temporary milestone
> on the road to producing an all-open JDK.
That's not a problem, actually I think it makes a lot of sense to
publish work-in-progress stuff rather than finished pieces of code,
because this way you get early review and testing. Working with the
community means including everybody in the process, not including
everybody in the finished product ;-)
> To that end, I identified
> basically just 3 places where our common code depended on the Ductus
> library and produced a very basic plugin interface containing 3 methods
> for those cases. The plugin has been tested with a NOP stub, but not an
> alternate implementation.
> From here I definitely want to start opening up the discussion for some
> more extensive work to plug in (or even replace) new renderers. I'd
> like our goal to be a fully open implementation that performs much
> better than the current collection of diverse rasterizers and not have
> separate production vs. open implementations moving forward...
I'd propose to start with the 'fully open' aspect and move on to the
'performs much better' aspect then ;-)
The next logical step from my POV would be:
- to figure out the copyright thing and start the grantback procedure
with the FSF.
- the see how the rasterizer could fit with the documented interface
- to figure out the legal issues and hopefully review my code when my
SCA is on file and the grantback procedure started.
- implement and/or publish tests against the documented interface
together with the ductus library, to be able to test and compare
alternate implementations for correctness, precision and performance.
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
More information about the graphics-rasterizer-dev