I’m trying to get two JLabels to update at exactly the same time which I would like to do from my repaint method in my loop. However, the problem is that calling setText and setBackground on the JLables automatically calls the repaint method, therefore these labels aren’t actually getting updated by my repaint method in my loop.

I’m trying to implement a method of double buffering where I update the labels off screen and then in my repaint method I make an Image of the JPanel that holds the JLabels and display that Image. However, I cannot get this to work. The JFrame shows up solid black.

I believe that my problem is getting the Image of the JPanel and I’ve tried a couple different methods, but neither of them worked. I left both methods in my code so you can see the two methods I tried and one of them is commented out.

I did check to make sure everything else in my loop and double buffer were working correctly by removing all of the JPanel Image creating stuff in my paintComponent method and added a line to draw an oval with Graphics...g.fillOval(x, 200, 20, 20);Then I incremented “x” in my update method and the oval does move successfully across the screen. So everything else appears to be working.

Any help in getting my JPanel double buffer to work would be greatly appreciated...of if there is a better way I could be going about this, I’m open to suggestions there as well. Thanks!

To everyone: Basically what I'm trying to do is prevent one of the label displays from getting updated slightly before the other one. This is for a metronome application and sometimes (especially at faster speeds) one display will change just slightly before the other one when they should both change at precisely the same time. That's basically what I'm trying to prevent from happening with my double buffering method. I know double buffering is usually used to prevent "flickering", but I figured that approach might work for what I need also.

KevinWorkman, I've read up on painting but I still don't fully understand some of the "magic" that happens behind the painting methods. I found an example of double buffering using Graphics that moved an oval around the screen with the arrow keys and I tried replacing the "draw oval" part with a "draw Image" which I'm trying to get from the JPanel. If drawing an oval works (and it does when I add that into my example code), then drawing an image should theoretically work as well as long as I get the get the Image correctly from the JPanel...which unfortunately isn't working.

BurntPizza, these shorter code samples don't really show the problem, but my actual metronome app has a lot more code in between changing the display. I shortened this example down to the bare essentials of trying to get the double buffering to work. I didn't think anyone would want to sort through my current 9 files of code. I'm also in the process of reworking my program (based on some help I had in another thread) in order to implement the "loop" as I did it a totally different way before. But I was having issues with the display being off sync and I wanted to get that problem sorted out before I got to deep in rewriting everything.

Is that like what you're experiencing, like what you mean by "a lot more code in between changing the display"? Update all states at the same time and you should be good, if there's signifficant stuff executing in between the updating of different UI components, then yeah, that's gonna look weird.

But I was having issues with the display being off sync and I wanted to get that problem sorted out before I got to deep in rewriting everything.

I have the feeling your problems with the display being off-sync has to do with your possibly incorrect usage of Swing, or more precisely the EDT.If you put any long-running tasks into the EDT, (be it a complex calculation or the loading of a file), the entire GUI will start to behave really weird and get unresponsive. Making mistakes like not changing Swing-components on the EDT, or running a very expensive operation on the EDT, is the main reason for a lot of bugs. What's even worse is constantly calling repaint() as fast as possible by using a dynamic-timestep application-loop, which is what I think you are doing (?).

Fix your application-loop so it doesn't call the repaint() method more than ~30 times per second.

Why 30 times: Nobody can possibly read a number that changes more than 30 times per second (there are probably exceptions to that). Example: I can barely guess a number that changes 20 times per second, any faster and I am totally lost.

Note that the labels change their backgrounds in lockstep (the panel.repaint()) even though there's that sleep(30) that from my previous example would normally cause a lag on label4.I expect there is a similar hack for setText().

I do not recommend this at all, but you might try it just to see if that is what your problem actually is.

Basically what I'm trying to do is prevent one of the label displays from getting updated slightly before the other one.

You should only be modifying the JLabels on the EDT.

Painting is done on the EDT as well. So are events.

That means that if you set the text (or icons, whatever) of both JLabels at the same time, neither JLabel will repaint before the other one is updated, because you're using the EDT to update the JLabels, so painting can't be started until you're done.

You're introducing a ton of needless complexity to this program, when really all you need are the basics.

To demonstrate my points, here is a program that constantly updates two JLabels **on the EDT** and keeps them in sync simply by obeying the Swing rule that anything that changes the GUI (including your JLabels) must be done on the EDT:

Ahhhhh, yeah! That's much better than the hack job that I was trying to do!

So let's see if I've worked this through correctly...instead of directly changing the text and background in my update method, I'd instead set a Boolean (to test whether or not to change the JLabel), Color, and String (which would both be sent to the JLabel) and then call another method which would use these variables to update the JLabel via the EDT. Correct?

