I haven't been able to find a solution to this problem so far through research and may in fact be a problem with JFrame as a whole.
Like any desktop application, most times the clicking of a button or "object" presents an action of changing what is currently being displayed. So for example, if I currently have an "input form" on the display frame and then the user clicks a button labeled "submit," the screen changes to a congratulations screen saying "your form has correctly been submitted," where all previous elements of the form are no longer showing.
Now in most cases, we set up a JFrame like so:
frame.getContentPane().add(panel);
frame.pack();
frame.setVisible(true);
Where panel is a JPanel that contains all the primary display objects and layouts at the current time.
Alright this is great, but if we want to change the content pane to introduce a new screen we would do something of the following:
frame.getContentPane().removeAll();
frame.getContentPane().add(newPanel);
frame.pack();
Where newPanel contains different objects and layouts when compared to the original panel.
But a design problem occurs here. The refresh rate becomes clunky and choppy. Take a look at this gif below at my current program:
You can clearly see the choppy refresh rate between the transition of the original panel and to the newPanel.
I got to thinking, maybe it was because I didn't disable the viewing of the frame before packing it. So I then tried:
frame.setVisible(false);
frame.getContentPane().removeAll();
frame.getContentPane().add(newPanel);
frame.pack();
frame.setVisible(true);
This, however, just yielded the same result as what is presented in the gif. I then began googling and found many StackOverflow answers saying to either revalidate() or repaint() the frame before packing. So I tried adding this first in the code right above:
frame.revalidate();
This didn't work either, whether placed before or after the pack() method, yielding the same result. So I tried removing that and tried this in the above code:
frame.repaint();
That didn't work either, whether placed before or after the pack() method, again yielding the same result. So I tried both of them together (before and after just like before) and yet again nothing changed.
I then saw some people recommending this line of code:
frame.update(frame.getGraphics());
But, again the same result is still presented. I began wondering if it was a problem with JFrame and its own internals. So I did an experiment with sleeping the current thread right after calling pack() but before turning the visibility of the frame to true.
This yielded the same outcome. No matter how long I waited, re-displaying the frame to the screen created the same clunky and messy redraw between components as what is presented in the gif. Now this is leading me to two possible conclusions, either the pack() method is more of a hack than a clean solution or the drawing of the frame to the screen is just buggy in nature with Java.
I have tried every method placement I can find. I have experimented many times over again with reorganizing the method calls and I have tried introducing other method calls in hopes of solving this problem.
Has anyone experienced this same result, as every application I have written is subject to this annoyed and ugly design bug. And I just cannot seem to get rid of it.
Is there a solution or do I have to reinvent the wheel with awt.Panel?
-Versions-
Java:
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
(This problem has occurred in previous versions of Java for me too)
MacOS:
OS X Yosemite
Version 10.10.3
MacBook Pro (Retina, 13 inch, Late 2013)
Here is my output:
As you can see, I still suffer the same problem as before. In the code I do use GridBagLayout but that is not the problem. In the past I have used layouts from BoxLayout to FlowLayout and I still got the same clunky, messy "refresh" result.
I just tested commenting out portions of the refresh code in my example program like how I did above and again the same result is given. I just provided everything uncommented because no matter what I do with that code, my result is unchanged.
In addition, I can understand downloading a file for some is a problem (e.g. lack of trust in the user) so here is the text: http://freetexthost.com/rjldye21ix
On a final note, I can post edits with more gifs if any new solutions appear.