Chet Haase's Blog

These Are Some of my Favorite [Mustang] Things

I've written about Mustang a few times already, but I thought I'd take the opportunity of the Mustang Beta Release to wax poetic about some of my favorite features in the release. This view is most certainly skewed, biased, and even subjective; there are a lot of cool things in the platform, but I specifically wanted to talk about the stuff that strikes my personal fancy, either selfishly because I had a hand in the feature or because I've used it already or look forward to using it someday (when I get time to write all the code I haven't gotten to yet).

My Favorite Features

If someone accosted me in the street, shoved a very large weapon in my face, and screamed “Tell me your favorite Mustang feature! Now!”, there would be no hesitation; I'd pass out.

But when I woke up, I'd definitely say...

Gray Rect Fix: This Swing feature is not only inherently cool from a graphics perspective, but it has the double advantages of real and perceived performance improvements. Real performance improvements kick in when Swing applications no longer need to repaint the GUI due to some invalidation on the screen; they simply copy the persistent back buffer to the screen. Perceived performance improvements, often more important than the real ones, are in the way that Swing windows are automatically updated from the back buffer instead of going through an erase/update cycle; even if the update cycle takes an insiginficant amount of time, the fact that the user did not see an erase (the gray rect) followed by the update is huge. Now, the “gray rect” erasure is replaced by a simple copy of the back buffer contents. This is one of the last holdouts of the tired old “Swing is slow” reputation; because it looked different than typical native applications during the erase/update cycle, users would interpret this as being slower. Now we're on a par with native applications (even faster in some situations, as many native applications don't do anything as sophisticated as double-buffering, and suffer flashing and slower updates as a result).

Faster, cleaner, more elegant, and cooler; how could you get a better feature than this?

For more on this feature, check out ScottViolet's and my blogs

Peabody: Okay, so this isn't a “feature” per se, but it's a really big change with Mustang from previous releases. Now, developers can get ahold of our development builds at the same time as we create them, see all the source code, build it, and even submit proposed fixes. This is way beyond where we've been in any previous release. Prior to Peabody, only licensees could see all of the source code, not many people on the planet could build it (or at least we didn't make it very easy), and proposed fixes would be necessarily limited to the code that people could view without being able to actually make the change and test it out themselves. I'm positive that this has contributed to both more awareness of what's in Mustang (since people are able to try it out) as well as more quality of the bits (as people try it out and are able to report problems). Sure, we're going into public Beta now, but in some sense, we've been in a rolling Beta since we started posting the Peabody builds on the site. This has reduced the lag between making a change, having it run in the wild, and finding out about problems that need to be addressed. Typically, this process takes months and involves layer upon layer of indirection between the engineers that did the work and the customers that tried it out. Now, we're able to implement a feature, promote the build, blog about it to tell people it's there, have it downloaded, tested, and get feedback directly to the developers; all within days of integrating the code. For example, check out the comments to Scott's Gray Rect blog; the same day that he posted the blog (which was just a few days after the Swing code was putback into the workspace) people were trying it out and giving us feedback on the feature. (Did I mention how much I like the Gray Rect feature?)

For more on Peabody, check out the mustang web site.

Single Threaded Rendering (STR): This feature moves Java 2D from a model of rendering immediately on aribtrary threads to one where we queue up requests at the Java level and execute them (slightly) later at the native level on a single thread. This feature is not as visible as many of the others in Mustang because it's not enabled by default. STR is implemented in the OpenGL rendering pipeline only, which is not on by default (due to various driver and hardware issues). But besides being extremely cool from a graphics software perspective (there are lots of issues of graphics state and large and complex primitive handling that had to be solved along the way), STR offers significant improvements both for the current OpenGL pipeline and for future rendering pipelines that will use this approach. OpenGL rendering benefits both in robustness (multi-threaded rendering in OpenGL tends to be a driver killer for many video cards) and performance (batching up rendering requests saves significantly in both JNI and OpenGL API overhead). In the future, we will use the STR approach in other rendering pipelines (such as the default DirectX renderer on Windows) and expect to see similar benefits.

For more on this feature, check out Chris Campbell's STR-Crazy and STR-Crazier blogs.

ImageIO Performance Improvements: This feature was a latecomer to the party; Chris Campbell did this work recently (and blogged about it recently as well). Our strong wish in Java 2D is for developers to start using the Image IO APIs for all image loading/saving operations and to move away from the old Toolkit approach. The ImageIO APIs are much easier to use (see my blog on using Image IO for easy image conversion, for example), much more feature rich, and are also where we are putting our current and future efforts in image loading and saving. The Toolkit APIs are old and crufty. Unfortunately, the Toolkit image loaders also happen to be faster in some important cases (such as loading JPEGs). Until we fix the performance issues, it's hard to convince people that Image IO is really a better approach. Finally, Chris looked into some of the issues here and made JPEG loading significantly faster than it used to be. Check out the nifty bar charts in his blog for the quick take on this.

