This note’s for you

The last couple of days I spent going through the AWT peer interfaces and cleaning them up (get rid of all the duplicate and deprecated stuff there), and have now started to document the stuff. The first results can be found here. For now I only have ButtonPeer to ComponentPeer, but I will add the missing stuff during the next couple of days, and I will also add all other classes that are necessary and/or helpful (like Toolkit, GraphicsEnvironment, and some internal classes).

I’m also very excited about Mario’s work with JOGL and Escher. This is so amazing to see (start) working.

Another day, another non-existent problem solved Seriously, the font problems I’ve seen yesterday have been kindof bad luck. Wrong font has been chosen by the pipeline, one that doesn’t render smooth as bold font. Plus some small problems in OpenJDK and/or FreeType regarding rendering this font, etc. Today I tried the Font2DTest program of OpenJDK and most fonts look just fine:

This is Bitstream Vera plain without anti-aliasing. Pretty smooth. The font we’ve seen yesterday has been FreeSans bold:

Which also looks slightly crappy with OpenJDK’s default pipeline:

BTW, it’s really amazing how well Swing applications already work. There are only very few glitches (no mouse drag yet for example) and performance seems reasonable (not quite on par with the OpenJDK X11, but still). And all this with minimal effort on my side, I really only implemented a handful of primitives and a little infrastructure. Yay OpenJDK Java2D architecture!

Today I finally solved a non-existant problem, and can finally show some stuff from the OpenJDK challenge work:

The demo already works quite well and performance is reasonable. Of course, there are still many quirks and etches, and the fonts look like crap. Not sure yet, why the fonts look so ugly, I have to find this out. This is using OpenJDK rendering pipeline and does all the rendering in pure Java (over Escher).

A while ago, our (Mario and me) project proposal for the OpenJDK Innovators Challenge has been accepted. Today I’d like to announce the actual project, codenamed Caciocavallo. This project will cover a couple of things:

• An implementation of the AWT Toolkit interface (java.awt.peer and a bunch of classes in java.awt), that doesn’t make use of Sun internal classes.
• An implementation of the AWT Toolkit interface that subclasses Sun internal classes and reuses most of the infrastructure. (This is named Caciocavallo-NG)
• Patches to OpenJDK to enable the above Plus better documentation, etc.

The toolkit implementations will be based on the great Escher library. So far we have (somewhat) working prototypes for both the ‘external’ and ‘internal’ implementation (that’s how I call them). Also, I reworked a significant portion of Java2D, to separate SunGraphicsEnvironment and FontManager. So far, the FontManager class was a final class, with most of the platform dependent font stuff in the subclasses of SunGraphicsEnvironment (urgs), and some more platform dependend stuff in FontManager itself (uuuuuurrrgs: look into FontManager.populateFontFileNameMap()). I changed it so that FontManager is an abstract class, with platform specific pieces in subclasses. SunGraphicsEnvironment doesn’t have any font stuff anymore. Works like a charm already.

Until the project is setup within OpenJDK (soon), all the code resides on my server. There’s caciocavallo and caciocavallo-ng (the external and internal toolkit implementation respectively) and a HG patch queue (what a nice feature of HG that is!!) for OpenJDK.

BTW: I spotted a fun part in the affidavit (new word learned) of The Challenge:

I understand and acknowledge and hereby waive and release any and all rights, demands, losses, liabilities, claims and causes of action whatsoever which I may now or hereafter be entitled to assert, including, but not limited to any death, injury, loss of enjoyment or other harm or loss of any nature whatsoever caused by, contributed to, or arising out of any prize awarded to me in this Contest.

I guess this means I can’t sue Sun when I get a heart attack from the price money, or when I don’t enjoy hacking OpenJDK anymore afterwards. Too bad Ok, now on with hacking (so many things to work on parallel, I need some clones of myself)

Today I discovered to my surprise, that the X peers of OpenJDK also use Swing as painting backend for its widgets (as opposed to the Motif peers that use Motif or Lesstif or whatever). Unfortunately, this doesn’t seem to be done in a very reusable way (==hardcoded in the X peers), as I did with my own Swing peers in GNU Classpath. I mean, it is really nice to have this reusable, because then, implementing a new backend for AWT is basically only implementing the top level components and graphics stack. I wonder, if these could be merged somehow, i.e. the reusability of my Swing peers with the completeness of OpenJDKs X peers. Hmmm, this would have been another nice proposal for the OpenJDK Innovators Challenge….