How can a Swing JWindow be resized without flickering?

Question

I am trying to make a custom UI based on a JWindow for the purpose of selecting an area of the screen to be shared. I have extended JWindow and added code to make it resizable and to 'cut out' the centre of the window using AWTUtilities.setWindowShape().

When running the code I am experiencing a flicker as the window is resized in negative x and y directions, i.e. up and left. What appears to be happening is that the window is resized and drawn before the components are updated. Below is a simplified version of the code. When run the top panel can be used to resize the window up and to the left. The background of the window is set to green to make it clear where the pixels I do not want showing are.

Edit: Improved the code to shape the window correctly using a ComponentListener and added a dummy component at bottom to further illustrate flicker (also updated screenshots).

import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Graphics;
import java.awt.Rectangle;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;
import java.awt.event.MouseMotionListener;
import java.awt.geom.Area;

import javax.swing.JPanel;
import javax.swing.JWindow;
import javax.swing.border.CompoundBorder;
import javax.swing.border.EmptyBorder;
import javax.swing.border.EtchedBorder;
import javax.swing.border.LineBorder;

import com.sun.awt.AWTUtilities;

public class FlickerWindow extends JWindow implements MouseListener, MouseMotionListener{

    JPanel controlPanel;
    JPanel outlinePanel;
    int mouseX, mouseY;
    Rectangle windowRect;
    Rectangle cutoutRect;
    Area windowArea;

    public static void main(String[] args) {
        FlickerWindow fw = new FlickerWindow();
    }

    public FlickerWindow() {
        super();
        setLayout(new BorderLayout());
        setBounds(500, 500, 200, 200);
        setBackground(Color.GREEN);

        controlPanel = new JPanel();
        controlPanel.setBackground(Color.GRAY);
        controlPanel.setBorder(new EtchedBorder(EtchedBorder.LOWERED));
        controlPanel.addMouseListener(this);
        controlPanel.addMouseMotionListener(this);

        outlinePanel = new JPanel();
        outlinePanel.setBackground(Color.BLUE);
        outlinePanel.setBorder(new CompoundBorder(new EmptyBorder(2,2,2,2), new LineBorder(Color.RED, 1)));

        add(outlinePanel, BorderLayout.CENTER);
        add(controlPanel, BorderLayout.NORTH);
        add(new JButton("Dummy button"), BorderLayout.SOUTH);
        setVisible(true);
        setShape();

        addComponentListener(new ComponentAdapter() {           
            @Override
            public void componentResized(ComponentEvent e) {
                setShape();
            }});
    }


    public void paint(Graphics g) {
        // un-comment or breakpoint here to see window updates more clearly
        //try {Thread.sleep(10);} catch (Exception e) {}
        super.paint(g);
    }

    public void setShape() {
        Rectangle bounds = getBounds();
        Rectangle outlineBounds = outlinePanel.getBounds();
        Area newShape = new Area (new Rectangle(0, 0, bounds.width, bounds.height));
        newShape.subtract(new Area(new Rectangle(3, outlineBounds.y + 3, outlineBounds.width - 6, outlineBounds.height - 6)));
        setSize(bounds.width, bounds.height);
        AWTUtilities.setWindowShape(this, newShape);
    }

    public void mouseDragged(MouseEvent e) {
        int dx = e.getXOnScreen() - mouseX;
        int dy = e.getYOnScreen() - mouseY;

        Rectangle newBounds = getBounds();
        newBounds.translate(dx, dy);
        newBounds.width -= dx;
        newBounds.height -= dy;

        mouseX = e.getXOnScreen();
        mouseY = e.getYOnScreen();

        setBounds(newBounds);
    }

    public void mousePressed(MouseEvent e) {
        mouseX = e.getXOnScreen();
        mouseY = e.getYOnScreen();
    }

    public void mouseMoved(MouseEvent e) {}
    public void mouseClicked(MouseEvent e) {}
    public void mouseReleased(MouseEvent e) {}
    public void mouseEntered(MouseEvent e) {}
    public void mouseExited(MouseEvent e) {}
}

The overridden paint() method can be used as a breakpoint or the Thread.sleep() can be uncommented there to provide a clearer view of the update as it happens.

My problem seems to stem from the setBounds() method causing the window to be painted to the screen before being laid out.

---

Window before resizing, as it should look:

---

Window during resizing larger (up and left) as seen at breakpoint at overridden paint() method):

---

Window during resizing smaller (down and right) as seen at breakpoint at overridden paint() method):

---

Granted these screenshots are taken during aggressive mouse drag movements but the flicker becomes quite annoying even for more moderate mouse drags.

The green area on the resize to larger screenshot shows the new background that gets drawn before any painting/layout is done, it seems to happen in the underlying ComponentPeer or native window manager. The blue area on the 'resize to smaller' screenshot shows the JPanel's background being pushed into view but is now out of date. This happens under Linux(Ubuntu) and Windows XP.

Has anyone found a way to cause a Window or JWindow to resize to a back buffer before any changes are made to the screen and thus avoid this flickering effect? Maybe there is a java.awt.... system property that can be set to avoid this, I could not find one though.

---

Edit #2: Comment out the call to AWTUtilities.setWindowShape() (and optionally uncomment the Thread.sleep(10) line in paint()) then drag the top panel around aggressively in order to clearly see the nature of the flicker.

Edit #3: Is anyone able to test this behaviour under Sun Java on Windows 7 or Mac OSX ?

Answer 1

I admit this is not a particularly helpful answer, but understanding what exactly Swing is may help.

See, Swing does all its own work, short of actually getting a bit of space to draw on from the OS. All the drawing, widgets, etc are Java code. It's not so much that this is running to slowly, as that it's running without the benefit of the 2D graphics card acceleration and the OS rendering tricks.

Remember DirectDraw? Everything has it nowadays, and window ops are butter-smooth. But if you ever grab a computer that doesn't have it for some reason (say, a XP install with no drivers) you notice exactly this type of slowdown.

With Swing, because it manages all its own space, the OS can't do any of these rendering tricks to help you out.

Somebody may come along with some optimization that fixes your problem on your computer, but I'm concerned that it's just not really going to fix the base issue - Swing is slow and can't get faster.

You should look into native toolkits. AWT is OK, but missing a lot of widgets/etc. It's native, and built-in, so it should be plenty fast if that's all you need. I'm partial to SWT, which is what Eclipse, Vuze (among others) use. It combines the native-ness of AWT with the ease and features of Swing, and of course runs everywhere.

EDIT: It's pretty clear after reading some more of your comments that you absolutely understand how the windowing happens - I don't want to come off as condescending. Not only that, but you're more interested in resizing, which my comment doesn't have that much to do with. I'd still recommend SWT because it's native code and faster, but that's a different answer than the one above.

Answer 2

I have just tried your example. I really saw some small flicking when resizing the window. I tried to replace the code fragment starting from setBounds() and finishing at AWTUtilities.setWindowShape(this, newShape); by

setSize(newBounds.width, newBounds.height);

and saw that the flicking disappeared. So, I'd suggest you this solution unless you have any special reasons to use setBounds.

Answer 3

Another approach might be to wait for the user to complete their dragging/resizing before painting. Maybe use a bounding box to show the user the size of the window until after their resize event is complete.

I've noticed a lot of windowed applications will either take that approach or deal with the flickering. Just about all the apps I've tried an aggressive resize like that with has the same problem (non-Java) so the problem may just lie with the graphic subsystem rather than Swing itself.