Swing gets even slower by using Vector Graphics

In previous posts I've lamented how Swing had great potential to capture the hearts and minds of GUI developers, but stubbornness on not using native widgets and a bad implementation means they have forfeited GUI applications to competitors like .NET. Most new thick GUIs that our financial clients ask us to develop are .NET GUIs (C# is the language of choice).

I was reminded recently of the pitfalls of the Swing draw-each-widget-pixel-by-pixel approach when I used a simple GUI like JConsole to access an application that I was JMX-ising:


Horrible refresh problem. Swing applications seem to be much more prone to this than native applications.

Can I blame this on the pixel-by-pixel approach, or just Swing's implementation of it? One other implementation of pixel-by-pixel that I played with a few years ago is Thinlet, a remarkably tiny GUI toolkit. I have never put a Thinlet application into production (only recently have clients gotten comfortable with the LGPL license), but I was impressed with the speed of it.

Recently I read an article Nimbus, a new sexy look-and-feel that the Sun Swing engineers are working hard on. When I read that Nimbus used vector graphics I cringed. Even with faster CPUs I bet the performance will still be similar to the current pixel-by-pixel approach. i.e. sucks

Don't get me wrong. Having a vector graphics option is good for some GUIs, but I really wish Sun (or whoever ends up driving the GUI side of Java) would also standardize a fast GUI toolkit. SWT is one option. Thinlet is another.

It is also interesting to note that Android, Google's Java-based framework for developing mobile phone applications, does not include any of the standard AWT or Swing libraries, instead using OpenGL C/C++ bindings.

Shame Sun, Shame for missing the opportunity to take over the desktop.