Slow applet

[robs]

Hi,

I'm quite new to Java and this is my first post here. I have written a simple paper, scissors, stone type game and it runs very slowly (about 80% CPU while other Java games I found online seem to use about 2%).

I am running the game in a browser and while it has a two player online version, the one player version is equally slow.

Using Windows Resource Monitor I can see that it runs with about 35 Threads, in my program I've created about 5 or 6, I assume that this is because Java creates it's own threads but the truth is I'm just guessing.

It has 8 classes which extend JPanel (various game panels, one with a simple animation, scores, myButtons, myRadioButtons, etc.) and use Java2D. I have used GridBagLayout on most panels for the layout.

I'm sure most of this information is irrelevant, but the program is nearly 3000 lines long so I wouldn't post it here expecting anyone to go through it all and problem is really that I don't know where to start looking to find out why it's so slow. Could anyone point me in the right direction?

Thank you in advance,

Rob

[KevinWorkman]

Can you define "slow"? Is the GUI unresponsive? Something else? Are you doing any time consuming business logic on the EDT?

[robs]

Hi Kevin,

Thanks for your reply. Just that it's using up a lot of CPU, it generally works fine but if the CPU is at 100% then there would be a delay after pressing the play button and it actually doing something, or the animation would be a little jumpy for example.

To give you an idea of how little I know about the intricacies and terminolagy of Java, I just had to look up EDT. What would be defined as "time consuming business logic" and how can I trace the EDT? I have a few lengthy graphics things going on in the panels just to try and make them look nice, I would assume it's not constantly repainting them though.

Thanks again,

Rob

[robs]

I would just like to add that I am a little unsure of how the thread structure works. For example, does an event (button pressed) create a new thread? From what I can see it does. Will that thread destroy itself? Apart from that and threads which I have created by implementing runnable does that just leave the EDT? Windows saying my game has 35 threads has led to me being totally confused as to what's actually happening behind the scenes!

[KevinWorkman]

Well the EDT is basically where all of the GUI work gets done behind the scenes. It's also where events are handled, along with painting. So if you do something that takes a long time on the EDT, you could interrupt the GUI, making things appear unresponsive or slow. On the other hand, you don't want to update the GUI from another thread- so you have to find a balance between doing the actual work on another thread, but doing the GUI updates on the EDT- luckily, Java provides things like invokeLater() and SwingWorker to help keep things straight.

It's not an exact science to measure whether something is too time consuming for the EDT. I suppose you could take things out one at a time, and when your GUI becomes responsive again, you've found the culprit. You could also use a profiler. Or just put a ton of print statements, or use a debugger.

And you can't assume when Java is going to call it's painting methods- what kinds of lengthy graphics things are you doing? Simply drawing is probably okay, but if you're doing something like loading an image from a file, there are probably simply ways to optimize.

[KevinWorkman]

I would just like to add that I am a little unsure of how the thread structure works. For example, does an event (button pressed) create a new thread?

No, it won't create a new Thread. The event will be handled on the EDT, just like all of the other GUI stuff.

You might want to check out the SwingUtilities.isEventDispatchThread() method. That method returns true when the current thread is the EDT. Put a ton of print statements that spit out the value of that, and you'll see what's happening on the EDT and what's not.

SwingUtilities (Java Platform SE 6)

[robs]

The longest paintComponent method I have is about 110 lines long, most of the volume of my paintComponent stuff is antialiasing text and centering it etc. The animation uses about 12 gif images but I load them onto a buffer before the program starts.

Does calling variables from other classes slow things down considerably, is it better to retrieve them using a method in the other class or does it make no difference?

I have some threads for animation and for timing the animation of my buttons, does it slow things down to have these threads spinning round waiting to be used? As I have 4 buttons would it be better to have each button with a thread in its own class or one thread in a separate class which is called by all buttons (which is what I have at the moment)?. I realise this may be considered unrelated to the topic but I'm not sure if these things are likely to slow it down.

Taking things out one at a time might be the way forward.

Thank you

[robs]

Thanks, I'll look into using the print statements too.

[KevinWorkman]

The longest paintComponent method I have is about 110 lines long, most of the volume of my paintComponent stuff is antialiasing text and centering it etc. The animation uses about 12 gif images but I load them onto a buffer before the program starts.

Not really sure. I guess you could try to isolate that into an SSCCE and see if you experience the same kind of slow down.

Does calling variables from other classes slow things down considerably, is it better to retrieve them using a method in the other class or does it make no difference?

That shouldn't matter at all.

I have some threads for animation and for timing the animation of my buttons, does it slow things down to have these threads spinning round waiting to be used?

