Chet Haase's Blog

September 2004 Archives

Tiger on the Desktop

I know Tiger's getting a lot of press lately (after all, we don't ship a new major Java release that often) and that there's a lot more about the new release than the graphics end of things. In particular, with a platform whose language changes so little and so infrequently, the types of changes introduced in Tiger are pretty substantial and attention-grabbing.

But still, there were some features that we worked on in the desktop client area of the platform for this release and if I can push! just squeeze shove! my way through the teeming throng of Tiger admirers, I'd like to mention a few of the highlights.

First, I should point out that on nearly every release, most of the work we do on the desktop client goes into things that don't percolate up into "features". This basically means fixing bugs, speeding things up, supporting any new platforms, and just making the existing platform run better every release. We've heard, loud and clear, that stability is one of the top requirements for our users, so the number one priority around here is quality (and everything that goes along with it, including making performance better and better, but not at the cost of core functionality).

Nonetheless, we do eventually get to work on new, cool stuff to enhance the platform. It's that stuff that I'll be discussing today.

The main things on Swing's feature parade for Tiger were some new Look & Feel features as well as table printing. I also have to add here my favorite feature: JFrame.add().

• Look & Feels

  There were two significant improvements in the Look & Feel area: Ocean and Synth.

  • Ocean

    The first was an update to the cross-platform look & feel. This one hasn't changed since the introduction of the Metal l&f. It had been a few years, that l&f was beginning to look a bit dated, so we worked on a more modern theme called "Ocean".

    One of the primary goals with Ocean was to Not Break Stuff. So now adjustments were made to the l&f which would have broken existing applications; the sizing of widgets is the same and everything should just work out of the box; it's just the skin of that l&f that's different (and, I think you'll agree, better).

    Users will get the Ocean l&f for free; an app that is run against 5.0 will pick up the Ocean l&f. Note that an app that subclasses Metal, or has other dependencies upon that look & feel, will still get the old Metal look & feel; again, backwards compatibility is the Prime Directive here.

  • Synth

    In addition to simply updating the cross-platform Java look & feel, the Swing team wanted to make it easier for developers to create newer, cooler look & feels for their applications. So they came up with synth, which is an architecture that makes it much easier to create new skins for applications, either through static XML definitions or programmatically through Java. I will leave the details of this approach to the experts; for more information on Synth, check out The Synth Look and Feel by Scott Violet on javadesktop.org.

• JTable Printing

  Don't you hate it when you've got a great GUI with some awesome data in it and you can't output that data in any other place that the screen? The Swing team thought so too, so they made printing work with JTable. Enough said.

• JFrame.add()

  The Swing team didn't call out this item when I asked them for their Tiger highlights, but it's probably my favorite Tiger feature in Swing and maybe the entire Java platform. Okay, so perhaps that's overstating it a bit. But I like it a lot in any case.

  Previously, you had to do the following to add a component to JFrame:

  	JFrame f = new JFrame();
  	f.getContentPane().add(someComponent);
  

  This is because of the Swing containment hierarchy; you cannot add a component to the JFrame itself, but only to the pane inside the JFrame which is tasked with being a container for sub-components. However, it was always awkward to have to remember that nuance and have to deal with Swing's containment hierarchy at this level. Well, they've fixed it. Now you can simply do this:

  	JFrame f = new JFrame();
  	f.add(someComponent);
  

  Internally, it's doing the same thing as before, only it's now handling the pesky containment details for you instead of your having to deal with it in your code.

Here are a few of the more significant features that you might notice about the graphics engine in Tiger. For more information on 2D Tiger features, check out our Release Notes.

• OpenGL

  This is an item that's not going to be apparent to most users right now, but should be an exciting thing for some developers and a taste of the great things to come, in terms of Java2D hardware accelerated graphics.

  We worked hard to enable nearly all Java2D functionality through hardware-accelerated OpenGL graphics on all Sun Java platforms (Solaris, Linux and Windows). This means we get accelerated graphics performance for such things as simple GUI operations (filling rects, drawing lines, copying buffers, caching and copying text glyphs as images, and so on), but we also get acceleration for way more interesting (and currently time-consuming) operations such as gradients, translucency, anti-aliased text, and transforms. This means that typical Swing applications work well, but more advanced 2D graphics apps just fly!

  There's a pretty big BUT here that I have to stick in at this point: this stuff all works extremely well ... except for the fact that OpenGL support on various platforms, graphics cards, and driver versions can be, er, less than optimal. Some of the problem lies with the way that we use the API and the types of features and performance we need; for example, we require different capabilities for Swing's back buffer than a typical GL app requires for its double-buffering operations. Some of the problem lies with the cards or drivers themselves; they simply have bugs that we tend to trigger (because we use the GL API in different ways than, say, Doom3 or other typical OpenGL applications).

  The net result is that we have an excellent implementation whose vast powers ... lie untapped by default. You can play with the OpenGL implementation by passing in a command-line argument to tell us to enable it:

  	java -Dsun.java2d.opengl=true 
  

  or you can set the same system property in your main() method:

  	System.setProperty("sun.java2d.opengl", "true");
  

  But otherwise, our OpenGL acceleration is disabled by default.

  But don't fear; I wouldn't have bothered mentioning it if it weren't way cool. Not only does it provide excellent benefits in the right situations now, but it also provides the necessary building blocks for us to have this kind of acceleration enabled by default on future releases. So it only gets better from here...

  For more information on this OpenGL renderer, check out the information in The OpenGL section of our Release Notes.

• Managed Images Everywhere!

  We introduced the concept of Managed Images in jdk 1.4. Basically, if you happened to create your images in certain specific ways (including Toolkit.getImage(), Component.createImage(w, h), and GraphicsConfiguration.createCompatibleImage(w, h)) then we would try to create accelerated, cached versions of the images underneath from which we could then do hardware-accelerated image copies.

  This system worked great for users of those particular APIs; developers didn't have to hassle with the management aspects of VolatileImage in order to enjoy the benefits of hardware accelerated image copies.

  But why the restrictions on which method calls you had to use? Why couldn't developers get the same benefit regardless of how the image was created?

  It was all a matter of just getting around to it. So in Tiger, we finally did.

  Now, you can create an image any way you like (including new BufferedImage(...)); if we can accelerate it, we will.

  Note that there are other things that can complicate the life and performance of a managed image; if this is a topic that interests you might check out these blogs on Images and this article on Intermediate Images for more details about image performance.

• Font Rearchitecture

  This is another "internal implementation" detail, but one which some users will definitely notice.

  The main work here was to take crufty old native code and move it up into elegant new Java code. This doesn't benefit the developers directly except that it makes the code much cleaner and easier to maintain (read: you'll get your bugs fixed faster and better).

  The real noticeable benefit of this change was that we removed threading constraints in the old code at the same time. Previously, much of the text processing was done in a synchronized fashion so that only one thread could access that key code at a time. This meant, for example, that an application rendering text to many different images at the same time would bottleneck in this code waiting for access.

  In Tiger, this constraint is removed and the font code is now Multithread Happy. Imagine the super-scalar servers that can now take advantage of all of those processors cranking away on text rendering simultaneously...

