7

I've been looking at this for several months and so far this is the best I have come up with.

The structure (render outside of EDT) is not up for debate, as our application operates this way and will not be rewritten. The application has a layout model and a scripting model which are integrated and drive rendering, so the render must be performed outside of the AWT paint model.

What I am trying to arrive at is the optimal and reliable way to perform custom rendering.

The following SSCCE works fairly well for us. However, during frame resizes, it has 2 drawbacks:

  • There is occasional flicker, especially on rapid resizes
  • The "smooth resize" hack which is to invoke resize (via checkSize here) from a paint() call only works well for expansions. When reducing the frame it usually does not render until the mouse button is released
  • Also, but not so evident here, it does throw occasional IllegalStateExceptions - is it OK to simply catch/ignore these?

Also useful is input on whether this is the optimal approach for a custom render path that takes place outside of the EDT. I have tried most, and done fairly extensive research. This combination (backbuffer image, double buffer strategy) seems to work the best.

import java.awt.Color;
import java.awt.Dimension;
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.Insets;
import java.awt.Toolkit;
import java.awt.event.ComponentEvent;
import java.awt.event.ComponentListener;
import java.awt.event.MouseEvent;
import java.awt.event.MouseMotionListener;
import java.awt.image.BufferStrategy;

public class SmoothResize extends Frame implements ComponentListener, MouseMotionListener {

    public SmoothResize() {
        addComponentListener(this);
        addMouseMotionListener(this);
    }

    private boolean sizeChanged = false;
    private Dimension old = new Dimension(0, 0);
    private synchronized void checkSize(String source) {
        int width = getWidth();
        int height = getHeight();
        if (old.width == width && old.height == height)
            return;
        sizeChanged = true;
        String type =
            (old.width > width && old.height > height) ? "shrink" :
                (old.width < width && old.height < height) ? "expand" : "resize";
        System.out.println(source + " reports " + type + ": "+getWidth()+", "+getHeight());
        old.setSize(width, height);
    }

    public void componentResized(ComponentEvent arg0) { checkSize("componentResized"); }
    public void mouseMoved(MouseEvent e) { checkSize("mouseMoved"); }
    public void paint(Graphics g) { checkSize("paint"); }
    public void update(Graphics g) { paint(g); }

    public void addNotify() {
        super.addNotify();
        createBufferStrategy(2);
    }

    private synchronized void render() {
        BufferStrategy strategy = getBufferStrategy();
        if (strategy==null || !sizeChanged) return;
        sizeChanged = false;
        // Render single frame
        do {
            // The following loop ensures that the contents of the drawing buffer
            // are consistent in case the underlying surface was recreated
            do {
                System.out.println("render");
                Graphics draw = strategy.getDrawGraphics();
                Insets i = getInsets();
                int w = getWidth()-i.left-i.right;
                int h = getHeight()-i.top-i.bottom;
                draw.setColor(Color.YELLOW);
                draw.fillRect(i.left, i.top+(h/2), w/2, h/2);
                draw.fillRect(i.left+(w/2), i.top, w/2, h/2);
                draw.setColor(Color.BLACK);
                draw.fillRect(i.left, i.top, w/2, h/2);
                draw.fillRect(i.left+(w/2), i.top+(h/2), w/2, h/2);
                draw.dispose();

                // Repeat the rendering if the drawing buffer contents 
                // were restored
            } while (strategy.contentsRestored());

            // Display the buffer
            strategy.show();

            // Repeat the rendering if the drawing buffer was lost
        } while (strategy.contentsLost());
    }

    public static void main(String[] args) {
        Toolkit.getDefaultToolkit().setDynamicLayout(true);
        System.setProperty("sun.awt.noerasebackground", "true");
        SmoothResize srtest = new SmoothResize();
        //srtest.setIgnoreRepaint(true);
        srtest.setSize(100, 100);
        srtest.setVisible(true);
        while (true) {
            srtest.render();
        }
    }

