This post summarizes the changes that were made in Substance 5 to address the performance issues raised by the users. As mentioned before (part 1 and part 2), Substance 5 is 2.5-3.5 times faster than Substance 4.3 on various static and dynamic scenarios. Many thanks go to Dmitri Trembovetski from Java2D team for his help and tips.

1. Use multi-stop gradients (LinearGradientPaint) with REPEAT cycle method (as mentioned in the comments on Romain’s blog entry).
2. Rendering translucent texts is slow and does not use the new native font rasterizer in 6u10. Solution – instead of installing a translucent composite, interpolate the text foreground color and the background fill color based on your alpha value, and use full opacity text rendering.
3. BufferedImage.setRGB and BufferedImage.getRGB are really slow. A custom BufferedImageOp might be more difficult to learn, but is much more performant if done correctly.
4. Set RenderingHints.KEY_ANTIALIASING to OFF before calling any Graphics.fill operation that results in aliased fill in any case. This is especially relevant for Graphics.fillRect that gets integer parameters. Java2D is not smart enough (yet) to choose the non-antialiased path when the end result is non-antialiased.
5. Intermediate non-cached BufferedImages are slow. Whenever possible, either draw directly on the Graphics context, or collect the final result into one BufferedImage that goes into the cache, even if the cache key is more complex.
6. Filling with translucent color or filling under translucent composite is very expensive. In fact, the single largest performance gain (20% of the final result) in Substance 5 was removing watermarks from most core skins.
7. Use AffineTransform for rotating painting instead of doing it manually. As with BufferedImageOp, it takes some time to understand how to do it (and i’m still terrible at it), but the performance is much better.
8. Use EnumSet and EnumMap whenever possible. This is not Java2D-specific, and the tip goes to Joshua Bloch. These are quite faster than Hash* counterparts.
9. Do not do multiplt rendering of the same surfaces. This is especially relevant for tables thatcan have potentially thousands of visible cells on the screen. Try to draw background fills and gradients once per table.
10. Last, and not specific to Java2D – profile every scenario, question every method and every line of code.

More tips on Java2D performance right here.

Update: hitting “Submit” too fast, i forgot another Swing-specific optimization. Since everything UI-relates has to run on EDT, you can use non-synchronized non-thread safe code and collections. This comes in quite handy coupled with caching images and additional otherwise guarded blocks.

Here are some Swing links that you might have missed during this week:

• Chrigel dives into SwingBuilder and MigLayout to create a GUI application for testing JCR query functionality.
• On a related subject, Jacek Furmankiewicz has an article on using MigLayout for building Swing and SWT applications. There’s definitely a lot of interesting MigLayout recently, and Mikael is pushing hardto get it into the core JDK. I’m not really sure that it’s a good idea, especially given the mismatch in the pace of development and backwards compatibility. Perhaps it would be better to concentrate on tight integration with visual builders such as JFormDesigner, Matisse and Instantiations.
• Thomas Kunneth compares the two Swing binding frameworks, JGoodies Binding and Beans Binding (dormant RI of JSR 295).
• ???????? ????? ????????Artem Ananiev kicks off the series of posts on JWebPane component, WebKit-based lightweight Swing component for displaying and interacting with”street” HTML content. There is an unexpected twist – it is going to use the current look-and-feel to render the HTML form elements.
• Maxim Zakharenkov summarizes his JavaOne BoF session on the SwingExplorer project and has a link to the presentation slides (PDF warning).
• Jacek Furmankiewicz is busy at work augmenting the Java SwingBuilder with support for scroll panes, borders and icons.
• And finally, Christophe Le Besnerais shows how to use a custom popup factory, some Java2D code and HTML to display richer multiline tooltips inspired by the Office 2007 Super Tooltips.

Chet Haase is a well-known figure in the graphics community. Join him as he talks about UI development, collaboration between designers and developers, desktop vs. web and more.

Tell us a little bit about yourself.

I’m a software geek, with an interest and focus in computer graphics. I’ve been working on graphics software ever since I got bored in my first job out of college, where I was doing “network analysis.” I raced off to graduate school and have been doing graphics ever since.

