1

I am drawing an animation onto a swing JPanel. The 1024x1024 screen is divided up into 2000 pieces which cover the screen exactly (no overlap).

each piece is a very small piece of the screen (1/2000'th of it). The animation draws one piece every millisecond by changing the pixels in the buffered image and calling reaint(). So at the entire screen changes every 2 seconds. The animation is run in a java.util.Timer task.

The buffered image is not accelerated and is not volatile. I set it's priority to 1.

The frame root pane is optimized. Both the front and back buffer are accelerated but not volatile.

This works ok.

Profiling indicates that almost all of the grahics time is spend drawing the buffered image as one would expect, Using some dirty rectangles does not seem to help reduce the paint time.

If I clip the drawing of the buffered image with it's exact shape, that piece gets painted and the rest of the screen turns white.

What I want to is to have the rest of the screen stay the way it was and just have the clipped shape get painted.

Making the pixels for each piece requires blending 10 layers, so there is some computation done there. could/should this be done better in an awt timer thread?

Or should i use a canvas and the update trick http://java.sun.com/products/jfc/tsc/articles/painting/src/UpdateDemo.java

I have seen suggestion that include Toolkit.getDefaultToolkit().setDynamicLayout(true); System.setProperty("sun.awt.noerasebackground","true");

other suggestions include paintimmedialtely, and subclassing JComponent instead of JPanel.

I find this all somewhat confusing.

I would like to keep this OS independent as much as possible, but the app will run mostly on windows 7.

What is the next (small) logical step for me to take here?

Update: Using a canvas (without the update trick) remarkably reduced the time spent drawing the buffered image. Instead of this being on the top line of the profiler, i can't find it! i may be doing more than i should when i use the panel.

Ray Tayek
  • 9,841
  • 8
  • 50
  • 90
  • 1
    (If you did not do it already:) Maybe initialize the JPanel with `setDoubleBuffered(false)`, as you yourself are doing the drawing. – Joop Eggen Aug 06 '12 at 20:04
  • @Joop Eggen, the real app will run with a fancy graphics board. i am hoping to eventually take advantage of that. my pc has on chip graphics. this is a prototype. – Ray Tayek Aug 07 '12 at 05:15

2 Answers2

3

Here are a few suggestions:

  • Critically examine the need to repaint() every millisecond; in particular, see if some updates may be coalesced.

  • Consider the convenience of java.swing.Timer, which renders on the EDT and supports coalescing events.

  • Calls to drawImage() are fastest when no scaling is required, as shown in this AnimationTest.

  • Always pre-compute images to the extent possible, as suggested in this KineticModel that illustrates several animation techniques.

  • TexturePaint, used in KineticModel, is also shown here.

  • IndexColorModel, illustrated here, may be applicable.

  • An sscce will allow you to isolate various approaches for easier profiling.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • re: coalesce update - yes, i will try that. scaling is required. data is live, so pre-compute will not help. blending data to needs to be done every millisecond, so i am not sure how i could do anything in the EDT except call repaint. will the swing timer be accurate to a millisecond? i am working on an sscce. – Ray Tayek Aug 07 '12 at 05:09
  • _accurate to a millisecond_? In a word, no. Java provides a platform- dependent virtual machine, not a RTOS. Several of the examples display self-timing data. – trashgod Aug 07 '12 at 05:30
  • tried coalescing the updates and just repainting every 10. some improvement, but not a lot. – Ray Tayek Aug 07 '12 at 07:31
  • One alternative is to run the model flat out and sample it periodically, as suggested [here](https://sites.google.com/site/drjohnbmatthews/threadwatch). – trashgod Aug 07 '12 at 17:21
  • correction, coalescing done right reduces the cpu time dramatically when i just repaint 1/100 of the screen! – Ray Tayek Aug 09 '12 at 03:20
2

EDITED TO BETTER EXAMPLE

Essentially we can use the RepaintManager to keep track of/update the few pixels that we change every millisecond. The dirty region will accumulate until the paint is actually able to happen. When the paint happens, it uses the paintImmediately(int x, int y, int w, int h) function (unless the whole component is dirty) - so we get away with just updating a small portion of the image. Hopefully the sample code isn't OS dependent - let me know if it doesn't work for you.

import java.awt.*;
import java.awt.image.BufferedImage;

import javax.swing.*;

public class UpdatePane extends JPanel{
    final int MAX = 1024;

    //The repaint manager in charge of determining dirty pixels
    RepaintManager paintManager = RepaintManager.currentManager(this);

    //Master image
    BufferedImage img = new BufferedImage(MAX, MAX, BufferedImage.TYPE_INT_RGB);


    @Override
    public void paintComponent(Graphics g){
        g.drawImage(img, 0, 0, null);
    }

    public void paintImmediately(int x, int y, int w, int h){
        BufferedImage img2 = img.getSubimage(x, y, w, h);
        getGraphics().drawImage(img2, x, y, null);
    }

    public static void main(String... args) {
        SwingUtilities.invokeLater(new Runnable(){
            @Override
            public void run() {
                final UpdatePane outside = new UpdatePane(); 

                outside.setPreferredSize(new Dimension(1024,1024));

                JFrame frame = new JFrame();
                frame.add(outside);
                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.pack();
                frame.setVisible(true);

                outside.new Worker().execute();
            }
        });
        }

    //Goes through updating pixels (like your application would)
    public class Worker extends SwingWorker<Integer, Integer>{
        int currentColor = Color.black.getRGB();
        public int x = 0;
        public int y = 0;
        @Override
        protected Integer doInBackground() throws Exception {
            while(true){
                if(x < MAX-1){
                    x++;
                } else if(x >= MAX-1 && y < MAX-1){
                    y++;
                    x = 0;
                } else{
                    y = 0;
                    x = 0;
                }

                if(currentColor < 256){
                    currentColor++;
                } else{
                    currentColor = 0;
                }

                img.setRGB(x, y, currentColor); 

                //Tells which portion needs to be repainted [will call paintImmediately(int x, int y, int w, int h)]
                paintManager.addDirtyRegion(UpdatePane.this, x, y, 1, 1);
                Thread.sleep(1);
            }
        } 

    }
}
Nick Rippe
  • 6,465
  • 14
  • 30
  • i may try this. but is doing a if(! fullRepaint) a reliable thing to do? – Ray Tayek Aug 07 '12 at 04:57
  • It's a valid point that in order to use the flag, you have to cover every scenario where a full repaint is necessary and set the flag (not exactly trivial). I added a better solution which avoids this pitfall. – Nick Rippe Aug 07 '12 at 15:33