    public void componentHidden(ComponentEvent arg0) { }
    public void componentMoved(ComponentEvent arg0) { }
    public void componentShown(ComponentEvent arg0) { }

    public void mouseDragged(MouseEvent e) { }
}
Charles Goodwin
  • 6,402
  • 3
  • 34
  • 63
  • +1 for [sscce](http://sscce.org/); also consider using the corresponding [adapters](http://download.oracle.com/javase/tutorial/uiswing/events/api.html). – trashgod Jul 26 '11 at 03:06
  • @trashgod: which adapters specifically and I was unaware there was any benefit to using an adapter vs using a listener - or is it a coding practise thing? – Charles Goodwin Jul 26 '11 at 09:50
  • `ComponentListener` -> `ComponentAdapter`, etc. Less clutter from empty implementations. – trashgod Jul 26 '11 at 15:21
  • @trashgod: there is no multiple inheritance in Java, so would have to use anonymous classes. As it is, our implementation uses those empty implementations so it was derived from something functional. :) – Charles Goodwin Jul 26 '11 at 15:40
  • That makes sense, but the adapters are abstract; composition with a named subtype is a common [approach](http://stackoverflow.com/questions/5136859/mouselistener-help-java/5137250#5137250). It's one way to avoid [leaking `this`](http://www.ibm.com/developerworks/java/library/j-jtp07265/index.html). – trashgod Jul 26 '11 at 16:03

2 Answers2

3

This answer is left here for reference, but is not the correct answer because it renders inside the EDT thread.

Here is a working fix! :D Basically the problem is that the ComponentResized is not appropriately called until the mouse is released after a shrink. Also, because the paint and checkSize methods are synchronized, they can exclude each other in rare instances. The fix is to override the validate method in the Frame class. This method is always called if the Frame changes state, including shrinks and growths. So we simply have to check the size in the validate and we can actually completely forget about using a ComponentResized method at all.

So, here is working code that compiles as is. I changed some of the variable names to improve my personal readability.

import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Insets;
import java.awt.Toolkit;
import java.awt.image.BufferStrategy;
import java.awt.Frame;

public class SmoothResize extends Frame {

public static void main(String[] args) {
    Toolkit.getDefaultToolkit().setDynamicLayout(true);
    System.setProperty("sun.awt.noerasebackground", "true");
    SmoothResize srtest = new SmoothResize();
    //srtest.setIgnoreRepaint(true);
    srtest.setSize(100, 100);
    srtest.setVisible(true);
}

public SmoothResize() {
    render();
}

private Dimension old_size = new Dimension(0, 0);
private Dimension new_size = new Dimension(0, 0);

public void validate() {
    super.validate();
    new_size.width = getWidth();
    new_size.height = getHeight();
    if (old_size.equals(new_size)) {
        return;
    } else {
        render();
    }
}

public void paint(Graphics g) {
    validate();
}

public void update(Graphics g) {
    paint(g);
}

public void addNotify() {
    super.addNotify();
    createBufferStrategy(2);
}

protected synchronized void render() {
    BufferStrategy strategy = getBufferStrategy();
    if (strategy == null) {
        return;
    }
    // Render single frame
    do {
        // The following loop ensures that the contents of the drawing buffer
        // are consistent in case the underlying surface was recreated
        do {
            Graphics draw = strategy.getDrawGraphics();
            Insets i = getInsets();
            int w = (int)(((double)(getWidth() - i.left - i.right))/2+0.5);
            int h = (int)(((double)(getHeight() - i.top - i.bottom))/2+0.5);
            draw.setColor(Color.YELLOW);
            draw.fillRect(i.left, i.top + h, w,h);
            draw.fillRect(i.left + w, i.top, w,h);
            draw.setColor(Color.BLACK);
            draw.fillRect(i.left, i.top, w, h);
            draw.fillRect(i.left + w, i.top + h, w,h);
            draw.dispose();

            // Repeat the rendering if the drawing buffer contents 
            // were restored
        } while (strategy.contentsRestored());

        // Display the buffer
        strategy.show();

        // Repeat the rendering if the drawing buffer was lost
    } while (strategy.contentsLost());
   }

  }

I hope that works for you!

Also, last second edit, I changed the logical ternary operation for the selection of your shrink or expand String. The last comparison was unnecessary because for the comparison in question, the values can be greater than, less than or equal to each other. There is not another possibility that would not generate a NullPointerException.

The stricken text is no longer relevant as I have completely removed that entire method. I indicate the other changes I've made to the original post as comments.

Josh
  • 448
  • 2
  • 9
  • Also, I'm not sure if this code was a grab from an actual in production code, but it might be advantageous to replace a method like `checkSize(String s)` with an `ActionListener` that listens to the frame itself. This would be more inline with the Java AWT Event model, and would provide a more consistent codebase. – Josh Aug 01 '11 at 00:58
  • I have edited the original post again. The extra `MouseListener` code was removed, as it served no purpose related to the question at hand. I also fixed the window flicker issue. That was do to implicit type conversion. When you divided the int of the window's width and height by two in the render method, it initially converted them to doubles to hold the extra .5 it would get dividing odd numbers. For instance, the int window size 3 becomes 1.5 as a double. Putting a double value to an int variable converts through truncation, cutting off the .5, and leaving a little white line in the render. – Josh Aug 01 '11 at 08:10
  • And may I recommend that you utilize Swing components, like `JFrame`, instead of the outdated AWT classes? – Josh Aug 01 '11 at 08:17
  • Your code didn't compile, there's an extra `}` ;-), but after removing that it works!! Now I wonder what the difference is between using Swing and AWT for this, as there are no components added to the Frame/JFrame? I'll post a follow up question for that, I think. – Charles Goodwin Aug 01 '11 at 10:33
  • In retrospect I should have not given the +100 yet as this implementation does paint in the EDT which kinda breaks the model. It is synchronized, so it may work in the outside-EDT render model, and I'll check that and get back to you. – Charles Goodwin Aug 01 '11 at 10:48
  • "From wikipedia : Most AWT and Swing object methods are not thread safe: invoking them from multiple threads risks thread interference or memory consistency errors. To avoid these problems, Swing standards state that all user interface components should be created and accessed only from the AWT event dispatch thread." Because the entire library is not thread safe, to make alterations to the GUI outside of the EDT could result in unwanted behavior. I can rewrite it to do it outside the EDT, I feel obligated since I got the bounty, but it probably will cause problems. – Josh Aug 02 '11 at 04:13
  • That would be great if you could, although could you post it as a 2nd answer in order to keep this one for posterity? – Charles Goodwin Aug 02 '11 at 11:32
  • So what you desire is for an outside thread to modify the buffers utilized by the Frame? – Josh Aug 02 '11 at 12:03
  • Implemented and added as a second answer. – Josh Aug 02 '11 at 14:24
