Scott Violet's Blog

April 2005 Archives

Baseline Layout

A friend speculated that Perl is best suited as a write once language. That is, Perl code tends to be rather cryptic to read and hard to maintain so that you end up writing the code once and praying you never come back to it. Much of the layout code I've seen can be lumped into that category. You write it once and if you ever come back to it you have to pull out your hair trying to figure out the intricacies of the containment hierarchy and layout managers being used. Ugh! All this for a process that is inherently visual and should be done in a tool.

This process has improved some what in recent years. In particular forms layout helps for much cleaner code, and some of the recent GUI builders have been getting better. We've been working closely with the Netbeans folks as well and will have an announcement soon. It's going to be fantastic. Stay tuned!

One area that we have been actively working on in Mustang is the ability to get the baseline for various components. This doesn't help developers laying out components, rather it's meant for those writing layout managers. Aligning components along their baseline makes for more polished apps. For example, if you have a label next to a button you do not want them top aligned or bottom aligned, rather you want them aligned on the baseline of the text.

Aligning components along their baseline also makes for great demos. Look at Apple's Interface Builder, or recent versions of Visual Studio for examples of GUI builders using baseline information to help developers create visually pleasing apps.

Accomplishing baseline layout with Swing has been tough. This is for a number of reasons, but primarily because Swing doesn't offer API to determine where the baseline for a particular component is! Sure, we do have the getAlignmentY method, but that really doesn't do all you need and it was never wired up. I'm happy to report that we're nearly done with the baseline API for Swing. If you want a sneak peek at what the API is looking like head over to the javadesktop, in particular the thread on baseline. Give us your two cents!

Thanks!

Swing Painting Improvements: No More Gray Rect!

In scoping out various performance related projects for mustang we wanted to tackle one of Swing's long standing problem areas that has contributed to bad perceived performance. That is, when a Swing based app is exposed after being hidden by another application there is a noticeable delay between when the background of the window is erased and when the actual contents are painted. We've come to call this the 'gray rect' problem. I'm happy to report that with the promotion of mustang build 32 this bug (4967886) has been fixed! Download it now and give us feedback!

The fix involved adding true double buffering support to Swing. That is, each window will now have an off-screen image that is kept in sync with the on-screen image. When a window is exposed we copy directly from the off-screen image, on the toolkit thread, to the screen. That's it! Your application will no longer see paint events in this scenario!

I've been running various Netbeans 4.1 builds for a while now with this fix and while subtle, it makes a big difference! I no longer see the Netbeans window flash when alt-tab'ing back and forth between Netbeans and other apps. Painting of exposed windows is nearly instantaneous.

An added bonus of this fix is that if your application is blocking the event dispatch thread, say you're contacting a server and a user hides your window and exposes it the app will still paint. Nice!

This fix is the most substantial change to Swing's painting architecture since pre 1.0. I'll have a follow on article that discusses the changes in more details. Until then, download the beta, kick the tires and give us feedback! We're not only interested in feedback on this change, but other areas that effect runtime performance you feel we should be focusing on.

For the hackers that want to see the Swing side of the code changes grab the latest source from the JDK source snapshot and look in javax.swing.BufferStrategyPaintManager, javax.swing.SwingPaintEventDispatcher and javax.swing.RepaintManager.

The fine print. For compatibility sake there are a handful of situations that will trigger turning off true double buffering. Most notably if you install your own RepaintManager. Additionally, true double buffering is currently only enabled on Windows. The code works on all platforms, but we have as yet to enable it everywhere. Yes, we're evaluating that now!

This work is licensed under a Creative Commons License.