For more on this feature, check out Chris Campbell's blog .

Native Look & Feel: There are basically two camps of Swing GUI developers: those that want a cross-platform look and feel and think that the Metal/Steel theme is dated and those that want a native look & feel and feel that we don't do a good enough job there. Okay, there's actually a third camp as well; there's also a silent majority of people that don't care deeply and are happy with whatever we offer.  But we're not talking about those folks here since their problems are solved. The Metal/Steel issue was addressed in Tiger, with the release of the Ocean theme for Metal (no more purply/bumpy widgets; it's all about cool, smooth gradients now).

The Native Look & Feel issue has continued to dog us for the last several releases.  In 1.4.2 we finally introduced both the XP and GTK look & feels and in Tiger we kept tweaking and improving things. In Mustang, we've made a major shift in both GTK and Windows to use the native widget rasterizer to get a truly native look. No, we're not using heavyweight widgets on these systems; Swing still has a lightweight widget model. But now, instead of Swing doing its own rendering of these lightweight widget images, we ask the native operating system to render the images for us, so that these lightweights look exactly the same as heavyweight widgets would. Combined with improvements in our text support (see below), I believe we're finally “there” for native look & feel support.

For more on this feature, check out Bino George's blog.

LCD Text: People have asked for some time for us to upgrade our font support to do better anti-aliasing on LCD displays.  In Mustang, we've done this. Not only do we now support this more complex anti-aliasing algorithm (which uses the RGB striping of LCD displays to enable sub-pixel rendering of the fonts; see my article Anti-Aliasing on the Fringe for geeky details on how this works); we also do more work at the Swing level to detect the desktop properties for anti-aliasing and set our default Swing anti-aliasing setting appropriately. Also, we now ask the font for information on appropriate anti-aliasing information given the size of the font; you'll notice that enabling anti-aliasing on the native desktop results in some text being anti-aliased and some not; this is because fonts actually have information about which sizes are appropriate for anti-aliasing and which are not (generally, small sizes of fonts don't look great with standard anti-aliasing, so fonts may specifically ask to be aliased at these sizes).

For more information on this feature, check out this blog on Phil's Font Fixes.

Table Sorting and Filtering: This is a handy feature that seems obvious once it's there; JTable now provides built-in support for sorting and filtering. This is functionality that many developers end up doing on their own in their JTable code. When JDNC began, they realized they needed this feature as well, so they did it on their own. It's like part of the initiation ritual for users of JTable, I think. Now Swing has folded in that capability into core so that everyone can just get it automatically.

For more on this feature, check out Scott's blog and this tech tip on java.sun.com.

New Modality: Modal dialogs in AWT have always had a behavior that was unexpected, when compared to typical native desktop applications. Now, through the new modality APIs, you get the behavior you expect.

For more information on this feature, check out this article on java.sun.com.

Splash screen: Applications end up implementing their own splash screen functionality, to mitigate the pause between launching an application and the application window actually coming up. Now, AWT offers this capability for free; you pass in the image and they'll display the splash screen. Not only that, but they'll do it in native code so that the splash screen can be displayed while the VM is still being initialized.

For more information on this feature, check out this article and tech tip on java.sun.com.

Desktop API: Integration with the native desktop is increasingly important for Java applications. The Desktop API allows a Java application to launch one of several typical native applications, all from within Java code. Your application can launch the native browser, the native mail client, any native document viewer, and more.

For more information on this feature, check out this article on java.sun.com.

Deployment Dialogs: A lot of the user experience issues around deployment have been vastly improved, from the splash screen we use for Java Web Start to the security dialogs that pop up when the user needs to approve some behavior. Scary security dialog no more!

For more on this feature, check out Stanley Ho's blog.

Wrap Up

As I said at the beginning, this is a purely subjective view of Mustang from my skewed perspective.  I haven't scratched the surface of the wealth of features offered in Mustang, from the whole host of features in the core libraries to improvements in the VM to other desktop features.  I would encourage you to read more about these features in the Core Java Technology Features article, in the Desktop Features article, on the Mustang site, and in the host of blogs and articles on the subject. 

But most of all, I would encourage you to download the Beta, download the regular snapshots, play with the release, tell us about any problems you have, and help us deliver a great release.

Comments

• thank you for this wonderful summary. this is awesome stuff. now, to fuel the early adoption of mustang: release a developer's notebook-length booklet on how to code the next generation rich client application with mustang, so no one has an excuse to say 'these features are not well documented.'

  Posted by: eitan on February 15, 2006 at 07:19 AM

• Nice summary, though I hope "The Metal/Steel issue was addressed in Tiger, with the release of the Ocean theme for Metal" was a joke you thought would match well. ;)

  Ocean is not at all better than Metal was. It reacts a little bit more to user interaction, but that's it. The colors are out of place, the borders look "wrong" on a modern desktop, and so on (actually, the complete Look is out of place for modern desktops.

  Other than that the new release will be really great and you've done a great job.

  Posted by: pago on February 15, 2006 at 08:22 AM

