Use of threads in an animation

[2by4]

Split off from this thread...

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.

Threads are necessary. As you found out, before conflating that fact with where its action listener runs. The timer RUNS in its own thread. If the timer (not its action listener) were running in the same thread, it would lock up the GUI.

You have shown nothing "here". The OP did not give details of how many pasture entities there could be, their interactions, the calculations for how they eat, feed, sleep etc. or whether it was for some substantial statistical analysis, which would be a reasonable assumption. He may even be designing an abstract class, where these values are indeterminate. Yet you are likening it to a ball pinging backwards on a screen?

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.

As I said, you are assuming what "this case" is.

You've also misunderstood what I wrote. No timer? No wonder you got all animated. Where did I say don't use a Timer?

I said there is a Timer a Controller and an animation. I said using a Swing Timer does not add much, and I meant in respect of a) using any basic Timer and b) isolating the controller UI.

Why not understand a position first, before arguing against it.

It is ALWAYS good practice to do things properly from the outset. There is no big deal in having a controller thread. A few lines of extra code.

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.

I am interested in the outcome, too and the application in general.

You asked me to stop, yet you keep bickering yourself. Anyway, rather than let you have that luxury, here I am with a new thread as you suggested. :-)

My point would be, Java Theory and Practice suggests that essentially asynchronous and independent processes should not be fudged as a single thread.

What do others think?

[KevinWorkman]

Threads are necessary. As you found out, before conflating that fact with where its action listener runs. The timer RUNS in its own thread. If the timer (not its action listener) were running in the same thread, it would lock up the GUI.

Sure, threads are necessary. There are plenty of threads working behind the scenes, and I'm not saying that they aren't important. My original argument was simply that telling a novice user to use threads when his assignment calls for a basic Timer was not very good advice. All I did was disagree and say that a Timer was the way to go- not only that, but it was required by the OP's assignment. This argument about threading is a bit moot. In this specific case, threads are not necessary. Sometimes they are. Not here. It's like telling an OP with an assignment requiring the use of arrays to use an ArrayList instead. Even if that's the "correct" way to go (which it is not guaranteed to be), it's not very good advice.

You have shown nothing "here". The OP did not give details of how many pasture entities there could be, their interactions, the calculations for how they eat, feed, sleep etc. or whether it was for some substantial statistical analysis, which would be a reasonable assumption. He may even be designing an abstract class, where these values are indeterminate. Yet you are likening it to a ball pinging backwards on a screen?

Actually, like I said, I based my answer off his previous posts. There are ~70 Entities, and Entity is an interface that different things implement. A Timer will work fine. But it doesn't really matter- the assignment calls for a Timer, not threading. Introducing threading to an already confused OP is bad advice. I simply disagreed with that advice.

As I said, you are assuming what "this case" is.

See above.

You've also misunderstood what I wrote. No timer? No wonder you got all animated. Where did I say don't use a Timer?

You told the OP:

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();

That's a far cry from what the assignment calls for, and what is appropriate in this instance.

Why not understand a position first, before arguing against it.

I understand your position fine. I simply disagree with it.

It is ALWAYS good practice to do things properly from the outset. There is no big deal in having a controller thread. A few lines of extra code.

Premature optimization is the root of all evil (good quote to google). Especially for a novice programmer. Especially for programs that work fine without any optimization. Especially for an assignment that requires using a Timer.

You asked me to stop, yet you keep bickering yourself. Anyway, rather than let you have that luxury, here I am with a new thread as you suggested. :-)

I am simply clarifying my argument, which you've somehow turned into a debate on the merits of threading, which was not my original point. All I said was I disagreed with your advice to use multithreading in a basic homework assignment that did not call for it.

My point would be, Java Theory and Practice suggests that essentially asynchronous and independent processes should not be fudged as a single thread.

Fine. But this is a simple animation that is not asynchronous or independent. You argued that it wasn't possible with a Timer because the GUI would freeze up, and even when I demonstrated this was outright false, you continue to disagree. I don't understand. The assignment does not call for threads, and the OP is confused. Telling him to use threads is not going to help him with his assignment or his confusion. That's it.

[2by4]

Firstly, I didn't realise this was a "novice" or an "assignment", and I do apologise for that.

I've been sitting here, thinking, "novice? assignment? basic?... , where are you getting all that from?"

I come from a scientific background, although I work as a contractor in the financial sector. I have come across specs very similar to the one in the OP, and the processing is HEAVY.

It is very possible that the inspiration behind the spec is from a real life scientific simulation, and not knowing the OP, he could have been anyone,.. a scientist asking for theoretical advice.

I went back to the opening post to scour for clues of where you are getting all your assumptions from, then I realised it can't be from the opening post, really..then I glanced across at the user name..

Maybe you have also helped this poster in the past?

I hope you can see that someone going on the opening post alone, would not necessarily agree with your assumptions of simplicity?

Now that I have realised the implications, I wholeheartedly agree with your approach.

Fine. But this is a simple animation that is not asynchronous or independent. You argued that it wasn't possible with a Timer because the GUI would freeze up, and even when I demonstrated this was outright false, you continue to disagree.

You continue to ignore the facts. This is what I said in post #9 of that thread..

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.

This states that a "Timer" is necessary and works with a Swing GUI.
Repeating your false claims won't make them true. You misunderstood, simple.

[KevinWorkman]

Firstly, I didn't realise this was a "novice" or an "assignment", and I do apologise for that.

I've been sitting here, thinking, "novice? assignment? basic?... , where are you getting all that from?"

I come from a scientific background, although I work as a contractor in the financial sector. I have come across specs very similar to the one in the OP, and the processing is HEAVY.

