These Are Some of my Favorite [Mustang] Things
What I Like About Mustang
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
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
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
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.
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
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.
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.
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.
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.