• Sounds like PR. Problems w/ native look and feel are a myth. It just has to look nice, which was fixed in 5.x. Same w/ Deployment dialogs, 5.x. Are you telling me nothing is new? SwingWorker is nice! Why not add GroupLayout to 6? .V

  Posted by: netsql on February 15, 2006 at 05:57 PM

• eitan Features are typically documented in a combination of the release notes and the JDK documentation (like the "New Features and Enhancements" section of the 5.0 docs). This time around, we've also got lots of these scattered blogs and articles detailing things in a one-off fashion. All told, this is a lot of information, but it's worth considering whether we should collect all of this stuff together in an easier fashion (even to collect a series of links to articles/blogs where we've already documented the features). I'll pass the idea along...

  pago Well, the Ocean comment wasn't an intentional joke... Part of the problems with Ocean are inherent in its requirement to be backwardly-compatible with Steel. If an application wrote to the Metal l&f and positioned its widgets and text in a certain way, then changes to things like border sizes, font sizes, spacing, etc. could throw the whole thing out of whack and cause these applications to break. So Ocean had a strict requirement to maintain the sizing of Metal/Steel, right or wrong. Beyond that, we try to provide good (and getting better) native look & feels and the ability for developers to customize further on their own; hopefully between this mix we've mostly got things covered...

  netsql

  PR? Sure. But if I didn't believe in these features, I wouldn't bother writing about them.

  Problems with native look and feel are somewhat historical, but some people still care deeply about minor differences and care that we fix them. We don't just do this stuff because we feel like it... Moreover, the fixes that we did in Mustang guarantee that when Vista arrives, Swing won't look like an XP app. I think you'd agree that there'd be native look & feel issues at that point. The fixes in Mustang will not be huge to people using XP because we already look pretty good there, but it lets us work on Vista in a much more native fashion.

  Deployment dialogs: I'm talking about stuff that's new in Mustang. We've been changing it every release, making it better, easier, friendlier. We did more of it in Mustang.

  Nothing is new? No, there's lots of new stuff. I just talked about some of the stuff I've personally designed, implemented, used, or benefited from. I've completely skipped some pretty major stuff. I wanted this blog to be a quick post on some of my favorite features, not survey of the huge amount of stuff in Mustang. For a broader overview of the major Desktop features, please check out the Desktop Features in Mustang article I referenced at the end of this blog. For a similar view of the Core (non-Desktop) features, check out the Core Features in Mustang article. Or check out the other 9 gazillion blogs posted today that cover other areas of Mustang outside my myopic view.

  SwingWorker is nice: I agree! ( I just didn't get to it here. It's in the Desktop Features article I referenced).

  GroupLayout: Actually, this is being discussed for Mustang, but it's not in Beta, so I didn't cover it here. Hopefully I'll have a chance to wax poetic on this for a later release...

  Posted by: chet on February 15, 2006 at 07:53 PM

• I hope to see the Gray Rect Fix applied to the Linux version before the final release.

  Posted by: mikael2 on February 16, 2006 at 01:48 AM

• Alghouth improvement in GTK native LAF is noticeable, font rendering is still so different than native Pango that Swing apps does not look native at all to a Linux desktop.
  
  Besides that, Swing anti-aliasing is much slower than the native anti-aliasing. For example, if I enable anti-alisaed text for NetBeans java editor, scrooling the editor while browsing the code becomes too slow to be practical, and I have to turn it off, while I can scroll anything I want using Eclipse java editor (which uses the native anti-aliasing).
  
  I've proposed before Swing gives the option of using the native platform text rendering, which will be ok for most apps, and the option of using Swing text rendering, for the few that need to know exactly which pixels should be touched, whatever the platform.

  Posted by: flozano on February 16, 2006 at 07:24 AM

• I have to agree with pago here... The excuse of backwards compatibility to Metal is valid, for the default PLAF. I don't mind the default PLAF being ugly, I would like it however if Sun shipped a decent looking PLAF with the VM. I don't mind if it will just be an XML file for Synth or anything like that but it should be something endorsed by Sun. Some 3rd party PLAF's break a bit with new VM releases and hunting down a decent free PLAF is hard for the smaller developers out there so it shouldn't be a big problem to Sun to offer a bit more variety than the very limited "Ocean" and show what can actually be done with a PLAF. Better yet, show what can be done with Synth we are dying to find out since there are hardly any examples. BTW I'm a native PLAF person myself ;-)

  Posted by: vprise on February 16, 2006 at 07:52 AM

• Hi Chet, of course I know about that argument. I've read it when Tiger came out. ;)

  Actually I meant what vprise was posting. You might want to add another LookAndFeel that could be used be used by apps that do not have to rely on the odd MetalLookAndFeel.

  Oh... and I'm clearly a Cross-Platform-Guy. ;)

  Posted by: pago on February 16, 2006 at 11:15 AM

• mikael2 Actually, Linux/Solaris do have the Gray Rect fix, as of build 48 of Mustang (I believe Beta is build 59). There are differences on these platforms in implementation:

  • The buffer is probably not cached in VRAM as it usually is on Windows, so copies to the screen may not be as fast (but fast enough that you may not notice).
  • Apparently we cannot disable the native window erase on X as we can on Windows. So there may still be some erasure prior to copying, but since we're not doing also doing a re-rendering (on a separate thread), the effect should be way better than the previous erase/re-render/copy process.

  pago Got it. Mixed news for you: we've spent more effort on the native l&f side, because the feedback we get tends to be heavily focused on that side (more people seem to care about native l&f than any cross-platform l&f). Meanwhile, we released Synth to make building custom l&f simpler. We are also working on a project to release a sample l&f for Synth which could go a long way toward addressing what you want. That one's still in process (Romain Guy is making progress on it, but it's not there yet), so I don't know when it'll make it, but hopefully there will be something for you later in Mustang.

  Posted by: chet on February 16, 2006 at 11:25 AM

• You've done a very good job on the native side, of course. You could've made LookAndFeel-development even easier by changing a view methods from "private" to "protected". ;)

  Just in case you did misunderstand me: I appreciate all of the things that have been done in Mustang and I'm really happy with the new native looks. It isn't that critical that you don't ship a first-class cross-platform LookAndFeel. I created my own and there are some others available as well.

  BTW: I just tried running TvBrowser on Mustang using GTK-LaF and it looks really cool. Almost like other GTK-Apps. There's one thing, however, I do not like. I'm using the "VistaBut"-theme which has a white font for menus - TvBrowsers menufonts are still black which is hard to read on the dark background.

  Romains work might be going into Mustang? I thought it might end up here at java.net or in Dolphin, but Mustang would be even better. ;)

  Posted by: pago on February 17, 2006 at 02:44 AM

