Still not understanding Swing Double buffering

Question

I'm writing a custom JComponent like
class Custom extends JComponent {
protected void paintComponent(Graphics g) {
       //slow complex routine
}As the display does not often change I thought I could improve performance with my own off-screen rendering
class Custom extends JComponent {
private Image screenImage= null;
private void doOffscreen() {
            BufferedImage backimage = defaultgc.createCompatibleImage(getSize().width, getSize().height);
            final Graphics2D g2 = backimage.createGraphics();
             slow complex routine
            screenimage = backimage;
protected void paintComponent(Graphics g) {
       super.paintComponent(g);
       if (screenimage != null) {
            g.drawImage(screenimage, 0, 0, null);
}What does adding
class Custom extends JComponent {
       public Custom() {
            setDoubleBuffering(true);
}get me ? Or can I use the SWING double buffer to render to ?
I'm guessing what it will do is render my screen image into yet another image and then switch this in.
I feel I'm missing something :(

Answer 1

I've run your code and it seems to work well,
however it is in constant update mode where as my application usually only changes as a part of user interactionActually, that doesn't matter, since when you want the screen to update, you just call "repaint()" from any place that has visibility in your application. The real wonderful thing about offscreen rendering is: that when you have to have an update done, it paints immediately is a very optimized code--a one line paint/paintComponent routine, since the image is pre-rendered, no waiting.
The offscreen rendering approach lends very well to animation loops, adhoc graphic updates, and pretty much any other animation schemes I've been able to come up with.
There is really only one concern that I have in offscreen renderings: it is possible that you would be able to catch the offscreen image being rendered so only a partial image would be present on the screen. I cannot make it do this so I can notice it happen in any animation loop or continuous update scenario that I've been able to test.
I can force it to happen noticeably in code if I purposefully artificially extend the animation times far beyond what they may normally take and unreasonably make multiple tick cycles to the animation and update delays. This is like running a film in ultra slow motion--frame by frame, but under normal conditions (full speed animations), I cannot force any noticeable flaw in the output of an offscreen rendering scheme.
I've pumped that program that I posted up to 10,000 objects and it still ran--no flicker what so ever, but yes, it was a little jerky since I'm doing 1600x1200 and 10,000 images on a 2.4 GHz AMD under Solaris x64, but at the 1,000 object mark as posted, it works fine.