SQL & PL/SQL

problem solved [sort of]. this detailed discussion from this forum was very useful:

[canvas in a frame re-sizing flicker|http://forums.sun.com/thread.jspa?threadID=5360272&start=0&tstart=0]

The solution is to not use a Canvas. Rather, draw directly on the Frame. Someone in that discussion mentioned it might be a bug? My environment is:
1.6.0_05 on XP-home sp3.
Maybe I misunderstood the talk about a bug because some of the comments where beyond my understanding right now. In any event, as a Frame is a top-level container I think its a really bad design to draw directly onto then. Thus, my solution going forward is to keep using the Canvas, and pause all rendering during any re-sizing. I assume that is doable.

-- edit --
well, well, well. This flickering is/was a bug. It can be fixed (on XP at the least) with this line of code. If only I had googled for more than 5-minutes this morning, I could have had a nice day...

System.setProperty("sun.awt.noerasebackground", "true");

I can't test this fix on other operating systems, but am curious.

Edited by: rerf on Aug 8, 2010 8:37 PM

You could clip the image's Graphics to the passed Graphic's clip rectify, that should speed up everything.

I don't see how the clip would help. Resizing the Frame makes the clip of the Graphics the exact same width/height as the enclosing Frame.

Here is the absolute minimal demo that shows the behavior I want:

public class Main {
  private static final Frame frame;

  static {
    // critical!!! remove the next line and there is flicker while resizing
    System.setProperty("sun.awt.noerasebackground", "true");
    frame = new Frame("Alpha GUI v1.5");
    frame.setSize(800, 600);
  }

  public static void main(String[] args) {
    Four four = new Four();
    frame.add(four);
    frame.setVisible(true);
  }
}

public class Four extends Canvas {
  // critical to buffer!!!
  private Image offscreen;

  void demo(Graphics g) {
    Graphics2D g2 = (Graphics2D) g;
    g2.setStroke(new BasicStroke(10));
    Ellipse2D e = new Ellipse2D.Float(130, 50, 40, 200);
    g2.draw(e);
  }

  @Override
  public void paint(Graphics g) {
    offscreen = createImage(g.getClipBounds().width, g.getClipBounds().height);
    demo(offscreen.getGraphics());
    g.drawImage(offscreen, 0, 0, null);
  }
}

I've read enough to know its bad design to grab a graphics context outside any of:

paint(Graphics g), update(Graphics g), repaint(Graphics g).

And when I do, its my responsibility to dispose of the Graphics objects, otherwise I'll eventually exhaust some kind of gui resources.(I will deal with that later). And everyone recommends using Swing components. But first I want to take AWT as far as possible. I want to compare pure AWT with Swing.

In the end, from the API, this is what I think the problem is:
public void paint(Graphics g);
This method is called when the contents of the component should be painted; such as when the component is first being shown or is damaged and in need of repair. The clip rectangle in the Graphics parameter is set to the area which needs to be painted . Subclasses of Component that override this method need not call super.paint(g) .

My speculation is that somehow, when a Canvas is put in a Frame, a resize of the Frame causes the entire Canvas to be considered "damaged" (and probably this is the correct behavior). Further, as per the API, overriding paint(Graphics g) cannot prevent the invokation of super.paint(g), and I think some how this is related to the problem.
setIgnoreRepaint(boolean tf);
might lead to an interesting solution, but I could not take that technique very far.

I have the behavior I want. Though I feel a little ill about the platform portability of:
System.setProperty("sun.awt.noerasebackground", "true");
but its good enough right now.

---> bug id # [4803767|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803767]