3

Here is code that renders with an outside Thread doing all the work. It does this by being able to render anything that implements the Renderable interface. I have tested this with both Swing and AWT (JFrame and Frame) and it works with no flickering. Note, it does flicker if you implement onto a JRootPane and set that pane as the JFrame's root pane. This has to do with how the component is buffered, and could be fixed if that is how you want to use this.

If this is still not what you were looking for, just say and I'll give it another go. This is actually fun, as it has been awhile since I've done any Java GUI work.

Anyways, here you go:

import java.awt.Color;
import java.awt.Dimension;
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.Toolkit;
import javax.swing.JFrame;

public class SmoothResize extends Frame implements Renderable {

    public static void main(String[] args) {
        Toolkit.getDefaultToolkit().setDynamicLayout(true);
        System.setProperty("sun.awt.noerasebackground", "true");
        SmoothResize srtest = new SmoothResize();
        RenderThread renderThread = new RenderThread(srtest);
        renderThread.start();
        srtest.setSize(100, 100);
        srtest.setVisible(true);
    }

    public SmoothResize() {
    }

    public void addNotify() {
        super.addNotify();
        createBufferStrategy(2);
    }

    @Override
    public Dimension getSize() {
        return new Dimension(getWidth(), getHeight());
    }

    @Override
    public Graphics acquireGraphics() {
        return this.getGraphics();
    }
}

