Following the last few entries on using SWT for native text rendering in Swing applications under the Substance look-and-feel, i was contacted by Steve Northover (technical lead of the SWT project) with a few suggestions. First, to recap the relevant entries up until now:

• The introduction showed a few screenshots of rasterizing the default Vista Segoe UI font in Swing and SWT.
• The next entry showed some of the implementation details of the interaction between the two UI toolkits.
• The “ready, steady, go” announced the official stable plugin version, along with much simpler deployment, support for WebStart environment and more.
• The last entry showed some quirks of rendering vertical texts.

Steve’s first suggestion was to go over the code and make sure that all SWT resources are properly disposed. While this has been considered as one of SWT’s weaker points (something along the lines of “it’s Java, why do i need to explicitly dispose resources”), this is hardly any different from Graphics2D.dispose or even explicitly closing DB connections, streams, files etc in usual Java programs.

If you don’t call the dispose() method of all allocated SWT resources, you can run into the “No more handles” error. While usually it takes quite a while to get there, the native text rasterizer would encounter it fairly quickly (about 5-6 resources are allocated for each text painting in the current implementation). While the text rasterizer itself is disposing all its resources, the test applications did not. This has now been fixed.

The second suggestion was to strip away unnecessary classes from the SWT jar. While this jar is by no means huge (clocking in at about 1.3MB), some people would cringe at this figure. First, i would like to enumerate the reasons why i don’t recommend stripping away the contents of swt.jar (as detailed below):

1. While the license permits it (and the whole plugin is under EPL), i’m rarely comfortable in stripping away contents of third-party libraries. When i upgrade to the latest release, i can eliminate at least one possible source of incorrect behavior (if something weird happens).
2. The swt.jar for Windows has quite an acceptable size for the functionality that it provides. For example, the main Substance look-and-feel jar is about 1.7MB.
3. An application that decides to use this plugin might as well “profit” from other parts of SWT, as illustrated by Chris Deckers’ posting on Javalobby. This way, the two libraries can share the same swt.jar.

Having said that, it is possible to strip the swt.jar to as little as 430KB. There are two ways to do so – the approach recommended by Steve, and the aggressive approach that resulted in the current swt-win-stripped.jar available from the CVS repository.

The recommended approach is to work on the package level, removing those packages that clearly are not required for the text rendering. The minimum set according to Steve is org.eclipse.swt.graphics, org.eclipse.swt.widgets, org.eclipse.swt.internal, org.eclipse.swt.internal.win32 and org.eclipse.swt.internal.gdip (for GDI+ operations such as tranformations for the vertical texts). In addition, the swt-win32 and swt-win32-gdip DLLs (for Windows) need to be in the stripped jar. Furthermore, Steve mentions that the org.eclipse.swt.events and org.eclipse.swt.accessibility might be needed for corner-case scenarios, such as switching the OS theme while the program is running (correction from Steve – these are needed to compile a stripped SWT jar from sources).

However, you can take it a little bit further and remove additional classes from the org.eclipse.swt.widgets (pretty much everything that concerns actual components, since these are not needed for the text painting and image manipulation for this plugin). Take a look at the contents of this package in swt-win-stripped.jar in the CVS or the distribution zip to see what has been left. This is what brings the jar size down to 430KB.

As an “extreme” measure, one can go even further and start stripping unnecessary functionality from the DLLs, org.eclipse.swt.SWT class and org.eclipse.swt.internal.win32.OS class. Do at your own risk.

Note that while this entry talks about the Windows version of SWT, the same applies to other platforms as well (which would have a different structure of org.eclipse.swt.internal package and different bundled native libraries).

I’d like to thank Steve Northover for his comments and time.

The Substance watermark pack comes with the functionality to generate fractal flame watermarks. While it takes considerably more time to create these watermarks (about 15-20 seconds on a decent machine), the visual results are certainly worth it, even outside the original goal of using the fractal flame images to add watermarking capabilities to Swing applications. I have just added a random generator that allows quickly creating and sieving out interesting fractal flames, and here are my weekly favorites:

Hopefully, in the not so distant future i’ll be able to find time to create a WebStart-able editor so that you won’t have to download the binaries.

In addition to about twenty core Substance themes, the theme pack plugin provides even more themes to create a unique look for your Swing applications. When you put the binary plugin in the classpath, the additional themes become available in the getAllThemes() API, and you can use them just like any other core theme.

