Thread: can someone show me how to change speed of an java engine.

You already do change the speed of the Timer, in the setSpeed() method. What's your question?

Originally Posted by 2by4

Load Microsoft Word on your machine :-)

Seriously, though, you need to read up on multithreading.

You need to have a controlling application and then launch your simulation on a separate thread, so that the controller and simulator are running in parallel.

Essentially you need an object of type Runnable passed to a Thread constructor, and then to call Thread.start();

I absolutely disagree with this advice. Using a Swing Timer is the way to go here.

Do you mean like the JFileChooser?

Originally Posted by 2by4

Swing Timer is using the same principal behind the scenes. However,...

...although I can understand that you advise against reinventing the wheel, I think you have assumed that the speed changes come from the user only, through a GUI. If the timer changes are coming from any asynchronous source, including automatic ones, I don't think Swing Timer gives you much advantage.

The advantage of the Swing Timer is that you don't have to worry about things like the EDT, and actions such as pausing between steps are done at a higher level. I don't know what you mean about timer changes coming from any asynchronous source, but I really don't see it being a problem.

For stuff like this, Timer is the way to go.

Originally Posted by 2by4

Of course you need a Timer. The OP is using Timer. That is not the issue. The issue is where the Timer sits -- in which thread?

The Timer MUST sit in a separate thread. Using a Swing GUI solves this only because the Swing GUI runs in its own thread. But this is assuming that the user is sitting there dictating when the timer speeds up and slows down.

What if the controlling information is on a set of 100 test files that are supposed to be read automatically, one after the other, and each contains information like -- start, run at speed A for twenty minutes, slow down to speed B for 30 minute, etc. then stop? You'd want this to run in batch mode. Nothing to do with a GUI.

So rather than harnessing the threading capabilities of a Swing GUI, you have to spawn the thread yourself.

Umm okay, but that's not this case. I said a Timer was the way to go here, for stuff like this, in this case. Threading has its own merits, but not here. And note that a Swing Timer does not have to run in a separate Thread- in fact, that wouldn't really change anything. It signals its ActionListener on the EDT. End of story. I'm not really sure what your point is here.

Originally Posted by 2by4

The OP didn't specify the case. You assumed it. Your assumption may, of course be right. I didn't assume.

Actually, he specified the case in the very first post. Also, if you look at the other posts he has made, you'll see exactly what he's trying to accomplish. I did the research. That's not making an assumption.

Originally Posted by 2by4

This is wrong. It does automatically run in it's own thread. That is one of its advantages. Obviously the animation and the timer shouldn't run in the same thread!!! You don't want them synchronous, lol!!!

Wrong. I'll repeat- a Swing Timer's ActionListener is fired on the EDT. That is not its own thread. In fact, that IS the same thread on which the animation, all painting, all events, and all GUI work is done. That's how it's supposed to work. I really suggest you do some reading on the EDT if you're going to make incorrect suggestions based on your misunderstanding.

Originally Posted by 2by4

But I think you are misunderstanding the problem. You have an animation, a timer and a controller (a process that is controlling the animation). The timer would normally be synchronous with the controller and should be asynchronous with the animation. So the controller would send an instruction to the animation, set the timer and wait for it to return before setting it for the next instruction. The animation, of course shouldn't wait (freeze) for the timer to return!!!

Wrong. For things like this, using a swing Timer and doing almost everything on the EDT is fine.

Originally Posted by 2by4

I hope you can see now?

I hope YOU can see now. Please do research before arguing. Write a simple program that includes a Swing Timer that controls an animation on a GUI. Print out the name of the current thread in the Timer, in paintComponent, and in an event. I guarantee you they're all on the EDT. Timers are not "on their own thread automatically". And using a Timer is fine for this kind of thing.

You're introducing incorrect advice, which will only serve to confuse the OP and any other visitors in the future. Please stop. Consider this a friendly warning. If you have more questions about how the EDT works, I suggest you create the program I just described and post any questions in your own thread.

Originally Posted by 2by4

No. Go and read it again. Nowhere does he say that a USER will change the speed. He just asks how the speed can be changed. You have ASSUMED that it is a USER and not another program.

That doesn't matter. What do you see as the important difference between a user changing the speed and the program changing the speed? There is no reason to use extra threads in either case.

Originally Posted by 2by4

Tell me, while the animation is running on EDT, what is the Timer doing?

What's your point? I said that Timers trigger their ActionListener on the EDT. The underlying implementation of a Timer is irrelevant to this conversation. You telling the OP that he has to use threading is not helpful.

Originally Posted by 2by4

And tell me, while the animation is keeping the EDT busy, do you think the "Start Button", the "Speed Up" button, the "Slow Down" button, the "Stop Button" are going to be responsive?

You seem to be under the impression that these animations are going to take forever. Simply changing a position or an image and calling repaint() are't going to take long at all. For longer tasks, such as file IO, you shouldn't use the EDT- but for things like this problem, using Timers is fine.

Originally Posted by 2by4

Take a look at this..

How to Use Swing Timers (The Java™ Tutorials > Creating a GUI With JFC/Swing > Using Other Swing Features)



Does that sound to you like the same thread?

Yes! The EDT is a single thread, and the timer "runs" on that thread by triggering its ActionListener on it. What the Timer does in between firings is of no concern to the OP. You seem to be insisting that the OP needs to implement multiple threads for this problem, and he simply doesn't! A Timer will work just fine.

Originally Posted by 2by4

And this..
Now go and think carefully why the animation images are loaded in a background thread.

Sigh. That's fine. That's not this case. I said that threading has a place, and loading things in background threads is one of those places. However, for this problem, in this discussion, threads are not necessary and only introduce unneeded complications. Using a Timer is fine, and only the EDT will be used (unless you want to be pedantic, in which case many threads are working under the hood, but that absolutely is not relevant to this discussion).