• CUPS Printing Support

  For the Unix printing fans out there, we now have CUPS support!

• ImageIO: plugins and performance

  We added a couple of key image format plugins in Tiger: BMP and WBMP (apparently popular image formats on some niche platforms; who knew?). We also worked on some major performance bottlenecks in image loading so the library is faster in some key areas.

• Startup performance

  The platform overall enjoys some serious startup improvements in Tiger. Small parts of those improvements came in the graphics arena, in the way that we were loading and initializing things that could have been done faster (and now it is).

  There's still a ways to go toward Startup Performance Nirvana, but we're making progress.

• Miscellaneous Performance Tweaks

  There were fixes in some rendering niches that are worth mentioning:

  • Primitive batching on Windows: we are smarter now about how we batch up line rendering calls when using our Direct3D renderer on Windows. This reduced the (significant) overhead per line and got us up to a 10x improvement in micro benchmarks (your mileage will vary; the biggest improvement will be seen when you issue all line calls together, not interspersed with other types of rendering operations).

  • Complex clip rendering speed was significantly improved in Tiger.

  • Footprint reduction for Toolkit images: We used to create intermediate images in our Toolkit image code which tended to bulk out the Java memory heap footprint. We've reduced much of that unnecessary garbage and got some pretty big footprint reductions as a result. Images tend to take up a pretty huge amount of memory (imagine: a buffer the size and depth of an average screen today takes about 5 megs of memory!), depending on the size and depth of the image, so saving the number of copies sitting around on the heap can help things out quite a bit.

