Scott Violet's Blog

September 2005 Archives

Customizing Ocean Gradients

In my last blog I went over how we were able to make Ocean perform as well, and in some cases better than Steel. In this blog I'm going to cover how you can change the gradients that Ocean draws.

For a quick refresher the gradients in Ocean consist of 4 distinct regions as shown here:

As with other visual properties Ocean determines how to draw this gradient from the defaults table. JButton uses the defaults key "Button.gradient" to get the value that dictates what to draw. The value is a java.util.List consisting of five values. The first value is the percentage (as a Number) of the width (or height) for the first gradient. The second number gives the percentage (again as a Number) of the the width (or height) for the solid region. The remaining three values are the colors: start color for gradient 1, end color for gradient 1 and end color for gradient 2.

The algorithm for drawing a vertical gradient is roughly like:

  List values = ...;
  int gradient1Height = ((Number)values.get(0)).floatValue() * h;
  int solidHeight = ((Number)values.get(1)).floatValue() * h;
  Color c1 = (Color)values.get(2);
  Color c2 = (Color)values.get(3);
  Color c2 = (Color)values.get(4);
  // First gradient
  // Fictional method that draws a gradient of the specified size.
  drawGradient(0, 0, width, gradient1Height, c1, c2);
  // Solid rectangle
  g.setColor(c2);
  fillRect(0, gradient1Height, width, solidHeight);
  // First gradient inverted
  drawGradient(0, gradient1Height + solidHeight, width, gradient1Height, c2, c1);
  // Last gradient
  drawGradient(0, gradient1Height * 2 + solidHeight, width, h - (gradient1Height * 2 + solidHeight), c1, c3);

And the code to initialize the value is roughly like:

  java.util.List buttonGradient = Arrays.asList(
                 new Object[] {new Float(.3f), new Float(0f),
                 new ColorUIResource(0xDDE8F3), getWhite(), getSecondary2() });

Because the colors are not hard coded, you can change the way Ocean looks by changing the value in the defaults table. For example, you can go for the garish:

To the minimalist:

Or a slightly brighter Ocean look:

You can even get a look similar to that used by Incor's Alloy Look and Feel:

Or an XP like gradient:

Ocean Gradient Customizer

If you have 1.5 you can try your hand at a good combination using the Ocean Gradient Customizer. Post your favorite combinations and I'll do a future blog on the various combinations people have come up with.

Ocean, Gradients and Image Caching - oh my

One of the biggest features we did in 1.5 was revamping the java look and feel by providing a new theme (OceanTheme). Love it or hate it, Ocean requires a bit more graphics support than the line primitives of yore. In order to make Ocean the default we needed to make sure performance was in line with the old theme (Steel). All of our internal tests show that we succeeded, Ocean performs as well and better in some cases, than Steel. How did we do this?

Before I get into the solution let's first look at how the gradients that Ocean makes such extensive use of are painted. The gradient is not a single gradient, but is made up of four distinct areas:

1. Gradient from color1 - color2
2. Solid rectangle of color2
3. Gradient from color2 back to color1
4. Gradient from color1 to color3

Here's a monsterously large button showing the distinct regions:

This gives a nice radial gradient and is the effect the designers were after. From the description it's pretty obvious this is way more expensive than a simple fillRect. So, how did we speed this up? Image caching! Chet wrote up a great article that in effect describes the approach we took. In a nutshell, we cache the expensive images (gradients, slider thumbs ...) in an offscreen buffer. To avoid taking up excessive amounts of memory we reference these images via SoftReferences. A SoftReference is a step up from a WeakReference in that the referenced object will be released when no one is referencing the object and memory is low. In other words, if memory is tight the image will be chucked. Perfect for this scenario. Additionally we directly use VolatileImages rather than BufferedImages. In this case a VolatileImage is good because it'll most likely live in video memory, and if the image is lost we can trivially recreate it.

We placed all this functionality into the package private abstract class javax.swing.plaf.metal.CachedPainter (in 1.6 this has been moved to sun.swing), take a look if you're curious. This class hides all the image management, and SoftReference trickyness from subclasses, a subclass only need override a single method to do the actual painting. CachedPainter makes use of varags to allow for seamless passing of arguments to the method responsible for the actual painting. It results in lossing some type safety, but it works.

One last thing, for compatability Ocean still uses bold fonts, but this can easily be turned off with the system property swing.boldMetal=false. Oh ya!

Special thank to Romain for helping with the image.

This work is licensed under a Creative Commons License.