Conversion from awt to Swing, colored list widget, and awt update() method

Question

Now that my Interactive Color Wheel program/applet is in Swing, I guess I should continue my previous thread in here from the AWT forum ("list widget with different colors for each list item?"):
* list widget with different colors for each list item?
My current issue involves two canvas (well, JPanel) refresh issues likely linked to double buffering. You can see them by running the following file with "java -jar SIHwheel.jar":
* http://r0k.us/rock/Junk/SIHwheel.jar
[edit add]
(Heh, I just noticed Firefox and Chrome under Windows 7 will allow you to run thie .jar directly from the link. Cool.)
[edit]
If you don't trust me and would rather run it as an applet, use:
* http://r0k.us/rock/Junk/SIHwheel.html
(For some reason the first issue doesn't manifest when running as applet.)
1) The canvas goes "wonky-white" when the user first clicks on the wheel. What is supposed to happen is simply the user sees another dot on the wheel for his new selected color. Forcing a complete redraw via any of the GUI buttons at the bottom sets things right. The canvas behaves itself from then on, at least until minimized or resized, at which point one needs to click a GUI button again. I'll be disabling resizing, but minimizing will still be allowed.
2) A button image, and sometimes toolTip text, from an entirely different JPanel will appear in the ULC (0,0) of my canvas.
Upon first running the new Swing version, I had thought everything was perfect. I soon realized though that my old AWT update() method was never getting called. The desired case when the user clicks somewhere on the wheel is that a new dot appears on his selected color. This usually allows them to see what colors have been viewed before. The old paint(), and now paintComponent(), clear the canvas, erasing all the previous dots.
I soon learned that Swing does not call update(). I had been using it to intercept refresh events where only one of the components on my canvas needing updating. Most usefully, don't redraw the wheel (and forget the dots) when you don't need to. The way I chose to handle this is to slightly modify the update() to a boolean method. I renamed it partialOnly() and call it
at the beginning of paintComponent(). If it returns true, paintComponent() itself returns, and no clearing of the canvas occurs.
Since I first posted about these two issues, I've kludged-in a fix to #1. (The linked .jar file does not contain this kludge, so you can see the issue.) The kludge is included in the following code snippet:
    public void paintComponent(Graphics g)
        Rectangle ulc;
     if (font == null)  defineFont(g);
     // handle partial repaints of specific items
     if (partialOnly(g))  return;
        ...  // follow with the normal, full-canvas refresh
    private boolean partialOnly(Graphics g)
     boolean     imDone = true;
     if (resized > 0)  // this "if { }" clause is my kludge
     {   // should enter on 1 or 2
         imDone = false;
         resized += 1;     // clock thru two forced-full paints
         if (resized > 2)  resized = 0;
        if (wedgeOnly)
         putDotOnWheel(g);
            paintWedge(g);
         drawSnake(g);
         drawSatSnake(g);
         updateLumaBars(g);
            wedgeOnly = false;
          else if (wheelOnly)
            wheelOnly = false;
          else
            imDone = false;  // was paint() when method was update() in the AWT version
        return(imDone);
    }Forcing two initial full paintComponent()s does whatever magic the double-buffering infrastructure needs to avoid the "wonky-white" problem. This also happens on a minimize; I've disabled resizing other than minimization. Even though it works, I consider it a kludge.
The second issue is not solved. All I can figure is that the double buffers are shared between the two JPanels, and the artifact buttons and toolTips at (0,0) are the result. I tried simply clearing the top twenty lines of the canvas when partialOnly() returns true, but for some reason that causes other canvas artifacting further down. And that was just a second kludge anyway.
Sorry for being so long-winded. What is the right way to avoid these problems?
-- Rich
Edited by: RichF on Oct 15, 2010 8:43 PM

Answer 1

Darryl, I'm not doing any custom double buffering. My goal was to simply replicate the functionality of awt's update() method. And yes, I have started with the Swing tutorial. I believe it was there that I learned update() is not part of the Swing infrastructure.
Problem 1: I don't see the effect you describe (or I just don't understand the description)Piet, were you viewing the program (via the .jar) or the applet (via the .html)? For whatever reason, problem 1 does not manifest itself as an applet, only a program. FTR I'm running JDK/JRE 1.6 under Windows 7. As a program, just click anywhere in the wheel. The whole canvas goes wonky-white, and the wheel doesn't even show. If it happens, you'll understand. ;)
Are you aware that repaint() can have a rectangle argument? And are you aware that the Graphics object has a clip depicting the area that will be affected by painting? You might use these for your partial painting.Yes and yes. Here is an enumeration of most of the update regions:
enum AoI    // areas of interest
    LUMA_SNAKE, GREY_SNAKE, HUEBORHOOD, BULB_LABEL, LUMA_WEDGE,
    LAST_COLOR, BRIGHTNESS_BOX, INFO_BOX, VERSION,
    COLOR_NAME, EXACT_COLOR, LUMA_BUTTON, LUMA_BARS, GUI_INTENSITY,
    QUANTIZATION_ERROR
}That list doesn't even include the large color intensity wedge to the right, nor the color wheel itself. I have a method that will return a Rectangle for any of the AoI's. One problem is that the wheel is a circle, and a containing rectangle will overlap with some of the other AoI's. I could build an infrastructure to handle this mess one clip region at a time, but I think it would add a lot of unnecessary complexity.
I think the bigger picture is that, though it is now updated to Swing, some of the original 1998 design decisions are no longer relevant. Back then I was running Windows 98 on a single-core processor clocked at significantly less than 1 GHz. You could actually watch the canvas update itself. The color wheel alone fills over 1000 arcs, and the color intensity wedge has over 75 update regions of its own. While kind of interesting to watch, it's not 1998 any more. My multi-core processor runs at over 2 GHz, and my graphic card is way, way beyond anything that existed last century. Full canvas updates probably take less than 0.1 sec, and that is with double-buffering!
So, I think you're right. Let the silly paintComponent() do it's thing unhindered. If I want to track old dots on the wheel, keep an array of Points, remembering maybe the last 10. As a final step in the repainting process, decide how many of those old dots to display, and do it.
Thanks, guys, for being a sounding board.
Oh, I'm moving forward on implementing the color list widget. I've already added a 3rd JPanel, which is a column to the left of the main paint canvas. It will contain 3 GUI items:
1) the color list widget itself, initially sorted by name
2) 3 radio buttons allowing user to resort the list by name, hue, or hex
3) a hex-entry JTextField (which is all that is there at this very moment), allowing exact color request
The color list widget will fill most of the column from the top, followed by the radio buttons, with hex-entry at bottom.
For weeks I had in mind that I wanted a pop-up color list widget. Then you shared your ColorList class, and it was so obvious the list should just be there all the time. :)
-- Rich