Possibly. It really depends on what they're actually doing. It sure seems like there's probably a better way to accomplish your goal. But I'm just guessing.

As I have 4 buttons would it be better to have each button with a thread in its own class or one thread in a separate class which is called by all buttons (which is what I have at the moment)?. I realise this may be considered unrelated to the topic but I'm not sure if these things are likely to slow it down.

I don't really think that matters, but again, it depends what those threads are doing. And it seems that using threads to update the GUI might be the problem. What happens if you use Swing Timers instead?

Taking things out one at a time might be the way forward.

Absolutely.

Thank you

No problem!

[robs]

Thanks for the link.

The threads I've used for animation and button timing are as follows:

I start the threads when the program loads and the run() method consists of a while(true) loop with an if(run) in it. In the specific case of the buttons 'run' is set to true when the button is pressed, it then sleeps for 200, tells the button to go up, sets "run" to false again and therefore exits the if section and continues doing nothing in the while loop. I have two of these (one to time time the button up and one to time it down) I know I could use just one thread for it. My animation threads work in a very similar way. I've never come across swing timers, if this turns out to be the problem I will investigate!

[KevinWorkman]

So you're setting the location of a Swing component on a thread that's not the EDT? That might be a contributor, I suppose. What happens if you wrap the setLocation() or whatever method you're using in a SwingUtilities.invokeLater()? Something like this:

SwingUtilities.invokeLater(new Runnable(){
   public void run(){
      button.setLocation(x, y);
   }
});

The above is not tested at all, but hopefully it gives you the idea.

[robs]

Sorry, that was slightly unclear. I'm not setting the location. It's just to animate the up/down status of the buttons. So it sets a boolean "down" so that it paints differently, the timer is to make sure it paints before it comes back up.

[KevinWorkman]

Sorry, without an SSCCE I'm pretty much guessing. I would bet that it has something to do with using threads to update the GUI. But I can't really suggest anything other than what I already said, until I see the SSCCE.

[robs]

Sorry I'm not sure how to type the code in properly here so I've uploaded a txt file with the skin and bones of my myButton class and its thread classes. Is that of any help to you?

[robs]

That should say bare bones! I've just taken a few methods out of myButton, the paintComponent and the other classes are complete.

[KevinWorkman]

Well you probably could have taken out most of that stuff (take stuff out until you don't see the problem, then you'll know what the problem is). And an SSCCE should be self contained- it should have a main method, fit in one file, and be runnable just by copying and pasting (take a look at the SSCCE link I posted above). And to see how to use the code tags, just take a look at my post (use the quote button to see what I actually typed).

But anyway, just glancing at this, one thing does jump out at me- in your paintComponent() method, you call resize(), which resizes the JPanel and calls repaint(). Won't that cause you to constantly be repainting?

[robs]

Thank you for pointing out my terrible bit of code! I had already removed the lines to start() the threads and it was still slow. Removing the resize() fixed it though (CPU 0). However, replacing the thread code slowed it down again. Turns out I had two problems.

I've tried taking the threads out one by one and it seems one of them is ok, while the others all slow it down... this has pointed me in the right direction, I'll keep investigating and let you know at some point how it goes, whether I resolve it or not.

Thank you very much!

[robs]

Thanks for your help. I've fixed the problem now. It turns out that the threads didn't like the if(run).

while(true){
   if(run){
        //DO SOMETHING
   }
}

I changed it back to

while(true){
  try{
      synchronized(Thread.currentThread()){
               Thread.currentThread().wait();
      }
   }
   //DO SOMETHING
}

and using notify, which is what I had before. I think the resize() problem you pointed out was masking the fact that I had resolved the issue. Now that I've removed that glitch and used the above method in all threads, everything is fine!

Thank you very much for your help!

I have one last question. Why does my program have over 30 threads when as far as I can see I have 6? Is it just to do with the way java works?

Rob

[KevinWorkman]

I have one last question. Why does my program have over 30 threads when as far as I can see I have 6? Is it just to do with the way java works?

Yeah. Depending on implementation, you'll have a ton of threads going. Just for starters, you have the main thread, then the EDT, then the garbage collection thread(s)...

[Awais261]

It has 8 classes which extend JPanel (various game panels, one with a simple animation, scores, myButtons, myRadioButtons, etc.) and use Java2D. I have used GridBagLayout on most panels for the layout.
It's not an exact science to measure whether something is too time consuming for the EDT. I suppose you could take things out one at a time, and when your GUI becomes responsive again, you've found the culprit. You could also use a profiler. Or just put a ton of print statements, or use a debugger.