7

I am using the JScrollNavigator component described here, in order to provide a navigation window onto a large "canvas-like" CAD component I have embedded within a JScrollPane.

I have tried to adapt the JScrollNavigator to draw a thumbnail image of the canvas to provide some additional context to the user. However, the action of doing this causes the rendering of my application's main frame to become corrupted. Specifically, it is the action of calling paint(Graphics) on the viewport component (i.e. my main canvas), passing in the Graphics object created by the BufferedImage that causes subsequent display corruption; if I comment this line out everything works fine.

Below is the JScrollNavigator's overridden paintComponent method:

@Override
protected void paintComponent(Graphics g) {
    Component view = jScrollPane.getViewport().getView();
    BufferedImage img = new BufferedImage(view.getWidth(), view.getHeight(), BufferedImage.TYPE_INT_ARGB);
    Graphics2D g2d = img.createGraphics();

    // Paint JScrollPane view to off-screen image and then scale.
    // It is this action that causes the display corruption!
    view.paint(g2d);
    g2d.drawImage(img, 0, 0, null);
    Image scaled = img.getScaledInstance(getWidth(), getHeight(), 0);

    super.paintComponent(g);
    g.drawImage(scaled, 0, 0, null);
}

Does anyone have any suggestions as to the cause of the corruption? I would have thought that painting to an offscreen image should have no effect on existing paint operations.

EDIT

To provide some additional detail: The JScrollNavigator forms a sub-panel on the left-hand side of a JSplitPane. The JScrollPane associated with the navigator is on the right-hand side. The "corruption" causes the splitter to no longer be rendered and the scrollbars to not be visible (they appear white). If I resize the JFrame, the JMenu section also becomes white. If I attempt to use the navigator or interact with the scrollbars, they become visible, but the splitter remains white. It's as if the opaque settings of the various components has been affected by the rendering of the viewport view to an offscreen image.

Also, if I make the JScrollNavigator appear in a completely separate JDialog, everything works correctly.

EDIT 2

I can reproduce the problem consistently by doing the following:

Add a JMenuBar to the mFrame:

JMenuBar bar = new JMenuBar();
bar.add(new JMenu("File"));
mFrame.setJMenuBar(bar);

In the main() method of JScrollNavigator replace:

jsp.setViewportView(textArea);

... with:

jsp.setViewportView(new JPanel() {
  {
    setBackground(Color.GREEN);
    setBorder(BorderFactory.createLineBorder(Color.BLACK, 5));
  }
});

Ensure that the JScrollNavigator is embedded as a panel within mFrame, rather than appearing as a separate JDialog:

mFrame.add(jsp, BorderLayout.CENTER);
mFrame.add(nav, BorderLayout.NORTH);

Now when the application runs the JMenuBar is no longer visible; the act of painting the view (i.e. a green JPanel with thick black border) to the Graphics2D returned by BufferedImage.createGraphics() actually appears to be rendering it onscreen, possibly from the top-left corner of the JFrame, thus obscuring other components. This only seems to happen if a JPanel is used as the viewport view, and not another component such as JTextArea, JTable, etc.

EDIT 3

Looks like this person was having the same problem (no solution posted though): http://www.javaworld.com/community/node/2894/

EDIT 4

Here's the main and paintComponent methods that result in the reproducible error described in Edit 2:

public static void main(String[] args) {
    JScrollPane jsp = new JScrollPane();
    jsp.setViewportView(new JPanel() {
        {
            setBackground(Color.GREEN);
            setBorder(BorderFactory.createLineBorder(Color.BLACK, 5));
        }
    });

    JScrollNavigator nav = new JScrollNavigator();
    nav.setJScrollPane(jsp);

    JFrame mFrame = new JFrame();

    JMenuBar bar = new JMenuBar();
    bar.add(new JMenu("File"));
    mFrame.setJMenuBar(bar);

    mFrame.setTitle("JScrollNavigator Test");

    mFrame.setSize(800, 600);

    mFrame.setLayout(new GridLayout(1, 2));

    mFrame.add(jsp);
    mFrame.add(nav);
    Dimension screenDim = Toolkit.getDefaultToolkit().getScreenSize();
    mFrame.setLocation((screenDim.width - mFrame.getSize().width) / 2, (screenDim.height - mFrame.getSize().height) / 2);

    mFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    mFrame.setVisible(true);
}