There were lots of bug fixes in the AWT arena for 5.0. There were also a couple of areas of major functionality work. For more information on all of the AWT-related fixes and features in Tiger, check out the 1.5 AWT Release Notes. Here's a quick take on some of the larger items implemented:

• XAWT

  AWT was reimplemented on both Solaris and Linux to avoid being tied to the old Motif widget library system. The new XAWT toolkit was implemented using only Xlib, with a minimum of native code (and thus a minimum of native platform dependencies). XAWT is now the default on Linux, but Solaris still defaults to the Motif implementation for now. The default for either platform can be altered by use of the AWT_TOOLKIT environment variable or the -Dawt.toolkit command-line parameter; values for both can be set to either sun.awt.X11.XToolkit (for XAWT) or sun.awt.motif.MToolkit (for Motif). You can read more about XAWT at http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/xawt.html

• X Drag and Drop

  Prior to Tiger, only Motif Drag and Drop (Motif DnD) protocol was supported on X11 platforms; now we also support the XDnD protocol. XDnD is a common feature on Linux and Java Desktop System platforms because of its support by GTK and Qt.

There were a few interesting (and huge) features added to our internationalization offerings in Tiger. For more information on these features than the blurbs below, check out http://java.sun.com/j2se/1.5.0/docs/guide/intl/enhancements.html. You can also get information on internationalization support in general at http://java.sun.com/j2se/corejava/intl/index.jsp.

• Multilingual Fonts

  In the past, logical fonts were monolingual or maybe bilingual. This means, for example, if you were running in a Japanese environment, you could display Japanese and English text, but not Arabic or Chinese. To use a different language, you'd have to quit the application, change a few environment settings (the LANG environment variable on Unix or the language selection in the Regional Options control panel on Windows), then restart the application. This made life difficult, for example, if the application you were using was an IDE, and you were using it to develop software that was localized into multiple languages.

  With the multilingual font configurations in Tiger, all you have to do is install fonts for all the languages you care about on your system and the JRE will use them all together when rendering with logical fonts. Note that today's operating systems usually come with support for many languages on their installation CDs - all you have to do is ask for that support to be installed. The list of writing systems that the JRE will support when provided with the necessary fonts and input methods is at http://java.sun.com/j2se/1.5.0/docs/guide/intl/locale.doc.html.

• Unicode 4.0 Support

  Character handling is now based on Unicode version 4.0 and there is also support for supplementary characters. For more information on supplementary character support, check out the article at http://java.sun.com/developer/technicalArticles/Intl/Supplementary/.

• Big Things

  The DecimalFormat class now supports BigDecimal and BigInteger.

• Vietnamese Support

  After a successful grass-roots campaign on the bug database (2517 votes on one of the bugs!), we have finally added support for Vietnamese in the java.util and java.text packages.

• Native Unicode Usage on Windows

  We now use the Unicode features of the native platform on Windows, which means we can now handle text in some components without restrictions on Windows locale settings.

That's about it, or at least that's the most visible part of our work on Tiger. We hope you enjoy it, and continue to send us feedback on what else you'd like to see in the future.

Happy Hacking!

Intermediate Images

This work is licensed under a Creative Commons License.