I’m now working at Adobe Systems on the Flex SDK, where my current project is (surprise, surprise) to add additional animation support to the library.

I also enjoy writing and speaking about technology, from my blogs to articles to the book that I wrote with Romain Guy, to presenting at technical conferences. Implementing technology is fun, but it’s also fun to articulate to the users of the technology how things work and how they can take advantage of the platform for their applications.

What are the three most important things for a good user experience with a business UI application?

I don’t know about ‘most important’, but here are three that I think are very important:

Understandable: Can the user understand the UI? Is it obvious what they’re supposed to do at any point during the application?

Efficient: Can the user get their job done quickly? This includes power-users: you need to make sure that people that use the application all the time have shortcuts or very fast means of accomplishing common tasks. I saw this in action watching users of Autocad. As a graphics person, I would expect all of the drawing to be via the mouse and display, but the power-users that ran the program all day long performed many of the operations by typing in shortcut commands instead.

Robust: This one is obvious: Can the application avoid errors and crashes? No matter what the application looks and behaves like, if the user can’t get work done because it’s crashing left and right, then they’ll abandon it for anything else that gets the job done.

Can business applications (especially internal) justify being “sexy”? Is the current trend of bringing sleek visuals, animated content, 3D effects and media more than a fad?

Well, I sure hope so, or else I’ve been wasting my life for the past few years…

I think that it’s easy to write off graphical and animated effects as just being eye-candy. But I believe that any application can benefit from some level of effects in order to make the application more powerful, effective, and useable. In the case of a business application, you might not want to put throbbing buttons and spinning sprites all over the screen, or to make the application look more like a media player than an HR forms database front-end. But the same techniques can be used to make this kind of business application more useable; you just need to know how and when to apply them. For example, animation can also be used to provide a subtle pulsation of the default button, or transitions between states of the application. It’s this last one that has been of particular interest to me for some time. Why give your users new GUI pages to figure out whenever the application screens change? Keep them connected to the application, and more productive, by animating between the states so that they can more quickly determine what’s going on and what they have to do.

Animation and graphical effects can be totally gratuitous, but they can also be helpful and powerful tools for any application, as long as they are used properly.

Rich client development tools place great emphasis on allowing smooth collaboration between developers and designers. How important is this for developing business applications?

There should probably be more use of designers in business applications than there is today. “Design” is not just about creating media-rich consumer experiences; it is also about making applications more useable by the target users. The ability for designers and developers to collaborate more closely should help in developing applications that incorporate this design input.

Most of your career has been spent at the pixel level, but your last few efforts (such as timing framework and animated transitions) were on higher concepts. Does this reflect on leaving pixels in the hands of designers?

Actually, that’s more a picture of my recent career at Sun, working on Java, than of my career overall. Prior to that experience, I had worked at both lower levels (e.g., implementing drivers for graphics chips) and higher levels (e.g., writing 3D modeling applications) over an uncomfortably long career in graphics. For me, it’s always about getting pictures onto the screen, no matter where I’m working in the stack.

But to your point, I have spent the past few years trying to apply the lower-level techniques to benefit the higher levels of application development. For example, the timing framework and animated transitions libraries were about providing capabilities to developers that made it easier for them to add animation to their applications. I think that most business application developers have their hands full just implementing the logic of the core application without also worrying about how to use graphical effects. The more painless we can make it for them to do so, the more possible it is for them to apply the techniques.

I suppose this point also relates to designer; if we require people to dive into low-level code to implement nice animated effects, then it’s just not going to happen. Whether those people are designers, who probably don’t want to fool around with code at all, or business developers, who may not have the time or expertise in this area, if that’s what it takes to get those nice effects then the applications will ship without them. On the other hand, if the people that understand the low-level details can create higher-level utilities and tools that accomplish these tasks, then we can broaden the reach of these techniques and make it possible for all kinds of developers to use them.

Are you a proponent of visual designer tools? Do you think that automating the UI development results in better looking and more maintainable applications?