@Override
protected void paintComponent(Graphics g) {
    super.paintComponent(g);

    Component view = jScrollPane.getViewport().getView();

    if (img == null) {
        GraphicsConfiguration gfConf = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
        img = new BufferedImage(view.getWidth(), view.getHeight(), BufferedImage.TYPE_INT_ARGB);
    }

    Graphics2D g2d = img.createGraphics();
    view.paint(g2d);

    Image scaled = img.getScaledInstance(getWidth(), getHeight(), 0);

    g.drawImage(scaled, 0, 0, null);
}

EDIT 5

It seems like others are having trouble recreating the exact problem. I would ask people to run the code pasted here. When I first run this example I see the following:

Corrupt Image 1

Neither the JScrollNavigator or the JMenuBar have been painted; these frame areas are transparent.

After resizing I see the following:

Corrupt Image 2

The JMenuBar has still not been painted and it appears that the JPanel was at some point rendered at (0,0) (where the JMenuBar should be). The view.paint call within paintComponent is the direct cause of this.

Adamski
  • 54,009
  • 15
  • 113
  • 152
  • What do you mean by 'corruption'. I've just run this example and it works for me perfectly. I needed only to invoke `super.paintComponent(g);` at the beginning of the overriden `paintComponent` method. – Xeon Jul 31 '12 at 13:46
  • 2
    I've submitted the code [here](http://wklej.to/RnkO1). – Xeon Jul 31 '12 at 13:55
  • See also [*Zoom box for area around mouse location on screen*](http://stackoverflow.com/q/18158550/230513). – trashgod Sep 13 '16 at 15:12

3 Answers3

9

Summary: The original JScrollNavigator uses the Swing opacity property to render a convenient green NavBox over a scaled thumbnail of the component in an adjacent JScrollPane. Because it extends JPanel, the (shared) UI delegate's use of opacity conflicts with that of the scrollable component. The images seen in edit 5 above typify the associated rendering artifact, also shown here. The solution is to let NavBox, JScrollNavigator and the scrollable component extend JComponent, as suggested in the second addendum below. Each component can then manage it's own properties individually.

enter image description here

I see no unusual rendering artifact with your code as posted on my platform, Mac OS X, Java 1.6. Sorry, I don't see any glaring portability violations.

image one

A few probably irrelevant, but perhaps useful, observations.

  • Even if you use setSize(), appropriately in this case, you should still pack() the enclosing Window.

    f.pack();
    f.setSize(300, 200);
    
  • For convenience, add() forwards the component to the content pane.

    f.add(nav, BorderLayout.WEST);
    
  • Prefer StringBuilder to StringBuffer.

  • Consider ComponentAdapter in place of ComponentListener.

Addendum: As suggested here, I got somewhat more flexible results using RenderingHints instead of getScaledInstance() as shown below. Adding a few icons makes it easier to see the disparate effect on images and text.

image two

editPane.insertIcon(UIManager.getIcon("OptionPane.errorIcon"));
editPane.insertIcon(UIManager.getIcon("OptionPane.warningIcon"));
...
@Override
protected void paintComponent(Graphics g) {
    super.paintComponent(g);
    Component view = jScrollPane.getViewport().getView();
    BufferedImage img = new BufferedImage(view.getWidth(),
        view.getHeight(), BufferedImage.TYPE_INT_ARGB);
    Graphics2D off = img.createGraphics();
    off.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
        RenderingHints.VALUE_ANTIALIAS_ON);
    off.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
        RenderingHints.VALUE_INTERPOLATION_BICUBIC);
    view.paint(off);
    Graphics2D on = (Graphics2D)g;
    on.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
        RenderingHints.VALUE_ANTIALIAS_ON);
    on.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
        RenderingHints.VALUE_INTERPOLATION_BICUBIC);
    on.drawImage(img, 0, 0, getWidth(), getHeight(), null);
}

