Native text rendering in Swing applications – ready, steady, go!

January 2nd, 2008 | 12 Comments »

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.

Related posts:

  1. Native text rendering in Swing applications Yesterday i posted six screenshots divided in two groups and asked what is the difference....
  2. Native text rendering in Swing applications – followup with Steve Northover Following the last few entries on using SWT for native text rendering in Swing applications...
  3. Native text rendering in Swing applications – how does it work? Two weeks ago i wrote about the first drop of Bramble plugin for Substance look-and-feel,...
  4. An interesting bug in Java2D text rendering I’ve started playing with custom alpha channel settings for certain component states. Look at the...

12 Comments on “Native text rendering in Swing applications – ready, steady, go!”

  1. 1 Theodor B said at 1:42 am on January 2nd, 2008:

    Hi Kirill, just tested the demo and I was very impressed with the way the Swing components render the text. Native text rendering is the way to go, anything else is sub-optimal and thus unnaceptable.

    One of the reasons I use Eclipse instead of Netbeans is the text rendering, being native on Eclipse producing a much better experience consistent with the rest of the operating system. Taking into account how many hours do I stare into the text editor, for me this is very important.

    Keep up the good work and hopefully someone at Sun notices you work and actually does something to improve the text rendering in Swing.

  2. 2 Guillaume Laforge said at 2:17 am on January 2nd, 2008:

    I launched the demo on MacOS X (Leopard), and only some gray squares and such appeared. No text, no images or icons, no buttons (unless you hover them, but you only see the shape / gradients of the button)…

  3. 3 Alex Ruiz said at 7:32 am on January 2nd, 2008:

    Only one word: Beautiful!!

    The demo looks really nice! :)

    One little detail: the last character in the tooltip for the buttons “Iconify”, “Maximize” and “Close” is rendered too close to the right border of the tooltip (it is actually touching the border and getting a little bit cut.) I’m using Windows XP with “Segoe UI” font.

    -Alex

  4. 4 Fabrizio Giudici said at 8:27 am on January 2nd, 2008:

    Can you please post a screenshot for us without a Windows computer at hand? :-)

  5. 5 Kirill Grouchnikov said at 9:26 am on January 2nd, 2008:

    Guillaume – please read the paragraph just above the WebStart button. This specific demo is for Windows only since i didn’t want to bundle SWT jar for every supported platform.

    Alex – thanks for pointing out this issue. Are you sure that the font that you’re using is Segoe UI and not Tahoma? Substance installs Segoe UI only under Vista, so unless you’re installed and configured XP to use Segoe UI by default, it should be Tahoma. I did some special handling for smaller baseline fonts (Vista is 12 pixels and XP is 11 pixels, since SWT uses points and not pixels). I’ll take a look at the tooltips on my XP box.

    Fabrizio – you can find screenshots in the introduction and implementation entries posted earlier on this blog.

    Thanks
    Kirill

  6. 6 Mikael Grev said at 10:54 am on January 2nd, 2008:

    Very impressive Kirill.

  7. 7 Alex Ruiz said at 10:59 am on January 2nd, 2008:

    Hi Kirill,

    I manually installed Segoe UI on my XP box (I haven’t found a good excuse to switch to Vista yet :D )

    Cheers,
    -Alex

  8. 8 Kirill Grouchnikov said at 11:10 am on January 2nd, 2008:

    Alex,

    Can you send me a screenshot to kirillcool / yahoo / com so that i can see the base pixel size that is used by Substance under XP with Segoe UI as the default font?

    Thanks
    Kirill

  9. 9 Daniel Spiewak said at 12:45 pm on January 2nd, 2008:

    Sweet! I’ve been keeping an eye out for something like this for a long time now. It’s good to see. Do you have any ideas on how to provide native rendering for editor panes and such? My main use case is trying to make jEdit’s monospaced rendering (or NetBeans if you prefer) not suck so much on windows.

  10. 10 Kirill Grouchnikov said at 1:00 pm on January 2nd, 2008:

    Daniel,

    It’s just the question of resources. It is most certainly possible to provide native text rendering for editor panes, text panes and HTML texts. The first two can be done by installing the relevant editor kits that provide the view implementation that uses the Substance text painter layer to paint the text (instead of using Graphics.drawString or SwingUtilities2 methods to draw characters).

    It’s just that the relevant views are quite complicated, and there are so many of them (and some are package-private so subclassing is out of question), that at least at the present time I have to leave it for the community to investigate.

    Thanks
    Kirill

  11. 11 Luke Sleeman said at 5:34 pm on January 2nd, 2008:

    It is possible to have one .jnlp file work on windows, linux and mac even when using SWT. You just have to enclose the reference to swt.jar inside resouce elements that are OS specific, like so:

    Then it should all just work…

  12. 12 Kirill Grouchnikov said at 5:39 pm on January 2nd, 2008:

    Luke,

    I think that your XML was cut away by WordPress. In any case, i didn’t say that one needs multiple JNLP files, and the relevant section of this entry links to the JNLP syntax on how to do this. I just didn’t want to have multiple SWT versions on my machine and in CVS, so this specific JNLP file is for Windows only.

    Thanks
    Kirill