Yes. I’m not a designer myself, so I can’t speak for the tools and experiences that designers have in application development. But having used some decent GUI builder tools, I’m completely in favor of letting the tool do the visual stuff and saving the code for the logic. If it’s all in code, then it’s too easy to decide that that little UI tweak isn’t a big deal because recoding it would be a hassle. But if you have a design tool that makes visual aspects easier to develop and modify, then it is much easier to make small adjustments that may have big user and usability impact.

Do you think that a UI toolkit should enforce a specific and rigidly “guided” approach to UI development and restrict the API expressiveness, even at the cost of alienating advanced developers that will not have access to low level APIs.

Software, for me, is an art form in which nearly anything is possible. If you restrict the capabilities too much without letting the developer get in and hack things differently, that’s not software. I do believe that guidelines should exist, but in a way that helps the developer get the basics right. You want to help them get decent-looking applications without trying too hard, or having to learn and custom-code things too much. But that doesn’t mean you should prevent the developer from changing things as they see fit. It’s their application, after all, and they probably know their target audience and domain far better than the folks designing the toolkit do.

Do you see added value in cross-platform UI toolkits? Is it worth sacrificing access to platform-specific native functionality?

I see value in both. Some applications need to run on multiple platforms and need to have the same, or at least similar, user experiences on these platforms. Other applications need to be tightly integrated into the native desktop and need to have user experiences that are very tightly tied to the native look and feel.

It would be safe to say that the web is winning as the delivery layer of rich applications. What do you thing about a browser as the container layer? How important is it for a UI toolkit to live both in the browser and on the desktop?

Most applications that we run today, if you include the simple shopping and reading experiences we have on the web, are browser-based. So clearly that is an important medium for any application, and I personally would like to see richer experiences than HTML for much of what I do on the web. But I also use many applications that have nothing to do with the web, or at least nothing to do with the browser. For these applications, I don’t want to bother with the browser container, but instead would like the application to run as a normal window on the desktop. The extent to which a rich UI toolkit can serve both of these needs is beneficial to the toolkit as well as to users that can share common experiences and paradigms between the browser and desktop.

The Parleys.com application that was demonstrated at JavaOne and earlier at JavaPolis is a good example of a program and toolkit that spanned both spaces effectively. It has a browser-based model where the user runs the application on the parleys site and a desktop-based version where the user gets a very similar experience in a native desktop window. Since the application uses the same toolkit and UI for both cases, the user can apply their knowledge of the UI on one version directly to the other version; there’s nothing new to learn and they’re up and running quickly.

Is the browser the new platform? Extending the previous question, how important is it for a UI toolkit to be cross-browser?

Cross-browser functionality for a toolkit is quite important today. In some situations, there is only one browser that matters. But even in these constrained situations, you cannot alienate your potential user base by having your application behave poorly if people happen to run it on a different OS, or with a different browser. Also, you can never tell how the future dynamics of the browser wars will work out. So it’s far better to use an approach that makes your application work well regardless of platform and browser.

Is there anything you would like to add?

I would just like to encourage everyone to go out and create rich experiences. Life is too short to run boring applications.

Here are some Swing links that you might have missed during this week:

• Alex Ruiz has announced release 1.0 alpha2 of FEST-Swing library for functional Swing UI testing.
• Roman Kennke shows the first UI working on Jamaica virtual machine with OpenJDK.
• Alexey Utkin posts a few sample examples of geocoding with JDICPlus, including locators, mouse tracing and alpha mixing.
• Vladimir Ikryanov summarizes his experience with Swing Application Framework. Richard Osbaldeston has a particularly interesting and gloomy comment.
• Collin Fagan is working on the Java Tutorials project, and has a few new JTable and JTree code samples.
• Project Albireo has announced release 0.0.2 (alpha2). The goal of this project is to simplify the task of combining Swing and SWT components, and at first stage focuses on allowing seamless embedding of Swing component in SWT applications. A few code samples are available, as well as general installation instructions.
• Christophe Le Besnerais has published a very useful macro for searching Swing documentation in IE7 / Firefox.
• Jacek Furmankiewicz continues working on the SwingBuilder project, adding first support for validator logic.
• Finally, Dalton Filho has an interesting project that allows saving Swing windows created by Matisse (NetBeans UI designer) as equivalent wxWidgets windows in C++.