This note’s for you

I did a run of GNU Classpath’s AWT and J2D benchmarks. The results are more fair now (JDK6 vs Cairo vs X/Escher). Cairo now beats the X peers, but the overall speed is still impressive given that it’s done all in java. I guess my own small benchmark was a nuance too artificial

Some more numbers for you as followup to my last measurements:

• jdk6: ~750ms
• my latest improved Escher/Java peers on Cacao: ~200ms

I wonder what Sun did to the shape renderer in jdk6. It’s quite slow compared to JDK5 and even much slower than the Escher peers. And that is without antialiasing just like the Java renderer. Probably this has to do with their work on the text renderer (which is even slower - ~1600ms - as it uses AA by default now).

It would be interesting to see how fast the Escher peers would run on hotspot. I’m thinking that a significant part of the performance gap between jdk5 and the escher peers is due to the performance of the VM itself as the escher peers and the shape renderer run comletely in java. Unfortunately it’s not trivial to port the peers to Sun’s JDK due to the few differences on the peer API. I’m still hoping that somebody will get hotspot running with GNU Classpath.

I rewrote the java based rasterizer that is used in the X peers of GNU Classpath. Heres some interesting numbers. Rendering a relatively complex shape (actually, the outline of a glyph vector) 250 times takes:

• ~60ms on JDK1.5
• ~780 ms on Cacao with the Cairo peers
• ~350 ms on Cacao with the X peers and the new Rasterizer

Learned lesson: native code is not necessarily faster than java code. The whole rendering pipeline of the X peers is implemented in plain java. X only draws horizontal lines here.

The comparison with the JDK is not necessarily fair but gives an interesting impression what should be possible.

Find the test program here. Yes it is a microbenchmark that highlights one particular case (rendering complex shapes). I will make more interesting and comprehensive benchmarks as soon as I am able to run the Java2D and AWT benchmarks that ship with GNU Classpath.

After some more tweaking in Escher and Twisti implementing a shiny new feature in CacaoVM (disabling assertion checking with -dsa/-ese,THANKS Twisti!) the Escher graphics performance could be nearly doubled again, coming closer to the JDK performance. Lesson learned: when putting asserts in performance critical code, make sure you disable them when doing real stuff. And never do assert read() == bla, or something similar, you can’t be sure that the read() is actually executed. Find updated useless stats here. For the sake of at least some fairness I also updated the Cairo results to account for the new CacaoVM. It doesn’t have such a great impact there though.

In the last couple of days I rewrote some core parts of Escher, making it much faster than before. I changed the way how Escher dispatches the X commands to the X server, and according to these AWT 1.1 Graphics benchmark results, it is now ~3 times faster than before. Also included in this benchmark are results for JDK and Cairo based peers for comparison. This shows that the Escher peers are ~3 times slower than JDK, and the Cairo based peers are again ~5 times slower than Escher. This comparison is not quite fair though, because JDK and the Cairo based peers implement Graphics2D which works differently than the AWT1.1 style Graphics. However, first tests with Graphics2D on Escher/GLX show that it is very likely to be faster than the current AWT 1.1 style implementation. Well, no surprise really, it’s OpenGL accelerated…

Today I’ve checked in my Escher based X peers in GNU Classpath. This AWT peer implementation is done completely without native code and connects to an X server directly via TCP or Unix sockets. It is capable of running many Swing apps, does AWT 1.1 style graphics and fonts and is quite fast.

The next step will be a Graphics2D impl on top of Escher’s GLX implementation. This will be quite some work, especially because OpenGL doesn’t support all features that Graphics2D requires, like clipping against arbitrary shapes, stroking and - most importantly - filling arbitrary polygons (these need to be tesselated into triangle-like things before). Also, this depends on some serious work on Classpath’s TTF font implementation, I need to add hinting in order to get smaller glyphs rendered without making the viewer blind