BurntPizza,

Yeah, your example was pretty close to the delay I was getting, sometimes mine would be a little more actually. I also had to change your colors to alternate between yellow and green. The grey and white actually didn't show the delay as well.

I ran your code on the EDT (like you posted later) and I even increased the delay...this works PERFECT no delay at all!

I used BurntPizza’s example, tweaked it a bit and added an animation onto it using jpg’s. For my metronome program I’d also like to add a “swinging” metronome animation so I’m trying my hand at getting some kind of simple animation (only two frames) going along with updating the JLabels.

The only way I could get the animation to switch at the same time as the other JLabels was to use two separate jpg images, load them as ImageIcons, and then add them to a JLabel by calling setIcon in the invokeLater method. This method does work, but since I’m not experienced in animation I just wanted to make sure that this was an acceptable method to use for animation...or would I be better off using another method?

I did try the single “sprite sheet” method at first, but from the tutorials and examples I looked at this involved drawing inside of the paintComponent method and I wasn’t able to figure out how to get it that to work along with my JLabels. So I tried the ImageIcon method and that was fairly easy to get working.

Here is what I was able to get working...am I on the right path here? Thanks!

D’oh! Sorry about that, that was my bad! I didn’t want to create a bunch of new topics on the forum over this so I posted my updated question on the same topic. I just edited the original post to notify you all about the slightly changed topic.

BurntPizza,

Holy smokes, that is awesome! Wow, I have a lot to learn on this stuff...I spent days trying to get those two stupid dots to move back and forth and you cranked out that awesome animation within the hour. lol

When I do get to making the swinging metronome animation, I would like to use images however rather than drawing with graphics so I can make the animation look “pretty” in photoshop. It’ll probably end up looking something like this...although I’ll probably make my own “less realistic” looking version.

I think I could get something like this to work with the “setIcon” method that I used above, but I don’t know if that’s a good method to use for animation as far as speed, smoothness, etc...I’ve never seen that used in any of the animation tutorials I’ve looked at, so I’m thinking this probably isn’t a recommended method.

I just tried re-working my original single sprite sheet example (using a BufferedImage) so I could post the code I was trying and I actually got it working this time!!!

Before I was trying to do it all in a single file and I calling repaint() from within the EDT, but it wasn't working. So instead I tried creating a separate animation JPanel class and this method works now. I’m not sure exactly what I was doing wrong before...but for whatever reason, starting over almost from scratch I finally got it!

Here's an updated version using multiple frames and the method you suggested for switching directions.

I also tweaked it so it's more like an "game loop" with an update and edtPaint methods. One thing I've noticed now is that I'm resetting the background color to the same color for the labels as well as redrawing the same image on the frames where the visuals don't change. Would it be more efficient to set a flag and check to see if it these items need to be updated before setting them again or is it ok to do this kind of constant updating on each frame on the edt?

I just want to make sure I'm not setting myself up for problems down the road as I started adding more stuff to it.

Yeah it doesn't really matter if you set the background color frequently, it's not an expensive operation. If you want to add the logic to do it only when necessary for peace of mind, do it.Only things really left for me to complain about are things you get with experience, like a developed sense of code conventions/style/formatting. Although Eclipse does have an on-save auto-formatter, imports organizer, and some other stuff I recommend you check out.

I'm currently using a very simple Java IDE called jGrasp. When I start working on my actual program I'll be using NetBeans since that was recommended for use with Codename One, does NetBeans have a similar kind of auto-formatting feature? And just so I'm aware of them, what kinds of formatting issues have you noticed in my sample code?

Inconsistency in field modifiers (some final, some not, some private, some not)

Inconsistency in field initialization (some in declaration, some in Test constructor)

Poor encapsulation: AnimationPanel is it's own class, but majority of it's initialization and logic is handled externally

Exceptions not being handled

Unnecessary methods (paintSubImage, etc.) (related to encapsulation)

Unnecessary repetition: label1, label2

Random things I could think of looking at it, goes from quite nit-picky to obvious to fairly advanced. I don't expect most of this from a simple demo/test program, sure, and some of it like I said you only gain from experience.Refactoring is your friend! Try to develop good architectural and style habits.

Ok, thanks a lot BurntPizza! Those are great things to be on the look out for. I will say that most of them were neglected only because this was a quick example to post on the forum and not things I intend to do in my real program. I did a lot of hacking, pasting, and moving things around so sometimes I didn't correct every detail just for the sake of time.

Thank you again for your help! I'm really glad I found this forum, you all are awesome!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org