Native text rendering in Swing applications – followup with Steve Northover

January 9th, 2008

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.