Addendum secundum: It looks like the JPanel UI delegate is not cooperating. One workaround is to extend JComponent so that you can control opacity. It's only slightly more work to manage the backgroundColor. NavBox and JScrollNavigator are also candidates for a similar treatment.

enter image description here

jsp.setViewportView(new JComponent() {

    {
        setBackground(Color.red);
        setBorder(BorderFactory.createLineBorder(Color.BLACK, 16));
    }

    @Override
    protected void paintComponent(Graphics g) {
        super.paintComponent(g);
        g.setColor(getBackground());
        g.fillRect(0, 0, getWidth(), getHeight());
    }

    @Override
    public Dimension getPreferredSize() {
        return new Dimension(300, 300);
    }
});
Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • Thanks - TBH I made those changes to JScrollNavigator already when I imported the code. I've noticed the corruption problem only occurs if I embed the JScrollNavigator as a sub-panel of the app frame; If I have the navigator as a separate JDialog it seems to work ok. I'll keep digging. – Adamski Jul 31 '12 at 20:59
  • @Adamski: this [answer](http://stackoverflow.com/a/11745544/230513) reminded me about resampling artifact, mentioned in an article cited [here](http://stackoverflow.com/a/6916719/230513). – trashgod Jul 31 '12 at 23:29
  • Thanks for the tips on resizing. See my second edit for an example of how to reproduce the corruption problem 100% of the time. It appears to be related to using a JPanel as the viewport view rather than e.g. a JTextArea, etc. – Adamski Aug 01 '12 at 08:59
  • Sorry, not I'm not seeing it at this point using e.g. `GridLayout` on the nav side. You might try further subdividing the left half of the split pane vertically. – trashgod Aug 01 '12 at 11:08
  • Thanks; I tried changing to GridLayout but it still doesn't look good - The JMenuBar is painted over. I've posted the exact main and paintComponent methods I've used. – Adamski Aug 01 '12 at 13:07
  • I'm doing `setSize()` _after_ `pack()`; and I'm invoking `super` at the _beginning_ of `paintComponent()`, as in the [original](http://wklej.to/RnkO1). Sorry, my "mental diff" is weak. :-) Looks OK on Ubuntu, too. – trashgod Aug 01 '12 at 18:36
  • Would you mind trying using the main and paintComponent methods I list at the end of my question? The problem only seems to manifest when the viewport view is a JPanel; for JTextArea, etc it works ok. – Adamski Aug 02 '12 at 07:32
  • Cool. I changed the layout and overrode `getPreferredSize()` in the anonymous `JPanel` and changed the color so I could see the green `overBox`. It all worked correctly as [patched](http://pastebin.com/iHF8en4t) from [original](http://wklej.to/RnkO1). – trashgod Aug 02 '12 at 10:11
  • Oh well - Thanks a lot for trying. I've actually just linked to the exact code I'm running with screenshots. I've tried using JDK 1.6.0_21 and 1.7.0_05 on Windows 7 so far. Will also try on Linux and see if the problem persists. – Adamski Aug 03 '12 at 09:55
  • I see normal rendering on Mac using your latest [code](http://pastebin.com/ueuNSBjy). The menu bar artifact in your screenshot looks like the frame's [`contentPane`](http://stackoverflow.com/a/11769153/230513) has been tampered with, perhaps replaced rather than added to. BTW, the `setSize()` in the `JScrollNavigator` constructor may be superfluous. – trashgod Aug 03 '12 at 12:49
  • I guess it must be a Windows specific problem - I've asked two colleagues to run the code, one on Fedora the other on Windows 7. Both experienced the same repaint issues, and only with a JPanel as the viewport view, not a JTextArea (where everything works fine). – Adamski Aug 03 '12 at 13:58
  • OK, I see it on Ubuntu, too. I've suggested an alternative above. – trashgod Aug 04 '12 at 19:34
  • Great stuff - Thanks a lot! I've accepted your answer. Do you think this is actually a bug that's worth reporting to Oracle? – Adamski Aug 06 '12 at 09:51
  • Glad it was helpful. I'm not sure it's a bug: The `JPanel` UI delegate is allowed to manage opacity. Changing `NavBox` and `JScrollNavigator` to extend `JComponent` proved straightforward. I'm not sure yet how this comports with @Nick Rippe's findings. – trashgod Aug 06 '12 at 10:44
  • BTW - should *"..see the disparate effect on images and test."* be *"..see the disparate effect on images and text."* (s->x)? – Andrew Thompson Aug 12 '12 at 03:18
2

I am also not sure what you mean by corruption, but I noticed that the resampled image is much nicer if you specify Image.SCALE_SMOOTH as the rescaling hint:

Image scaled = img.getScaledInstance(getWidth(), getHeight(), Image.SCALE_SMOOTH);

Maybe this is what you are looking for...

lbalazscs
  • 17,474
  • 7
  • 42
  • 50
  • Ah, _this_ artifact. Also consider this [answer about resampling artifact](http://stackoverflow.com/a/6916719/230513); +1. – trashgod Jul 31 '12 at 23:39
2

I was able to reproduce your problem and get you the result your looking for. The problem is that the drawing of the image wasn't complete by the time you were repainting again, so only portions of the image were being painted. To fix this, add this field to your JScrollNavigator class (as a lock):

/** Lock to prevent trying to repaint too many times */
private boolean blockRepaint = false;

When we repaint the component, this lock will be activated. It won't be released until we have been able to successfully paint the panel - then another paint can be executed.

The paintComponent needs to be changed to abide by the lock and use a ImageObserver when painting your navigation panel.

@Override
protected void paintComponent(final Graphics g) {
    super.paintComponent(g);
    if(!blockRepaint){
        final Component view = (Component)jScrollPane.getViewport().getView();
        BufferedImage img = new BufferedImage(view.getWidth(), view.getHeight(), BufferedImage.TYPE_INT_ARGB);
        Graphics2D g2d = img.createGraphics();
        g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);

        // Paint JScrollPane view to off-screen image and then scale.
        // It is this action that causes the display corruption!
        view.paint(g2d);
        ImageObserver io = new ImageObserver() {

            @Override
            public boolean imageUpdate(Image img, int infoflags, int x, int y,int width, int height) {
                boolean result = true;
                g.drawImage(img, 0, 0, null);
                if((infoflags & ImageObserver.FRAMEBITS) == ImageObserver.FRAMEBITS){
                    blockRepaint = false;
                    result = false;
                }

                return result;
            }
        };

        Image scaled = img.getScaledInstance(getWidth(), getHeight(), 0);
        blockRepaint = g.drawImage(scaled, 0, 0, io);
    }
}
Nick Rippe
  • 6,465
  • 14
  • 30
  • I tried swapping in your paintComponent to the example I pasted but I see the same result. I don't quite understand how the scaling can be the problem: Even if I comment out the scaling code the problem still occurs; it's the painting to the offscreen image that causes the issue. – Adamski Aug 06 '12 at 13:52
  • I assume you added the lock as a field (otherwise the code wouldn't work). If so, your flag being returned on the `ImageObserver` might be different. The line you indicate is the problem appears to be the problem only because when you comment it out, it prevents the other steps from doing anything - it's the `g.drawImage(...)` line that's taking a while to complete because it's updating the UI. The working code I have is here: http://pastebin.com/MccHaaFj . I added some print statements to the `paintComponent` so you could see exactly which flags are being passed (and adjust as necessary) – Nick Rippe Aug 06 '12 at 14:04
  • @NickRippe: I couldn't make this work on Ubuntu/OpenJDK, but I've never tried to reorder rendering like this. My solution was to avoid `PanelUI` by extending `JComponent`; I'd welcome any critical insight you can offer. – trashgod Aug 06 '12 at 19:28
  • @trashgod - I've just had problems identifying the actual problem. I thought I found it, but now that I go back to it, it looks like I was just fixing a separate rendering problem. :P Oi vay! I've spent enough time with this - Your answer provides a good workaround (I was just hoping to fix the problem). – Nick Rippe Aug 06 '12 at 20:48
  • @NickRippe: Thanks. I just noticed that `BasicPanelUI` is shared, which may be a factor. – trashgod Aug 06 '12 at 21:05