As part of updating the licensing headers to 2008, i’ve also updated the screenshots of extra themes to reflect the latest visuals of Substance. Here are some of my favourites:

Belize

Brick Wall

Fauve Mauve

Mahogany

Orchid Alloy

Yellow Marine

The subject of native text rendering in Swing applications has been introduced on this blog about six weeks ago, and I already described some of the implementation details. The devil is, of course, in details (unless you’re working on whizzy demoes), and i’ve spent the last month working on all the issues mentioned in the original post. This post addresses the functionality that has been missing, talks about the unsupported cases and links to a WebStart demo (at the end).

Easier deployment and support for WebStart environment

With migration to release 3.3.0 of SWT and valuable help from the SWT dev mailing list (thanks, Dave), it is now much easier to configure Bramble and SWT. Browse to the SWT main page, download the relevant distribution (Bramble distribution bundles the Windows version) and add the swt.jar to your classpath. That’s it – no more need to muck with the java.library.path VM flag and no need to extract the native libraries from the SWT jar (like was the case in 3.2.1).

To use the native text rendering in your WebStart application, take the latest substance-bramble.jar and the matching swt.jar, sign them and you’re ready to go. Note that if you’re using the jar from Eclipse itself, it’s already signed. Although it’s possible to use jars signed by different parties, I had security access exceptions on using the SWT jar from Eclipse. If you use the jar from the SWT main page, it works flawlessly (see the WebStart link at the end of this entry). If you need your application targeting multiple platforms, you’ll need to bundle the matching SWT jars and use the resources JNLP tag accordingly.

Support for all core Swing components

The latest binary and source drops of Bramble plugin provide support for all core Swing components with the following exclusions:

• Non-plain text components, including text panes and editor panes.
• HTML text.
• Titled borders.

The text on all these components (including HTML) is painted with the default core AWT text font rasterizer. The latest plugin version also provides support for painting rotated (vertical) texts which are used on vertical progress bars and sliders (with labels). Interestingly enough, the rotation transformations in AWT and SWT are different (rotation angles have opposite values, and hence the translation offsets are different as well).

Support for SwingX components

This will be done in the next Substance release. As a proof of concept, the latest SwingX plugin provides native text painting for the status bar components. As in the case above, all other SwingX components use the core AWT text font rasterizer.

Support for additional operating systems

While the primary target of Bramble plugin is Windows Vista (and the inadequate AWT rasterizing of the default “Segoe UI” font), this plugin is not Windows-specific. It has been successfully tested under Windows Vista, Windows XP, Windows 2003 and Ubuntu 7.10. If you encounter bugs (visual or exceptions) under other platforms (KDE, Mac and others which are supported by SWT), I would be very interested in hearing about it.

Incidentally, using the native text renderer can not only make the applications look better. The core AWT font rasterizer has its own bugs (as all software does). This bug report opened on Substance (under Ubuntu / Gnome) is caused by a bug in the default font rasterizer that fails on a specific non-Latin character (see the bug report for more details). Since this happens under the core GTK look-and-feel and Substance provides the platform-specific font policy lookup that is aligned with the GTK LAF font lookup, this bug is seen under Substance as well. While the visual quality of the AWT font rasterizer on “DejaVu Sans” is very close to the native text renderer and there isn’t much reason to bundle SWT and Bramble, at least in this case doing so makes the application run with no exceptions and look like it belongs to the specific desktop.

Under Windows Vista, the Bramble plugin will also instruct Substance to use “Segoe UI” font under JDK 5.0 as well. Unlike the AWT font rasterizer that did even worse job under JDK 5.0, the native text renderer doesn’t care. So, you don’t have to upgrade to JDK 6.0 to have your applications look good on Vista.

Demo

Clicking on the button below will launch the full Substance test application that uses Bramble plugin to render all the texts with the native renderer. Note that while the application itself is cross-platform, this specific JNLP file only uses Windows version of SWT (no need to leave comments that this specific JNLP doesn’t work on Ubuntu or Mac). It is signed since one of the tabs shows the file system tree. As you’ll see, the texts on the task panes (left hand side) do not have proper background – as mentioned earlier, full support for SwingX components will be added in the next release. So, click around and let me know if you see something fishy :)

You’re more than welcome to leave comments with your thoughts, suggestions and bug reports (but first make sure that you’ve read this entry in its entirety). The plugin is distributed under the Eclipse Public License (EPL). The release candidate is scheduled for January 21st, with the release scheduled for February 4th.