If I add an instance of WorldWindowGLJPanel to my JFrame then remove it and add it again, the panel's GL viewport gets recalculated to a Rectangle that is much smaller than the available space. The dimension appears to consistently be 116x26. What this means is the frame becomes mostly blank with just a small piece of the WorldWind panel displaying in the bottom left corner of the frame. Resizing the frame appears to reset the viewport but is there a way to reset the viewport programmatically?
import java.awt.BorderLayout;
import java.awt.FlowLayout;
import java.awt.event.ActionEvent;
import javax.swing.AbstractAction;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;
import gov.nasa.worldwind.Model;
import gov.nasa.worldwind.WorldWind;
import gov.nasa.worldwind.avlist.AVKey;
import gov.nasa.worldwind.awt.WorldWindowGLJPanel;
public class WorldWindTest {
public static void main(String[] args) {
final JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
final WorldWindowGLJPanel wwPanel = new WorldWindowGLJPanel();
Model wwModel = (Model) WorldWind.createConfigurationComponent(AVKey.MODEL_CLASS_NAME);
wwPanel.setModel(wwModel);
JPanel buttons = new JPanel(new FlowLayout());
buttons.add(new JButton(new AbstractAction("Re-add WorldWind panel") {
private static final long serialVersionUID = 1L;
#Override
public void actionPerformed(ActionEvent e) {
frame.getContentPane().remove(wwPanel);
frame.getContentPane().add(wwPanel);
frame.getContentPane().repaint();
}
}));
frame.getContentPane().add(buttons, BorderLayout.NORTH);
frame.getContentPane().add(wwPanel);
frame.setSize(800, 600);
frame.setLocationRelativeTo(null);
SwingUtilities.invokeLater(new Runnable() {
public void run() {
frame.setVisible(true);
}
});
}
}
4 and half years late to the party, but posting my solution because I couldn't find one when I ran into this issue.
This problem seems to have nothing to do with WorldWindowGLJPanel, I believe it's a problem with any GLJPanel.
When you remove the GLJPanel from its parent, it resets its internal pixel scaling to some sentinel values. That's why it becomes tiny, but continues to (sorta) work.
The following 3 lines of code fixed it for me (I add them to a hierarchy listener and call them when the parent changes, but you can add them to the SSCCE above in the button handler)
wwPanel.initializeBackend(false);
wwPanel.reshape(0, 0, 0, 0);
wwPanel.revalidate();
initializeBackend tells OpenGL to initialize the backend, if it isn't initialized (Not 100% sure what causes it, but it seems to be tied to moving between parent windows).
Reshape will overwrite those pixel scale sentinel values, and so it'll actually calculate the proper size to display.
Revalidate causes it to recalculate the size of the panel, which I believe kicks off the size calculations now that those sentinel values aren't in the way.
Related
Working with the JTreeWithScrollbar example, but scaled it back significantly to focus on the issue.
The original code would have the vertical scrollbars appear as needed.
Here, there is plenty of space and no scrollbars are needed.
If the panel is moved enough, the scrollbar will appear.
Once the following line of code was added, the scrollbars stopped appearing.
tree.setUI(new MyTreeUI());
Notice no scrollbar.
If the above line of code is commented out, the vertical scrollbar appears.
Checking the documentation for BasicTreeUI and there isn't anything related to showing/hiding scrollbars.
2 Questions
1 - When utilizing the BasicTreeUI object, what is required to ensure the scrollbars still function?
2 - Why is it the Horizontal scrollbar never appears even if the line of code is commented out?
import javax.swing.JEditorPane;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JSplitPane;
import javax.swing.JTree;
import javax.swing.plaf.basic.BasicTreeUI;
import javax.swing.tree.DefaultMutableTreeNode;
import java.awt.Dimension;
public class JTreeWithScrollbar extends JPanel {
private JEditorPane htmlPane;
private JTree tree;
public JTreeWithScrollbar()
{
//Create the nodes.
DefaultMutableTreeNode top = new DefaultMutableTreeNode("The Java Series");
DefaultMutableTreeNode book1Node = new DefaultMutableTreeNode("Book 1");
DefaultMutableTreeNode book2Node = new DefaultMutableTreeNode("Book 2");
top.add(book1Node);
top.add(book2Node);
tree = new JTree(top);
tree.setUI(new MyTreeUI()); ///Comment out this line of code and the vertical scrollbar appears.
JScrollPane treeView = new JScrollPane(tree);
JScrollPane htmlView = new JScrollPane(htmlPane);
JSplitPane splitPane = new JSplitPane(JSplitPane.VERTICAL_SPLIT);
splitPane.setTopComponent(treeView);
splitPane.setBottomComponent(htmlView);
Dimension minimumSize = new Dimension(100, 50);
htmlView.setMinimumSize(minimumSize);
splitPane.setDividerLocation(100);
splitPane.setPreferredSize(new Dimension(500, 300));
add(splitPane);
}
public static void main(String[] args)
{
//Create and set up the window.
JFrame frame = new JFrame("TreeDemo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JPanel jp = new JPanel();
jp.add(new JTreeWithScrollbar());
frame.add(jp);
//Display the window.
frame.pack();
frame.setVisible(true);
}
private static class MyTreeUI extends BasicTreeUI
{
public MyTreeUI()
{
super();
}
#Override
protected void updateCachedPreferredSize() {
treeState.invalidateSizes();
tree.treeDidChange();
}
}
}
When utilizing the BasicTreeUI object, what is required to ensure the scrollbars still function?
As shown in the minimal example below, BasicTreeUI correctly shows each scroll bar when needed; resize the frame to see the effect.
Why does the horizontal scrollbar never appear even if the line of code is commented out?
After pack() the frame has been resized to adopt the preferred size of it content. Making the frame slightly smaller illustrates the effect. Your example adds the tree to a JPanel having a default FlowLayout which ignores preferred sizes; the example below adds the tree to the center of the frame's default BorderLayout which responds to preferred sizes.
I am assuming the updateCachedPreferredSize() must be doing other stuff behind the scenes…
Exactly. Each invocation of updateCachedPreferredSize() updates the component's preferred size to reflect any change in state (resize, expand, etc.); when the preferred size exceeds the viewport size, the scroll bars appear. As you observed, invoking super.updateCachedPreferredSize() allows normal operation, and any further customization must preserve that functionality.
In addition,
Expand rows as need like this.
Construct and manipulate Swing GUI objects only on the event dispatch thread.
Don't use setSize() when you really mean to override getPreferredSize() or illustrates a resize effect; more here.
import java.awt.EventQueue;
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTree;
import javax.swing.plaf.basic.BasicTreeUI;
public class JTreeWithScrollbar {
public static void main(String[] args) {
EventQueue.invokeLater(() -> {
//Create and set up the window.
JFrame frame = new JFrame("TreeDemo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JTree tree = new JTree(); //default model
for (int i = 0; i < tree.getRowCount(); i++) {
tree.expandRow(i);
}
tree.setUI(new MyTreeUI());
frame.add(new JScrollPane(tree));
//Display the window.
frame.pack();
frame.setSize(frame.getWidth() - 10, frame.getHeight() - 100);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
});
}
private static class MyTreeUI extends BasicTreeUI {
}
}
I have long text in Text Area placed to the Scroll Pane. I've noticed that when I rotate the mouse wheel, the text is redrawn severely, maybe even entirely.
This is the demo app:
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
public class TextArea {
public static void main(String[] args) {
final JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
final JTextArea textArea = new JTextArea();
textArea.setColumns(80);
textArea.setRows(20);
textArea.setLineWrap(true);
final JScrollPane scrollPane = new JScrollPane(textArea);
textArea.append("1234567890 ".repeat(20000)); // Java 11
frame.add(scrollPane);
frame.pack();
frame.setVisible(true);
}
}
Redrawing can be easily detected if you place a logging breakpoint to the sun.java2d.SunGraphics2D.drawString(String, float, float) method. For me, it logs a couple of thousands hits when I rotate mouse wheel by a single unit (the number of hits depends on the size of frame). If I stop at breakpoint, I see that y position of the string to draw differs a lot and the difference is much more than the height of my screen.
I think it should better redraw only visible lines, or maybe even newly appeared lines.
Can JScrollPane be set up somehow to optimize the amount of draw calls? Or is it an unoptimized thing in Swing?
When I run this code and spin the mouse scroll wheel, the GUI doesn't flicker or change at all. The only reason I see my scroll wheel doing something is the JScrollPane tab moves upward.
I compiled to the Java 8 standard, using Java 14.0.2. My computer runs on Windows 10.
Not surprising, since the text is identical.
Try this complete runnable code and see if it makes a difference.
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;
public class LargeTextArea implements Runnable {
public static void main(String[] args) {
SwingUtilities.invokeLater(new LargeTextArea());
}
#Override
public void run() {
final JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
final JTextArea textArea = new JTextArea();
textArea.setColumns(80);
textArea.setRows(20);
textArea.setLineWrap(true);
textArea.append("1234567890 ".repeat(20000)); // Java 11
final JScrollPane scrollPane = new JScrollPane(textArea);
frame.add(scrollPane);
frame.pack();
frame.setLocationByPlatform(true);
frame.setVisible(true);
}
}
JTextArea indeed generates too much draw calls for a long line, seems like it redraws it fully and because of soft wrapping, it's split.
However, going deeper, it's visible that while scrolling, clipping area is set quite restrictively (to the newly visible space), so Graphics2D is able to skip drawing of all the strings that are outside of clipping.
So there is no need to worry because actually not much drawing should be performed.
I have a JFrame, and within it, a JLabel that is filled by an image of a Map. I want to have clickable square “Tiles” in a grid over the image of the map. To do this, I made a large grid of JButtons that I have added to the JLabel containing the Map. However, the Map cannot be seen, so I have made the JButtons completely transparent. However, when they are Transparent, I can’t see where one JButton ends, and where another one starts. I want to create a JButton that is totally transparent on the inside, but still has a visible border around it. I have tried setOpaque(false) and then setBorderPainted(true) but that makes them opaque again. I have tried everything I could find, but nothing happens. Any suggestions?
Once again, all I want is a Transparent JButton with Visible Borders
You should be able to replace border with you own...
import java.awt.Color;
import java.awt.EventQueue;
import java.awt.GridBagLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.border.LineBorder;
public class Test {
public static void main(String[] args) {
new Test();
}
public Test() {
EventQueue.invokeLater(new Runnable() {
#Override
public void run() {
JFrame frame = new JFrame();
frame.add(new TestPane());
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
}
public class TestPane extends JPanel {
public TestPane() {
setBackground(Color.RED);
setLayout(new GridBagLayout());
JButton btn = new JButton("Hello");
btn.setOpaque(false);
btn.setContentAreaFilled(false);
btn.setBorderPainted(true);
btn.setBorder(new LineBorder(Color.BLUE));
add(btn);
}
}
}
You might need to use a CompoundBorder with a EmptyBorder on the inside to provide some padding (I tried using setMargins but it didn't seem to work)
Maybe i have encountered a bug or more probably doing something wrong ;)
I try to translate the content of a user drawn JPanel using a JScrollPanel. Inside the panel the drawing i would like to access the visible area through the Graphics class getClipBounds method to improve rendering performance.
Searching on SO brings a lot results referring to JScrollPane but none is mentioning a problem with the clip bounds. Google the same.
user drawn panel
import java.awt.Dimension;
import java.awt.Graphics;
import javax.swing.JPanel;
public class Content extends JPanel {
#Override
protected void paintChildren(Graphics g) {
super.paintChildren(g);
// intense clip bounds dependent rendering here
System.out.println(g.getClipBounds());
}
#Override
public Dimension getPreferredSize() {
return new Dimension(2000,2000);
}
}
main frame setup
import java.awt.EventQueue;
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import java.awt.BorderLayout;
public class ClipBoundsIssue {
private JFrame frame;
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
try {
ClipBoundsIssue window = new ClipBoundsIssue();
window.frame.setVisible(true);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
public ClipBoundsIssue() {
frame = new JFrame();
frame.setBounds(100, 100, 450, 300);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JScrollPane scrollPane = new JScrollPane();
frame.getContentPane().add(scrollPane, BorderLayout.CENTER);
Content content = new Content();
scrollPane.setViewportView(content);
}
}
to reproduce
Just run the code, move one of the scrollbars and inspect the console output of System.out. The following picture depicted scrolling the bar on the x axis.
actual System.out result
Which produced the following results
java.awt.Rectangle[x=0,y=0,width=416,height=244]
java.awt.Rectangle[x=416,y=0,width=16,height=244]
java.awt.Rectangle[x=432,y=0,width=15,height=244]
java.awt.Rectangle[x=447,y=0,width=16,height=244]
java.awt.Rectangle[x=463,y=0,width=15,height=244]
expected result
I would have expected to have the width of the bounds to keep the same. But it changes from 416 to 16.
The question now is
Does anybody know why this happens, or how it can be avoided??
discared WAs
A possible workaround would be to lookup the view port's view bounds. But if possible i would like to avoid the Content class making any such lookup. Another alternative would be to pass the information into the Content class, but this i would like to avoid as well.
I would have expected to have the width of the bounds to keep the same.
Why? It is so simple that it is hard to explain, but let me try.
When you scrolling, only small new portion if the JPanel is appearing if you scroll slowly.
The produced output is absolutely correct:
java.awt.Rectangle[x=0,y=0,width=416,height=244] Control is shown first time, you need to redraw it completely
java.awt.Rectangle[x=416,y=0,width=16,height=244] You scrolled to the right by 16 pixels, so only narrow strip of you control must be redrawn.
You must understand that these coordinates are related to your control which has size set to 2000x2000 pixels.
Try to scroll the window created with this code and you will see what I am talking about:
import javax.swing.*;
import java.awt.*;
import java.util.Random;
public class ScrollPaneRepaintDemo extends JPanel {
public ScrollPaneRepaintDemo() {
setPreferredSize(new Dimension(2000,2000));
}
public static void main(String[] args) {
JFrame frame = new JFrame();
frame.add(new JScrollPane(new ScrollPaneRepaintDemo()));
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.setVisible(true);
}
#Override protected void paintComponent(Graphics g) {
Rectangle clip = g.getClipBounds();
g.setColor(new Color(new Random().nextInt()));
g.fillRect(clip.x, clip.y, clip.width, clip.height);
}
}
By the way - it works so because of JPanel's internal implementation. If you extend JComponent instead, the whole viewport will be clipped. I add also that JPanel repaints completely when resizing, its optimizations are only for scrolling.
If i create non-resizable JFrames, and windows Aero is enabled setLocation does not seem to take account of the window border correctly.
In the following code I would expect the second frame to be positioned to the right of the first frame, instead the borders are overlapping. If Aero is disabled or if I remove the calls to setResizable this is done as expected.
import java.awt.Rectangle;
import javax.swing.JFrame;
public class FrameBorders {
public static void main(String[] args) {
JFrame frame1 = new JFrame("frame 1");
JFrame frame2 = new JFrame("frame 2");
frame1.setResizable(false);
frame2.setResizable(false);
frame1.setVisible(true);
Rectangle bounds = frame1.getBounds();
frame2.setLocation(bounds.x+bounds.width, bounds.y);
frame2.setVisible(true);
}
}
Am I doing something wrong or is this a bug?
How can I display 2 unresizable dialogs side by side without having overlapping borders?
Edit: added screenshots (also changed frame2 to a JDialog instead of a JFrame)
Aero On:
Aero Off:
Aero On but resizable:
What are the problems with settings bounds on non-resizable containers?
Suppose you adjust the bounds to look good on your platform. Suppose the user's platform has a font with different, say larger, FontMetrics. This example is somewhat contrived, but you get the idea. If you change the bounds of a non-resizable container, be sure any text is visible regardless of the host platform's default font.
import java.awt.BorderLayout;
import java.awt.EventQueue;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;
/**
* #see http://stackoverflow.com/a/12532237/230513
*/
public class Evil extends JPanel {
private static final String s =
"Tomorrow's winning lottery numbers: 42, ";
private JLabel label = new JLabel(s + "3, 1, 4, 1, 5, 9", JLabel.LEFT);
public Evil() {
this.add(label);
}
private void display() {
JFrame f = new JFrame("Evil");
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.add(this, BorderLayout.WEST);
f.pack();
int w = SwingUtilities.computeStringWidth(
label.getFontMetrics(label.getFont()), s);
int h = f.getHeight();
f.setSize(w, h);
f.setResizable(false);
f.setLocationRelativeTo(null);
f.setVisible(true);
}
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
#Override
public void run() {
new Evil().display();
}
});
}
}
It seems that this is not a Java issue but rather an aero appcompat issue , as described here.
One solution that I see in Java is to let the windows be resizable then work around the setMaximumSize bug