Like I said, if you want to continue this conversation, start your own thread.

Originally Posted by 2by4

You really don't understand do you? He is trying to change the speed of the animation WHILE IT IS RUNNING. Not wait for it to finish and then press the "Speed Up" button!!!

LOL, look, when you've understood the problem and read through the tutorial, we can it up from there.

Wrong. He's trying to change the speed of the animation WHILE THE SIMULATION IS RUNNING, as opposed to having to stop the simulation, change a value, recompile, and restart the simulation. That can be done by a user, from a GUI component's listener (on the EDT), or by the program, from the timer's ActionListener itself (also on the EDT). No user-defined threads are necessary. Like I said, these animations are not going to be taking very long, so "waiting for one to finish" will be invisible to the user. Please stop introducing unnecessary complications to the problem, and please stop hijacking the OP's thread. I've asked you nicely a few times now.

Originally Posted by KevinWorkman

Wrong. He's trying to change the speed of the animation WHILE THE SIMULATION IS RUNNING, as opposed to having to stop the simulation, change a value, recompile, and restart the simulation. That can be done by a user, from a GUI component's listener (on the EDT), or by the program, from the timer's ActionListener itself (also on the EDT). No user-defined threads are necessary. Like I said, these animations are not going to be taking very long, so "waiting for one to finish" will be invisible to the user. Please stop introducing unnecessary complications to the problem, and please stop hijacking the OP's thread. I've asked you nicely a few times now.

As I said WHILE THE ANIMATION IS RUNNING. I don't know why you have repeated it?

If the action listener for the speed up button is in the same thread, it won't respond WHILE THE ANIMATION IS RUNNING. That is why the tutorial says that the image loading happens in a background thread.

I don't know what you don't get. But I can see you are heading for moderator mode and trying to claim I am off topic. Don't worry, I will make my point. Do what you want.

Here is a program that adjusts the speed of an animation while the simulation is running. It also prints out the name of the current thread during painting, in the timer, and in the gui code.

import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Graphics;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
 
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JSlider;
import javax.swing.Timer;
import javax.swing.event.ChangeEvent;
import javax.swing.event.ChangeListener;
 
 
public class TimerTest extends JPanel {
 
 
	int ballX = 250;
	boolean goingRight = true;
 
	Timer timer;
 
	public TimerTest(){
 
 
		timer = new Timer(50, new ActionListener()
		{
			public void actionPerformed(ActionEvent event)
			{
 
				System.out.println("Timer, thread: " + Thread.currentThread().getName());
 
				if(goingRight){
					ballX++;
				}
				else{
					ballX--;
				}
 
				if(ballX >= getWidth()){
					goingRight = false;
					timer.setDelay((int) (Math.random() * 100));
				}
				else if(ballX <= 0){
					goingRight = true;
					timer.setDelay((int) (Math.random() * 100));
				}
 
				repaint();
			}
		});
		timer.setRepeats(true);
 
		timer.start();
 
		final JSlider timerSlider = new JSlider();
		timerSlider.setMinimum(0);
		timerSlider.setMaximum(100);
		timerSlider.addChangeListener(new ChangeListener(){
 
			@Override
			public void stateChanged(ChangeEvent e) {
				System.out.println("GUI, thread: " + Thread.currentThread().getName());
				timer.setDelay(timerSlider.getValue());
			}
		});
 
		JFrame frame = new JFrame("Timer Test");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 
		frame.add(this);
		frame.add(timerSlider, BorderLayout.SOUTH);
		frame.setSize(500, 500);
		frame.setVisible(true);
 
	}
 
	public static void main(String... args){
		new TimerTest();
	}
 
	public void paintComponent(Graphics g){
		super.paintComponent(g);
 
		System.out.println("Painting, thread: " + Thread.currentThread().getName());
 
		g.setColor(Color.RED);
		g.fillOval(ballX, getHeight()/2, 50, 50);
	}
 
}

The program prints out:

Timer, thread: AWT-EventQueue-0
Painting, thread: AWT-EventQueue-0
GUI, thread: AWT-EventQueue-0

...which shows that only a single thread is used, the EDT. The animation sets its own speed every time the ball hits a side, or the user can specify it by adjusting the slider.

If you still have questions, post them in your own thread.

Originally Posted by 2by4

OK, I won't say much more. Note that timer running in its own thread is not the same as its event listener running in its own thread. So that was a red herring from you.

Like I said, the underlying implementation details of a Timer don't really matter in this context. It was not a red herring, because it was my counter-point to your insistence that threads were necessary here. They aren't, since a timer "runs" in the EDT by firing an event on the EDT periodically. You seemed to think this would tie up the EDT and make the GUI unresponsive, which I've shown is not the case here.

Originally Posted by 2by4

The difference here, is that the controller (slider) is in the same thread as the animation. I am sure you know that such an implementation can freeze or lose critical responsiveness especially where speed is required, for precisely the reasons in my earlier posts. May work for a small ball on the screen. No good for a scientific application with substantial data.

That's fine, and I conceded that point outright. But we aren't talking about a scientific application with substantial data here; we're talking about a simple animation. It's true that long processes should never be done on the EDT. But simple animations and whatnot are absolutely fine on the EDT. A Timer works perfectly in this context. Threads are more trouble than they're worth in this instance. Telling the OP to use threads instead of a Timer was bad advice. That's okay, I've been known to give bad advice from time to time too.

Originally Posted by 2by4

Peace. I say no more on the subject :-)

Sounds reasonable to me. OP, sorry we hijacked your thread with our bickering. But hopefully you can use my example program to figure out what you could be doing.