![Quote](https://www.javaprogrammingforums.com/images/misc/quote_icon.png)
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.
![Quote](https://www.javaprogrammingforums.com/images/misc/quote_icon.png)
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.
![Quote](https://www.javaprogrammingforums.com/images/misc/quote_icon.png)
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.