Image repaint preformance and threading

Question

Folks,
I'm trying to make this sucker run faster.
My question is, can anyone please guide me, especially with regards synchronising the Threads more efficiently... I'm thinking of using join and i]notify to make the "navigator" threads yield to the swing threads, to give it a chance to repaint before continuing... does this sound sane to you?
Currently, without the thread.sleep it paints get the first "burst", and then nothing until the alrorithm has completed... exactly not what I wanted, because the whole point of this GUI is to watch the algorithm at work... sort of a "visual debugger"... I find that watching an algorithm play out helps me to "imagineer" ways of improving it... and in this case improvement means optimisation... it's all about getting from A-J faster than anyone else on the planet, especially those smarty-wishbone-legs C# programmers ;-)
The code is too big to post (darn that 7500 char limit!) so I'll split it over several posts here, and I've also posted it as a single download to [MazeOfBoltonGUI2.java|http://groups.google.com/group/comp_lang_java_exchange/web/MazeOfBoltonGUI2.java] on my google group (comp lang java exchange).
Cheers all. Keith.
package forums.maze;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.util.HashMap;
import java.util.SortedMap;
import java.util.TreeMap;
import java.util.Stack;
import java.util.Queue;
import java.util.PriorityQueue;
import java.util.Iterator;
import java.util.Set;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.ExecutionException;
import java.awt.Dimension;
import java.awt.Color;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.Font;
import java.awt.image.BufferedImage;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.JPanel;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
import javax.swing.SwingWorker;
import java.io.PrintWriter;
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
* A Visual debugger,
* for the [A* Alogorithm|http://en.wikipedia.org/wiki/A*_search_algorithm] navigator
* of the [Maze Of Bolton|http://cplus.about.com/od/programmingchallenges/a/challenge12.htm]
* as implemented by [Prometheuz|http://forums.sun.com/profile.jspa?userID=550123]
* with GUI by [Kajbj|http://forums.sun.com/profile.jspa?userID=91610]
* hacked together by [Keith Corlett|http://forums.sun.com/profile.jspa?userID=640846]
* and posted on [Sun's Java Forum|http://forums.sun.com/thread.jspa?threadID=5319334]
* and posted on [Google news group|http://groups.google.com.au/group/comp_lang_java_exchange/]
public class MazeOfBoltonGUI2
  static final char[][] matrix = readMatrix("map.txt");
  public static void main(String[] args) {
    SwingUtilities.invokeLater(
      new Runnable() {
        public void run() {
          try {
            MazeNavigator navigator = new MazeNavigator(matrix);
            JFrame frame = new JFrame("MazeOfBoltonGUI2");
            frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
            frame.setContentPane(new MainPanel(navigator));
            frame.pack();
            frame.setVisible(true);
          } catch (Exception e) {
            e.printStackTrace();
   * Reads the file into a char matrix[rows,cols] ie: an array of char arrays.
   * @param String filename - the name of the file to read
   * @return a fixed length array of strings containing file contents.
  private static char[][] readMatrix(String filename) {
    try {
      BufferedReader input = null;
      try {
        input = new BufferedReader(new FileReader(filename));
        char[][] matrix = null;
        List<String> lines = new ArrayList<String>();
        String line = null;
        while ( (line = input.readLine()) != null ) {
          lines.add(line);
        int rows = lines.size();
        matrix = new char[rows][];
        for (int i=0; i<rows; i++) {
          matrix[i] = lines.get(i).toCharArray();
        System.err.println("DEBUG: rows="+rows+", cols="+matrix[0].length);
        return matrix;
      } finally {
        if(input!=null)input.close();
    } catch (IOException e) {
      e.printStackTrace();
      throw new IllegalStateException("Failed to readMatrix!", e);
class MainPanel extends JPanel
  private static final long serialVersionUID = 1L;
  // button panel
  private final JButton goButton;
  // maze panel
  private final MazeNavigator navigator;
  private final Monitor<Path> monitor;
  private BufferedImage background;
  private BufferedImage image;
  private List<Path>currentPaths;
  public MainPanel(MazeNavigator navigator) {
    this.navigator = navigator;
    this.monitor = new SwingMonitor();
    this.goButton = new JButton("Go");
    goButton.addActionListener(
      new ActionListener() {
        public void actionPerformed(ActionEvent event) {
          final String caption = goButton.getText();
          goButton.setVisible(false);
          monitor.execute();
    add(goButton);
    setPreferredSize(new Dimension(navigator.maze.cols*3, navigator.maze.rows*3)); //w,h
  public void paintComponent(Graphics g) {
    super.paintComponent(g);
    if (image==null) {
      image = (BufferedImage)createImage(navigator.maze.cols, navigator.maze.rows);
      mazeColors = createMazeColors(navigator.maze);
    this.draw(image.createGraphics());
    ((Graphics2D)g).drawImage(image, 0, 0, super.getWidth(), super.getHeight(), null);
  private static Color[][] mazeColors;
  private static Color[][] createMazeColors(Maze maze) {
    Color[][] colors = new Color[maze.rows][maze.cols];
    for (int r=0; r<maze.rows; r++) {
      for (int c=0; c<maze.cols; c++) {
        colors[r][c] = getColor(maze.matrix[r][c].ch);
    return colors;
  }*... PTO ...*

Answer 1

I'm persuaded that the main issue (no intermediate results drawn) is the improper use of SwingWorker.
When you've got over it, you may want to consider other smaller-effect optimizations:
Reconsider usage of an offscreen image*
public void paintComponent(Graphics g) {
    super.paintComponent(g);
    if (image==null) {
      image = (BufferedImage)createImage(navigator.maze.cols, navigator.maze.rows);
      mazeColors = createMazeColors(navigator.maze);
    this.draw(image.createGraphics());
    ((Graphics2D)g).drawImage(image, 0, 0, super.getWidth(), super.getHeight(), null);
  }At first I didn't get why you wanted to draw an offscreen image, then paint it to the screen, all that in the EDT.
After reading the draw() method more closely, I guess you want to ease the coding of the scaling: you draw an image where one cell = one pixel, then paint the image, scaled to the panel's display size.
In terms of performance, I don't know how it stands:
On one hand, the image creation if lighter (1 pixel per cell). And you have a point that the built-in scaling offered by Graphics2D.drawImage(image, size) may be efficient. I can't comment on that, I hope the granphics and hardware acceleration folks will pop in the thread.
On the other hand, if the built-in scaling had poor performance, it may be good to try what "manual" scaling would bring you. That means, in a simplified version, skip the offscreen image creation, and draw directly on the paintComponent()'s Graphics2D argument. the drawing of a cell at coordinates c,r, for example, would look like:
g.fillRect(c*CELL_WIDTH, r*CELL_HEIGHT, WIDTH, HEIGHT);Performance apart, the scaling as you do it currently has functional drawbacks, if you want pathes as 1-pixel width lines over large cells:
- if the maze is smaller (in rows, columns) than the panel displaying it (in pixels), the cells will be scaled but the pathes too: so your 1-pixel lines appear as large as the cells. May or may not be a desired effect.
- if the maze is larger than the display panel, the cells are shrinked, fine, but the so are the path lines, to a point where they may be invisible (probably depending on color blending, I'm a n00b at graphics operations).
But maybe I misunderstood the need, and maybe the intended drawing of a path is actually the drawing of the rectangles of all its traversed cells, in special path colors?
Reconsider intermediate allocations*
Each paintComponent() call results in the allocation of a 2D-array of Color objects (method createMazeColors(Maze)).
I don't see what the mazeColors array brings you. I assume you wanted to decouple the determination of colors (depending on cell state) and the rendering of the colors: what does it bring: no performance advantage (on the contrary, it adds a 2D array allocation, and 2xN^2 2D-array access), and does not improve the code readability either (subjective rant, sorry).
Why don't you pass the Maze as an argument to the draw() method, and call the getColor(cell.ch) from there?
Side note, maybe a bit subjective: performance apart, the design of the usage of this mazeColor array is a no-go!
An instance method alters a static variable reference,which is used subsequently in another instance method, with no synchronization. The current code does that in a single thread (+paintxxx()+ is only called in the EDT), which keeps that safe (I'd dare to say: by luck), but considerations exposed below may have you refactor the design to introduce other threads, and may exhibit the thread-unsafety of this design.
Consider drawing the image in a background thread.*
Indeed the technique of drawing to an offscreen image is quite common, but it is often done to improve responsiveness (not raw performance) of Swing applications. Here is a resource about this (what the author calls the passive approach), although it doesn't use a background thread.
The idea is that if a paintCompobnent() methods involves lots of computation (arithmetics of traversing a 2D model, scaling things, etc.), this takes CPU times in the EDT, and all subsequent events (such as, a MouseEvent, but also other painting events) keep pending on the event queue, which is consumed by the single event-dispatch thread. The result is that the UI appear unresponsive, and painting of other areas may seem hung.
The idea is to move the computation to a background thread, which posts rendering to the EDT when the Image is ready to be displayed.
Of course this doesn't gain any CPU time. This only ensures the EDT uses a minimal part of this CPU (only render and image and process events), instead of performing the whole computation.
In your case you already have a background thread, and indeed an appropriate choice, a SwingWorker. The application of this technique would consist in calling the draw() method in the worker thread (in the update(Path) method), and invoke super.publish() only after the image has been updated. Note that the process(List<Path>) could then ignore its argument (you may reconsider the choice of type parameter of the worker), and simply get the latest version of the image attribute).
Of course in this technique, the offscreen image filling is called synchronously from the Navigator, so this halts the algorithm part itself, for the duration of the image generation. You may refine the technique by spawning a dedicated thread for the image generation - with subtle guard code to handle occasions when the algorithm goes faster than the image generation, and posts a new update(Path) while the image generation for the previous path has not completed yet...
Recuce the number of things to redraw*
Two parts:
first, depending on the number of cells and pathes, there may be (yet another) optimization, to not redraw the whole offscreen image, but only the cells/path that have changed in the last update(). In particular, if a path is not a line but a list of cells, then it's quite easy, reusing the current offscreen image, to only fillRect(...) the appropriate cells.
Second, if a path is not rendered as a thin line over larger cells, but as cells themselves rendered in special path colors, you may paint cells and path in one go: instead of drawing, first the cells, then the path, draw only the cells, electing the color using a decision method such as:
private Color getColor(Cell) {
    if (cell.getPathState()!=NOT_IN_ANY_PATH) {
        return getColor(cell.getPathState());
    else {
        return getColor(cell.ch);
}Of course this forces you to modify your data model, and update the new pathState as part of the algorithm (or better isolated, in the update(Path) method, before invoking the drawing machinery). Maybe that was the intention of the mazeColors array?
I haven't studied your other posts on the logic of the MazeOfBolton algorithm, so I don't know if it's acceptable for you that a cell appear to have only one path state, as opposed to one for each of the pathes that traverse it. This last trick may then seem incorrect, but please consider it as only a graphical information, and indeed your current image drawing draws only ONE path for a given cell (the last path in currentPaths that traverses this cell ).