class RenderThread extends Thread {

    Renderable target;
    Dimension last_size = new Dimension(Integer.MAX_VALUE, Integer.MAX_VALUE);

    public RenderThread(Renderable d) {
        if (d == null) {
            throw new NullPointerException("Drawable target cannot be null.");
        }
        target = d;

    }

    @Override
    public void run() {
        while (true) {
            render(false);
        }
    }

    private synchronized void render(boolean force) {
        Dimension size;
        do {
            size = target.getSize();
            if (size == null) {
                return;
            }

            Graphics draw = target.acquireGraphics();
            if (draw == null) {
                return;
            }
            draw.setPaintMode();
            int w = (int) (((double) (size.width)) / 2 + 0.5);
            int h = (int) (((double) (size.height)) / 2 + 0.5);
            draw.setColor(Color.YELLOW);
            draw.fillRect(0, h, w, h);
            draw.fillRect(w, 0, w, h);
            draw.setColor(Color.BLACK);
            draw.fillRect(0, 0, w, h);
            draw.fillRect(w, h, w, h);
            draw.dispose();
            // Repeat the rendering if the target changed size
        } while (!size.equals(target.getSize()));
    }
}

interface Renderable {

    public Graphics acquireGraphics();

    public Dimension getSize();
}
Josh
  • 448
  • 2
  • 9
  • That looks pretty neat. I shall try it out ASAP (which unfortunately may be Monday if I can't get to it tonight). A quick question though - the Renderable interface is just something locally defined, right? (No java.awt.Renderable or similar seems to exist.) – Charles Goodwin Aug 02 '11 at 16:09
  • I won't be using a rootpane, as the custom UI we use takes over everything so it isn't necessary AFAICT. – Charles Goodwin Aug 02 '11 at 16:13
  • 1
    The `Renderable` interface is defined as an inner class at the bottom of the file. It seemed to me using an interface was the best way to do it, as it provided the most flexibility to your implementation. – Josh Aug 02 '11 at 16:53
  • You did specify that **No** awt components were going to be added to the frame, correct? – Josh Aug 02 '11 at 17:03
  • Correct - unless required to implement better rendering. :-) – Charles Goodwin Aug 02 '11 at 17:04
  • Actually, give me a sec and I'll check what that does to the performance. I'm curious if it works. At first I didn't think it would, but I might get saved by the UIDelegate already accommodating z-order into drawing routines. – Josh Aug 02 '11 at 17:08
  • Heres [the result](http://i54.tinypic.com/anbrth.png). It isn't pretty. Note the white artifacts are due to an added call to clearRect I made to try and fix the problem. It doesn't play well with other components. – Josh Aug 02 '11 at 17:20
  • This definitely works in this simpler context. If I run in to issues in the more complex context then I'll follow up with a question that demonstrates it... somehow. I am curious here though, is the backbuffer of the Frame ever likely to be "lost"? :-) – Charles Goodwin Aug 03 '11 at 10:59
  • The 'lost' frames only happen with `VolatileImage`s, or things that render to `VolatileImage`, which can be lost. Otherwise, to the best of my knowledge, no. – Josh Aug 07 '11 at 04:11
  • It still doesn't quite work for our particular situation although it is a lot better. Drawing directly to the Frame graphics is too slow (think hundreds of bits to draw) so an intermediate backbuffer is required, which is then copied to the Frame. It still doesn't resize nicely. I'll have to come up with another question (as you have answered this one correctly and helped a lot!) but if you fancy a challenge, it is open source software, and my email is charles.goodwin at a gmail address. – Charles Goodwin Aug 22 '11 at 00:38