It is very possible that the inspiration behind the spec is from a real life scientific simulation, and not knowing the OP, he could have been anyone,.. a scientist asking for theoretical advice.

I went back to the opening post to scour for clues of where you are getting all your assumptions from, then I realised it can't be from the opening post, really..then I glanced across at the user name..

Maybe you have also helped this poster in the past?

I hope you can see that someone going on the opening post alone, would not necessarily agree with your assumptions of simplicity?

Now that I have realised the implications, I wholeheartedly agree with your approach.

Yeah, I've helped him in another thread where he spelled out his assignment in more detail. But I've been doing this for a while, and I'm pretty good at spotting homework versus a complicated scientific question. I tried telling you that in the last thread, when you were telling me I was making invalid assumptions. For the future, you can click on a person's user name to get a history of the posts they've made. This might help you determine whether a person is asking a homework question or not.

You continue to ignore the facts. This is what I said in post #9 of that thread..

This states that a "Timer" is necessary and works with a Swing GUI.
Repeating your false claims won't make them true. You misunderstood, simple.

I didn't misunderstand anything. You claimed that the OP had to place a Timer into its own thread so that it wouldn't block the EDT. That's simply not true, and I suggested that you create a small program to test your assumptions, which you did not do. So I finally had to demonstrate my points in a program that I posted in the previous thread. The program consisted of exactly what you said was not possible- a Timer that controlled an animation, without blocking the EDT, and responded to both user and program-driven changes in speed, which you claimed would require the use of multiple programmer-created threads. I'm not sure why we're still having this conversation. You were wrong, and that's okay. Time to learn from it and move on.

[2by4]

Yeah, I've helped him in another thread.

Right. Next time, you can perhaps try to see things from the perspective of someone JUST LOOKING AT THE OP and stop making IMPLICIT references to some earlier conversation I knew nothing about. Why not EXPLICITLY refer to the earlier thread??? And, no, it is not my responsibility to be rooting about for clues. OP should say it is an assignment for a basic java course. That obviously makes more sense that posters to the thread rooting about for possible clues!

I didn't misunderstand anything. You claimed that the OP had to place a Timer into its own thread so that it wouldn't block the EDT. That's simply not true,....

What it is, is that you don't know, or don't accept when you have misunderstood something. I stated categorically that it would work in a swing application. The swing timer ALREADY operates in its own thread as I categorically stated. <---- You misunderstood that, too, and started talking about its listener thread. There is no point arguing any further with you about it. Nothing is going in.

[KevinWorkman]

Right. Next time, you can perhaps try to see things from the perspective of someone JUST LOOKING AT THE OP and stop making IMPLICIT references to some earlier conversation I knew nothing about.

There was no implication- I told you to look at the OP's other posts as soon as you started this pointless arguing. You could have ended it right there.

But I've done my research on you, and from what you've said in other posts here and on other forums, I see that this is a bit of a pattern for you. You make statements that are categorically not true, and then you become overly defensive when other people call you out on it, shifting your argument just for the sake of arguing. I'm not really here to argue. I've tried to explain the reasons why the things you've said have either been false or simply bad advice, but you continually come back with non sequiturs and personal attacks. You might consider taking a moment to think about your approach- these are technical forums, and the only thing that really matters is the technical usefulness of your advice. I've shown you why your advice in this instance was not technically useful. Personal attacks don't really have a place here.

I've shown you why your advice was invalid, and you seem to be conceding that point, yet you continue to argue because of some vague notion that I didn't see things from your perspective. Perspective is irrelevant. Your advice was bad. I don't really care why, as long as you learn from the experience. Maybe you've learned that many questions here are indeed homework. Maybe you've learned that over complicating things isn't a good idea. Maybe you've learned to try out sample programs to test your assumptions. Or maybe you'll just keep arguing pointlessly.

Why not EXPLICITLY refer to the earlier thread??? And, no, it is not my responsibility to be rooting about for clues. OP should say it is an assignment for a basic java course. That obviously makes more sense that posters to the thread rooting about for possible clues!

I'm all for people with questions posting all relevant information. But 90% of the time, questions here are indeed homework assignments. It's not unreasonable to assume that any particular question is homework- in fact, that's a great practice to get into, as perhaps you've learned here. And when you started this incessant arguing, I told you to check out the OP's older posts so you would understand what we were talking about. However, even if this had not been a homework assignment, your advice was still pretty bad, and your claims were still simply wrong.

What it is, is that you don't know, or don't accept when you have misunderstood something. I stated categorically that it would work in a swing application. The swing timer ALREADY operates in its own thread as I categorically stated. There is no point arguing any further with you about it. Nothing is going in.

Here are some excerpts of what you said, keeping in mind that the OP's question was how to set the delay of a Swing Timer:

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();
The Timer MUST sit in a separate thread.
Obviously the animation and the timer shouldn't run in the same thread!!! You don't want them synchronous, lol!!!
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!!!
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?
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!!!
If the action listener for the speed up button is in the same thread, it won't respond WHILE THE ANIMATION IS RUNNING.

You also threw in a bunch of non sequiturs about why threading is useful in certain cases, which was entirely beside the point. I told you to write a small program that tested your above statements, and when you refused, I did it for you. I posted a program that demonstrates the untruth of your arguments, and I explained to you several times now why your advice was wrong. Shifting the argument to "but you didn't see things from my perspective!" is irrelevant. I did know where you were coming from. And even if I hadn't, it wouldn't change the fact that you were wrong. I can't just let people post incorrect advice to an already confused OP.

There's really no point in being defensive. I have no interest in arguing; my only motivation is that we can't have bad advice being given out on the forums. I highly advise you to chalk this one up to a lesson learned and move on.