• Gray Rect Fix on Linux works reasonable well. However if you configure X to display content in resizing windows, the dreaded gray rect is still there. Try to resize a window infront of NetBeans.

  Posted by: mikael on February 19, 2006 at 01:11 PM

• Hi! This release sounds very good, and I can't wait to try it out. I've always been highly disappointed by Swing, and am anxious to be able to do cross-platform development (I currently do Win32 only). So if Swing is at last rising to the level of SWT, (hope, hope!) then that's great! Just wondering, do you have any screenshots of a Swing application running on Windows with the new JDK?

  Posted by: jonneve on February 22, 2006 at 08:50 AM

• jonneve: This isn't exactly what you're looking for, but I posted some screenshots of SwingSet and NetBeans on Vista some time ago in this blog entry. The interesting thing in these screen shots is not the apps themselves, but the native l&f on this Beta platform (Vista), as well as some of the early LCD text capabilities.

  Posted by: chet on February 22, 2006 at 09:50 AM

• Thanks Chet, for your information about JDK 1.6, but are the 1.6 changes only limited to the Swing part of Java? I mean, what about support for custom languages, imporved File utilities, improved startup speed and ofcourse at least 500 new classes, which ofcourse we're getting kinda used to ;-)

  Posted by: bodiam on February 23, 2006 at 02:03 PM

• bodiam: This blog entry is most definitely client-oriented. I am now, and always will be, a desktop kinda guy. Check out the first paragraph:

  "...wax poetic about some of my favorite features in the release. This view is most certainly skewed, biased, and even subjective; there are a lot of cool things in the platform, but I specifically wanted to talk about the stuff that strikes my personal fancy..."

  I didn't intend to cover the whole platform here; I didn't have the time, nor do I necessarily have the experience of knowledge to do it accurately. Please check out the other articles (such as the "Desktop Features" and the "Core Feautres" linked in comments above) and the other numerous blogs that all cover their own niches in much better depth than I could.

  Posted by: chet on February 23, 2006 at 02:14 PM

• It seems that you can only add an image to the splash screen support . Is it possible to add more complex components, e.g. a progress bar?

  Posted by: ctiger on September 29, 2006 at 03:09 PM

This work is licensed under a Creative Commons License.