Animated Multi-Thread Graphical Object Instances Painting To The Same JPanel

[Christopher Dodunski]

Greetings all,

I'm new to Java Graphics, and am developing an app that displays ships on top of an aerial view of a harbour.  I followed some online tutorials and successfully used GeneralPath to draw ships within a class extended from JPanel.  As we live and program in an object oriented world, I then decided to create a ShipShape class and delegate drawing of each ship to that class by way of forwarding a Graphics2D reference from the JPanel class to the ShipShape class constructor.  This, too, was successful.

Finally I decided to take the next natural step: make each ShipShape instance run in its own thread, so each could exist independently of any another.  Each ship instance would also incorporate some simple animation, and this also influenced my decision to use threads, so any animation could occur within a loop inside a run() method.  Unfortunately, converting ShipShape to a Runnable class has not been successful - instances of ShipShape no longer draw to the JPanel screen.

I'm wondering if the Graphics2D reference passed to the ShipShape constructor gets broken now that ShipShape runs in a separate thread.  I've attached an abbreviated version of my three classes below.  Fully grasping multi-threading in Java graphics must be a vital skill.  I imagine that Java, animated, game characters would ideally exist within their own thread, right?

Possibly complicating matters is the intention that ship animations may differ slightly from instance to instance - some appear static, some contain flashing lights, some incorporate moving lights (like a battery charging indicator), etc.  Therefore, having the JPanel simply iterate through a ListArray<ShipShape>, sequentially repainting ShipShape instances one after the other, would be problematic - animations wouldn't occur simultaneously.

Your guidance would be greatly appreciated.

Thanks & regards,

Chris.

public class HarbourFrame extends JFrame{
 
    public HarbourFrame(){
        initUI();
    }
 
    private void initUI(){
        add(new HarbourPanel());
        setTitle("Harbour Application");
        setSize(1024, 768);
        setLocationRelativeTo(null);
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    }
 
    public static void main(String[] args){
        EventQueue.invokeLater(new Runnable(){
 
            @Override
            public void run(){
                HarbourFrame hf = new HarbourFrame();
                hf.setVisible(true);
            }
        });
    }
}

class HarbourPanel extends JPanel{

    private Image background;
 
    private void loadImage(Graphics g){
        Graphics2D g2d = (Graphics2D) g;
        background = new ImageIcon("res/images/Port.jpg").getImage();
    }
 
    private void doDrawing(Graphics g){
        ShipShape ship1 = new ShipShape("thread1", (Graphics2D)g.create(), 40f, 200f, 450f, 242f);
        ship1.rotate(80);
        ship1.start();
    }
 
    @Override
    public void paintComponent(Graphics g) {
        super.paintComponent(g);
        //setBackground(new Color(0,50,150));
        loadImage(g);
        doDrawing(g);
    }
}

public class ShipShape implements Runnable{

    private final Thread runner;
    private volatile boolean shouldStop = false;
    private Graphics2D g2d;
    private GeneralPath hull;
    private GeneralPath accommodation;
    private float width;
    private float height;
    private RoundRectangle2D led1;
    ... etc
 
    public ShipShape(String threadName, Graphics2D g2d, float width, float height, float xPosition, float yPosition) {
        runner = new Thread(this, threadName);
        this.g2d = g2d;
        this.width = width;
        this.height = height;
 
        g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
        g2d.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
        g2d.translate(xPosition, yPosition);
        g2d.rotate(Math.toRadians(0));
    }
 
    public void sketchHull(){
 
        hull = new GeneralPath();
 
        ... Draw hull
 
    }
 
    public void sketchAccommodation(){
        accommodation = new GeneralPath();
 
        ... Draw accommodation
    }
 
    //Rotate ship
    public void rotate(int degrees){
        g2d.rotate(Math.toRadians(degrees));
    }
 
    public void start(){
        runner.start();
    }
 
    public void stop(){
        shouldStop = true;
    }
 
    public void run(){
        while(!shouldStop) {
            g2d.setPaint(new Color(40, 40, 40));
            sketchHull();
            g2d.fill(hull);
            g2d.setColor(new Color(230, 230, 230));
            sketchAccommodation();
            g2d.fill(accommodation);
 
            ... Other drawing code
 
            System.out.println("Thread: " + Thread.currentThread().getName() + " is running!");
            System.out.println("Variable values: Width " + String.valueOf(width) + ", Length: " + String.valueOf(height));
            try{
                Thread.currentThread().sleep(1000);
            } catch(InterruptedException e){
                System.out.println(e.getStackTrace());
            }
        }
    }
}

[Norm Radder]

The posted code won't compile with the ...
Could you post code that will compile so it can be executed for testing.

Is the GUI drawing being done on the EDT?  Use a SwingWorker to make sure GUI changes are on the EDT.

[Campbell Ritchie]

As you doubtless know, Swing components are as a general rule not thread‑safe. So don't try animation with multiple threads. Use a Swing Timer instead. Any events from a Swing timer are injected into the EDT.
I do not know how long it would take to iterate a List and paint all the shapes therein, but try and see whether that can be done in 25ms or so. Remember we cannot see changes occurring faster than about 25−40ms.

[Brian Cole]

Christopher Dodunski wrote:
As we live and program in an object oriented world, I then decided to create a ShipShape class and delegate drawing of each ship to that class by way of forwarding a Graphics2D reference from the JPanel class to the ShipShape class constructor.  This, too, was successful.

I haven't had time to look closely at your code but, with that caveat, this approach is problematic, and I mean even before the multi-threading stuff you're asking about. When I first read this sentence my interpretation is that your implementation was definitely incorrect. On second reading I realize it's somewhat ambiguous and possibly what you were doing (before the multi-threading stuff) was ok. So it depends.

But in general, it's a mistake to forward a Graphics2D reference around. You should pretend that the Graphics2D object was created just before your JPanel's paint() method is called, exists for the duration of the call, and is destroyed afterward. That's not really what happens, but it would be a mistake to make any assumptions otherwise. So if your paint() method passes the Graphics2D object to a different method, or even a tree structure of methods, which is used briefly for painting, then that's absolutely fine. But if you're passing the Graphics2D to something that saves the reference in a field with plans to use it later, you really need to restructure your code not to do that. (This is what your ShipShape class is doing, which is bad, but I don't know if you were doing it that way in your pre-multi-threaded code.)

The correct way to do this, or at least a correct way, would be for your ShipShape objects to essentially have a paint() method of their own which takes a Graphics2D object as an argument and uses it only briefly. Then your HarbourPanel would keep a list of ShipShape objects (or whatever) and its paint() method would iterate through the ShipShape objects calling each paint method in a single thread. If you want to do multi-threaded stuff that's fine, but those other threads should manipulate the state of the ShipShape objects and/or the HarborPanel but not interfere with painting. The methods provided by the Graphics2D class should only be called by the single event dispatch thread. Does that make sense? (The other threads may, and probably should, call the HarbourPanel's repaint() method, which is documented to be thread-safe, when they realize they need to be redrawn. That wouldn't count as "interering with painting.")


While I'm here let me mention that you probably don't want to be instantiating new ImageIcons or new ShipShapes within paint() or paintComponent(). You want paint()/paintComponent() to be fast, and loading ImageIcons is slow. Instantiating ShipShapes is not especially slow so possibly that's ok, but typically you would set up your ImageIcons and ShipShapes in the initialization phase, so they're already there when paint() gets called.

BTW no big deal but HarbourPanel could probably extend JComponent instead of JPanel.

[Christopher Dodunski]

Thank you all very much for your advice.

Summarising... Having each ShipShape instance run in its own thread is not in itself wrong.  However, having these instances retain a reference to a Graphics2D instance instantiated in HarbourPanel, and then proceeding to produce animation by repeatedly "pushing" graphical changes to this reference would be wrong.

You are suggesting two alternative approaches:

(1)  HarbourPanel stores instances of ShipShape instances in a ListArray<ShipShape>, and then iterates through it, one by one calling each ShipShape instance's paint(g2d) method to reflect on screen a graphical representation of each's current state.  I guess you could consider this a "pull" approach, as JPanel is systematically pulling state from each ShipShape instance.

(2)  Each ShipShape instance/thread calls JPanel whenever it changes state - for instance a new frame of an animation is generated - and JPanel (as above) invokes that ShipShape instance's paint(g2d) method to reflect that change.  I guess you could consider this a "push" approach, as unless a ShipShape instance pushes a change, JPanel sits idle.

My question is, given the variety of animations possible with each ShipShape instance - some flashing lights (2 frame animation), some chasing lights (up to an 11 frame animation), and some not animating at all (static) - is option (2) above the only viable solution?

Finally (re the first two replies), I assume SwingTimer could form part of option (1) for iterating through the ArrayList, whereas SwingWorker could be an alternative to multi-threading (animations would be generated in the "background" rather than within a loop of a thread's run() method).

Thanks & regards,

Chris Dodunski.

[Brian Cole]

Christopher Dodunski wrote:You are suggesting two alternative approaches:

Not really. You need them both:
(1) HarbourPanel.paintComponent() iterates through the list of ShipShapes calling each ShipShape instance's paint(g2d) method.
(2) When a ShipShape object changes its state (or if the harbour itself does) then call HarbourPanel.repaint(). Not paint() or paintComponent(), but repaint(), which is different.

Note that calling repaint() doesn't do any immediate painting. But it does alert the system that it needs to call the paint() method before too long. To use your terminology (which I must admit I don't quite follow) it doesn't push but it requests a pull.

[Piet Souris]

Another possibility that I sometimes use mimicks the way one programmed for the old Atari and Commodore 64 machines.

Say you have two BufferedImages, called 'display' and 'draw', each the size of your Harbour image.
Now, you could have a SwingWorker that lets each ShipShape update its state. It then draws the harbourimage into 'draw', and next let each ShipShape also draw itself to 'draw'. Once that is finished, it renames 'draw' to 'display' and vice versa. Then it repeats the cycle.

Meanwhile, whenever the SwingTimer fires, the Harbourpanel just draws 'display' into its panel. It couldn't care less what's in that image, or what made that image.

By the way: you have a very complicated way of executing your ShipShape runnables.
The normal way to start a Runnable rb is either via 'new Thread(rb).start' or letting an Executor execute r.
But why do you want your ShipShape to be a Runnable? If you have more than a handfull of ships, then you soon run out of available Threads (unless you have the very latest Intel or AMD processors). The idea that each ship can do its own animation if it is running in its own Thread is not plausible. You only see one moment of such an animation when the panel is repainting. Having each ship call redraw whenever it feels like it does not seem like a good idea to me either. Wouldn't you need some way of coordination then?

[Christopher Dodunski]

Hi all,

My reason for taking the (seemingly misguided) multi-thread route was largely to satisfy the requirement for multiple, simultaneous animation.  Complicating matters is the fact that animations may differ from ship to ship.  For instance, a flashing light animation would comprise 2 frames and repeat every 1 second.  Whereas a 'chasing light' animation may comprise up to 11 frames and repeat every 5 seconds.  With JPanel handling all such animation in a single thread, by iterating through a ListArray<ShipShape>, what would happen to remaining ships while JPanel was occupied generating a 5 second animation for just one?

I guess a solution is having JPanel paint just one frame of an animation before iterating to the next ship, but this didn't strike me as efficient coding.  Perhaps I am wrong and this is perfectly fine?

Thanks & regards,

Chris.

[Brian Cole]

Maybe it's easiest to write some quick demo code.

The following code tries to take your approach but do it "right". If I were doing this on my own I don't think I'd give each drawn object its own thread. I'd probably use a timer (probably a java.util.Timer rather than a javax.swing.Timer in this particular case) or an event queue or something of that ilk.

import java.awt.Color;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.util.ArrayList;
import java.util.List;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;

/**
 * Demo: Draw some things where each thing changes its state in its own thread.
 * @author Brian Cole
 */
public class Dodunski {

	public static void main(String[] argv) {
		SwingUtilities.invokeLater( () -> new Dodunski().startup() );
	}

	public void startup() {
		JFrame frame = new JFrame("Harbor");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setContentPane(new Harbor());
		frame.setSize(180, 120);
		frame.setVisible(true);
	}

	public static class Harbor extends JComponent {
		private List<BallWithOwnThread> balls = new ArrayList<>();

		public Harbor() {
			balls.add( new BallWithOwnThread(Color.BLUE, 32, 64, 12, 1, 2, 101, false, this) );
			balls.add( new BallWithOwnThread(Color.CYAN, 32, 32, 12, 2, 1, 227, true, this) );
		}

		@Override
		protected void paintComponent(Graphics g) {
			super.paintComponent(g); // handle opaqueness
			Graphics2D g2 = (Graphics2D)g;
			balls.forEach( ball -> ball.paint(g2) );
		}
	} // end static class Harbor

	/**
	 * Few of us would argue that each Ball should have its own thread,
	 * especially if there are going to be a large number of balls, but
	 * this is a proof-of-concept that the approach can work.
	 */
	public static class BallWithOwnThread implements Runnable {
		private Color color;
		private int x, y, radius, dx, dy, milliseconds;
		private boolean blink, visible=true;
		private JComponent parent;

		public BallWithOwnThread(Color color, int x, int y, int radius, int dx,
				  int dy, int milliseconds, boolean blink, JComponent parent) {
			this.color = color;
			this.x = x;
			this.y = y;
			this.radius = radius;
			this.dx = dx;
			this.dy = dy;
			this.milliseconds = milliseconds;
			this.blink = blink;
			this.parent = parent;
			// create and start this object's thread
			new Thread(this).start();
		}

		public void paint(Graphics2D g) {
			// Draw the ball. Don't change state.
			if (visible) {
				g.setColor(color);
				g.fillOval(x-radius, y-radius, 2*radius, 2*radius);
			}
		}

		@Override
		public void run() {
			// Change state in a loop.
			for ( ; ; ) {
				// Again, Thread.sleep() is probably not the best approach but,
				// since we decided to go that way, it does actually work.
				try {
					Thread.sleep(milliseconds);
				} catch (InterruptedException e) {
					e.printStackTrace();
					return;
				}
				// change the ball's state
				int xOld = x, yOld = y;
				x += dx;
				y += dy;
				bounce();
				if ( blink ) visible = !visible;
				// note: The zero-argument repaint() could replace next two lines.
				parent.repaint(x-radius, y-radius, 2*radius, 2*radius);			
				parent.repaint(xOld-radius, yOld-radius, 2*radius, 2*radius);
			}
		}

		private void bounce() {
			// note: One could argue that parent.getWidth() and getHeight()
			// are not thread-safe. That's something worth pondering.
			int parentWidth = parent.getWidth();
			if (x > parentWidth) { x = 2*parentWidth - x; dx = -dx; }
			else if (x < 0) { x = -x; dx = -dx; }
			int parentHeight = parent.getHeight();
			if (y < 0) { y = -y; dy = -dy; }
			else if (y > parentHeight) { y = 2*parentHeight - y; dy = -dy; }
		}
	} // end static class BallWithOwnThread

}

[Les Morgan]

You have elements of animation from using the EDT and Technics commonly used in full screen manually controlled animations. The manual animations characteristically block the events scheduled on the EDT and everything just seemingly stops or become unpredictable at best.

Get rid of your infinite loop processing -- while(true) -- or get rid of your EDT reliance. Use manual or EDT, but rarely have I seen them merged successfully as an early learning exercise.

[Brian Cole]

Les Morgan wrote:You have elements of animation from using the EDT and Technics commonly used in full screen manually controlled animations. The manual animations characteristically block the events scheduled on the EDT and everything just seemingly stops or become unpredictable at best.

Get rid of your infinite loop processing -- while(true) -- or get rid of your EDT reliance. Use manual or EDT, but rarely have I seen them merged successfully as an early learning exercise.

First of all, I'm not claiming to have any problem with my code. IMHO, it is correct. (Modulo each ball having its own thread, which I usually wouldn't do but was trying to help the original poster with his implementation using this approach.)

Second of all, I don't understand your complaints. I'm not dismissing them, but will you clarify why you object. I'll try to address what I can.

"The manual animations characteristically block the events scheduled on the EDT" • Nowhere in my code is the EDT blocked. If you think otherwise, please tell me what line number(s) you're worried about.

"Get rid of your infinite loop processing" • If you're talking about the sleep-within-loop idiom used here, then I agree. It would be better to take a different approach. But, given this approach, the infinite loops are appropriate.

"or get rid of your EDT reliance" • What are you talking about? The only thing that happens on the EDT in this is the painting. Everything else happens on other threads.

[Piet Souris]

Brian wrote: "The manual animations characteristically block the events scheduled on the EDT"
• Nowhere in my code is the EDT blocked. If you think otherwise, please tell me what line number(s) you're worried about.

I think Les could have a point here.
If you look at the paintComponent method in the Harbour class, it does

balls.forEach( ball -> ball.paint(g2) );

It could well be that one (or more) of the balls Threads is sleeping at that moment. What happens in that case? Does the EDT wait? I have no java at my disposal currently, so I can't check.

[Tony Docherty]

Piet Souris wrote:

Brian wrote: "The manual animations characteristically block the events scheduled on the EDT"
• Nowhere in my code is the EDT blocked. If you think otherwise, please tell me what line number(s) you're worried about.

I think Les could have a point here.
If you look at the paintComponent method in the Harbour class, it does

balls.forEach( ball -> ball.paint(g2) );

It could well be that one (or more) of the balls Threads is sleeping at that moment. What happens in that case? Does the EDT wait? I have no java at my disposal currently, so I can't check.

That shouldn't cause the EDT to block as the thread that may be sleeping is not the EDT.
What may be a problem though is there is no proper synchronization so the paint method may be painting the ball as the x and y values are being changed. Also shouldn't the 'visible' variable be declared as volatile as it is being used by two different threads.

[Brian Cole]

Piet Souris wrote:It could well be that one (or more) of the balls Threads is sleeping at that moment. What happens in that case? Does the EDT wait? I have no java at my disposal currently, so I can't check.

That doesn't make sense. If the EDT wants to call a ball's paint method, it goes ahead and calls it. If that ball's private thread is sleeping (which it will be 99% of the time) that's completely irrelevant as far as the EDT is concerned. The threads don't share a lock or anything. (The balls' private threads don't do any locking at all.)

Tony Docherty wrote:
What may be a problem though is there is no proper synchronization so the paint method may be painting the ball as the x and y values are being changed. Also shouldn't the 'visible' variable be declared as volatile as it is being used by two different threads.

This is definitely as issue. If you want the balls' movement to happen atomically then you would have to write code to do that, taking care not to slow down the paint() method too much. In this program I don't care if I paint a ball in which, say, the x has changed and the y hasn't yet, because the animation will pretty much still be ok. It's easy to be cavalier in simple demos like this one. The original poster might not have that luxury.

visible is being used in two threads in the same way that x, y, and the others are. The private thread is read/writing it and the EDT is accessing it read-only. If the private thread is changing the visible value concurrently with an EDT paint, I don't care if paint() draws it visible or invisible. Either is fine to achieve the blinking animation effect. This is a luxury the original poster probably does have, unless he has stringent requirements about how the blinking needs to look.


I still maintain that my code is sound. If the original poster wants each ShipShape object to have its own thread to change its position and heading, then this is the kind of approach he should take. But of course I'm willing to consider further objections.

[Brian Cole]

Tony Docherty wrote:Also shouldn't the 'visible' variable be declared as volatile as it is being used by two different threads.

Sorry, I talked about the two threads but I didn't talk about volatile. Yes, I think it might be smart to declare x, y, and visible to be volatile. It didn't occur to me but it should have. Without volatile I don't think there is any guarantee that the EDT thread will ever see changes to those variables, though of course in practice it does eventually.

[Piet Souris]

Brian Cole wrote:

Piet Souris wrote:It could well be that one (or more) of the balls Threads is sleeping at that moment. What happens in that case? Does the EDT wait? I have no java at my disposal currently, so I can't check.

That doesn't make sense. (...)

I was only asking, but you are right: there are no stupid answers, only stupid questions.

Just tested this at home. The code works without any problem, no matter how hard I tried by resizing the panel as fast as I could. The 'paint' method is not affected in any way by the Thread executing the 'run' method. This is new to me, and if I had a chance to test this earlier, I wouldn't have asked.

[Brian Cole]

Piet Souris wrote:Just tested this at home. The code works without any problem, no matter how hard I tried by resizing the panel as fast as I could. The 'paint' method is not affected in any way by the Thread executing the 'run' method. This is new to me, and if I had a chance to test this earlier, I wouldn't have asked.

Thanks for the retraction.

It's funny that you mention resizing the panel, because I think the bounce() method does have a bug related to that. If you size the panel big and wait for a ball to get at the very bottom (or very right) then quickly resize to very small, the code in bounce() doesn't handle this correctly and the ball can get 'lost' with coordinates outside the visible area. I realized this when I wrote it, but I decided to keep the code simple and not address it. (Again, it's easy to be cavalier in simple demos.) I did try to "lose" a ball this way several times but failed each time, but I think it's possible if things go just right.

[Tony Docherty]

Brian Cole wrote:
I still maintain that my code is sound. If the original poster wants each ShipShape object to have its own thread to change its position and heading, then this is the kind of approach he should take. But of course I'm willing to consider further objections.

I agree and sorry if my post came across as criticism. I was originally posting to support your code with regard to the thread locking suggestion and then noticed a couple of issues which as you say probably aren't critical given the actual application. I tacked those comments onto the end of the post just before having to rush out and probably should have worded it better.

I did try to "lose" a ball this way several times but failed each time, but I think it's possible if things go just right.

Or just wrong  

[Norm Radder]

I'm taken Brian's nice code and messed it up a bit to try another solution:  Use one thread with a ScheduledThreadPoolExecutor object to schedule ball movements.  I've found that ScheduledThreadPoolExecutor loses tasks and leaves more and more balls unmoved over time.  I've run out of ideas on how to fix this.

Here is Brian's code with my mess:

/* https://coderanch.com/t/682689/java/Animated-Multi-Thread-Graphical-Object

Note: Added executor ->>> Problem: loses tasks???
*/

import java.awt.Color;
import java.awt.Graphics;
import java.awt.*; //Graphics2D;
import java.util.ArrayList;
import java.util.*; //List;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
import java.util.concurrent.*;

 
/**
 * Demo: Draw some things where each thing changes its state in its own thread.
 * @author Brian Cole
 */
@SuppressWarnings("serial")

public class Dodunski {

    ScheduledThreadPoolExecutor executor;
    int width = 900;
    int height = 700;
    int nbrBalls = 50;           // loose movements with 100    / 2 unmoved with 50  / no unmoved with 30
 
    public static void main(String[] argv) {
//       System.out.println("main thread="+Thread.currentThread());    // main thread=Thread[main,5,main]     
       SwingUtilities.invokeLater( () -> new Dodunski().startup() );
    }
 
    public void startup() {
//        System.out.println("startup thread="+Thread.currentThread()); // startup thread=Thread[AWT-EventQueue-0,6,main]
        JFrame frame = new JFrame("Harbor");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        executor =  new ScheduledThreadPoolExecutor(1);       //<<<<<<< do all on one thread?   same with 4 ???
        frame.setContentPane(new Harbor());
        frame.setSize(width, height);
        frame.setVisible(true);
    }

    // See if synchronized is the cause of losing tasks >>>> No change, still loses tasks
    synchronized void doSchedule(Callable<String> ball, long time) {
        ScheduledFuture<String> sf = executor.schedule(ball, time, TimeUnit.MILLISECONDS);
        if(sf.getDelay(TimeUnit.MILLISECONDS) <= 0) {
          System.out.println(sf.getDelay(TimeUnit.MILLISECONDS));     //NEVER
        }
    }

    //====================================================================
    public class Harbor extends JComponent {
        private java.util.List<BallWithOwnThread> balls = new ArrayList<>();
            Random ran = new Random();
 
        public Harbor() {                //              x   y   rad dx dy ms   blnk         start
            balls.add( new BallWithOwnThread(Color.BLUE, 32, 64, 12, 1, 2, 101, false, this, true) );
            balls.add( new BallWithOwnThread(Color.GREEN, 32, 32, 12, 2, 1, 227, true, this, true) );

            // add a bunch with own threads      >> CPU usage 40% 
            for(int i=0; i < 0; i++) {      // java.lang.OutOfMemoryError: unable to create new native thread  w/4000 
               int x = ran.nextInt(width);
               int y = ran.nextInt(height);
               int dx = (x > width/2) ? -2 : 2;  // different directions depending on starting loc
               int dy = (y < height/2 ? 1 : -1);
               int speed = 100 + ran.nextInt(300);
               Color aColor = new Color(x%255, y%255,ran.nextInt(255));
               balls.add( new BallWithOwnThread(aColor, x, y, 12, dx, dy, speed, false, this, true) );
            }

            // define some to use one thread with executor   >>  CPU usage  40%
            BallWithOwnThread bwot = null;
            long start = 0L;
            for(int i=0; i < nbrBalls; i++) {
               int x = ran.nextInt(width);
               int y = ran.nextInt(height);
               int dx = (x > width/2) ? -2 : 2;  // different directions depending on starting loc
               int dy = (y < height/2 ? 1 : -1);
               int speed = 100 + ran.nextInt(300);
               Color aColor = new Color(x%255, y%255,ran.nextInt(255));
               balls.add(bwot = new BallWithOwnThread(aColor, x, y, 12, dx, dy, speed, false, this, false) );
               executor.schedule((Callable<String>)bwot, start++, TimeUnit.MILLISECONDS);
            }

            //- - - - - - - - - - - - - - - - - - - - 
            System.out.println("starting Q size="+ executor.getQueue().size());   // starting Q size=4000

            //  Some balls are not moving >>> Try to find them???
            Thread t = new Thread(new Runnable() {
               public void run() {
                  while(true) {
                     try{Thread.sleep(5000);}catch(Exception x){}
                     int cnt = 0;
                     for(BallWithOwnThread bwot : balls) {
                        if(!bwot.checkMoved())  {
                           cnt++;
                        }
                     }
                     System.out.println("Q size="+ executor.getQueue().size() +", unmoved balls = "+cnt);
                     //     Some stop moving after a bit???
                     /*
                     Q size=3960, unmoved balls = 0
                     Q size=3894, unmoved balls = 60
                     Q size=3795, unmoved balls = 113
                     Q size=3733, unmoved balls = 205
                     Q size=3647, unmoved balls = 275

                      ballId=28 java.awt.Point[x=148,y=575] moveCnt=274    <<  This ball was not moving

                     */
                  }
               }
            });
            t.start();

            // MouseListener to allow seletion of a ball
            addMouseListener(new javax.swing.event.MouseInputAdapter() {
               @Override
               public void mousePressed(java.awt.event.MouseEvent me) {
//                  System.out.println("mP at="+me.getPoint());
                  for(BallWithOwnThread bwot : balls) {
                        if(bwot.onBall(me.getPoint()))  {
                           System.out.println("ballId="+bwot.ballId + " " +bwot.getLocation() + " moveCnt="+bwot.movedCnt);
                        }
                  }

               }
            });
        }    // end constructor
 
        @Override
        protected void paintComponent(Graphics g) {
            super.paintComponent(g); // handle opaqueness
            Graphics2D g2 = (Graphics2D)g;
            balls.forEach( ball -> ball.paint(g2) );   //??? don't call if not moved!!!
        }
    } // end static class Harbor

    //---------------------------------------------------------------
    //  Fields for saving delay times
    static int[] delays = new int[21];  // hold 1-20 and > 20
    static int cntr = 0;

    static int id = 0;    //  to give ball objects unique ids
 
    /**  ====================================================================================
     * Few of us would argue that each Ball should have its own thread,
     * especially if there are going to be a large number of balls, but
     * this is a proof-of-concept that the approach can work.
     */
    public  class BallWithOwnThread implements Runnable, java.util.concurrent.Callable<String> {
        private Color color;
        private volatile int x, y; 
        int radius, dx, dy, milliseconds;
        private boolean blink, 
                        visible=true;
        private JComponent parent;

        private boolean moved = true;   // to record when paint called w/o a move being done
        int ballId = id++;

        public volatile int movedCnt = 0;   // to detect if any balls are not moved >>> all are moving ???
 
        public BallWithOwnThread(Color color, int x, int y, int radius, int dx,
                  int dy, int milliseconds, boolean blink, JComponent parent, boolean startThread) {
            this.color = color;
            this.x = x;
            this.y = y;
            this.radius = radius;
            this.dx = dx;
            this.dy = dy;
            this.milliseconds = milliseconds;
            this.blink = blink;
            this.parent = parent;
            // create and start this object's thread
            if(startThread)   {                //<<<<<<<<
               new Thread(this).start();
            }
        }
 
        public boolean onBall(Point p) {
            return (p.x > x-radius) && (p.x < x+radius)
                   && (p.y > y-radius) && (p.y < y+radius); 
        }
        public Point getLocation() {
           return new Point(x,y);
        }

        public void paint(Graphics2D g) {
//            if(!moved)  return; //<<<<<<<    makes for poor drawing when balls cross paths
//            System.out.println("thread="+Thread.currentThread());  // thread=Thread[AWT-EventQueue-0,6,main]    
            // Draw the ball. Don't change state.
            if (visible) {
                g.setColor(color);
                g.fillOval(x-radius, y-radius, 2*radius, 2*radius);
            }
            if(moved) {
              moved = false;
            }else {
//               System.out.println("paint called w/o move "+ballId);   //<<<<<<<<<<<<
            }
        }

        //---------------------------------------------------------
        long lastCall = 0L;     // to compute delays

        @Override
        public String call() {
           long currTime = System.currentTimeMillis();
           if(lastCall != 0) {
              int delay = (int)(currTime - lastCall); 
              delay -= milliseconds;
              if(delay < delays.length) delays[delay]++;
              else delays[delays.length-1]++;
              if(delay >  2) { // only show some
//                  System.out.println(">>>>>>delayed "+ delay + " vs " + milliseconds);
                  if(cntr++ % 30 == 0)  {   // only show some
//                     System.out.println("cntr="+cntr + " " +java.util.Arrays.toString(delays));
                  }
                     // cntr=51 [0, 0, 0, 51, 0, 0, 0, 0, 0, 0, 0]      ???? only 3 ????
                     // cntr=271 [0, 0, 0, 163, 35, 21, 19, 13, 6, 2, 12]
                     // cntr=61 [38856, 28784, 5379, 49, 1, 3, 2, 1, 0, 0, 5]
                     // cntr=181 [84624, 58662, 9812, 154, 7, 2, 1, 1, 2, 4, 10]
                     // cntr=331 [171433, 104896, 15056, 310, 0, 1, 0, 1, 0, 3, 16]
                     // cntr=15601 [184753, 112444, 16948, 1147, 875, 648, 598, 516, 526, 466, 518, 460, 463, 467, 483, 465, 511, 446, 516, 495, 6001]
              }
           }
           lastCall = currTime;      // save for delay comps

           moveIt();   
                                      
           // schedule next move
           doSchedule(this, milliseconds);          // see if synch keeps from losing balls from queue??? DID NOT Help
//           executor.schedule((Callable<String>)this, milliseconds, TimeUnit.MILLISECONDS);
//           System.out.println("thread="+Thread.currentThread());      // thread=Thread[pool-1-thread-1,5,main]
           return "";           //????
        }
 
        //-------------------------------------------------
        @Override
        public void run() {
//            System.out.println("run thread="+Thread.currentThread());  
            // run thread=Thread[Thread-2,6,main] 
            // run thread=Thread[Thread-1,6,main]
            // ...
            // run thread=Thread[Thread-100,6,main]

            // Change state in a loop.
            for ( ; ; ) {
                // Again, Thread.sleep() is probably not the best approach but,
                // since we decided to go that way, it does actually work.
                try {
                    Thread.sleep(milliseconds);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                    return;
                }
                moveIt();
            }
        }

        private void moveIt() {
                // change the ball's state
                int xOld = x, yOld = y;
                x += dx;
                y += dy;
                bounce();
                moved = true;                 // remember for paint's message

                if ( blink ) visible = !visible;

                // note: The zero-argument repaint() could replace next two lines.
                parent.repaint(x-radius, y-radius, 2*radius, 2*radius);         
                parent.repaint(xOld-radius, yOld-radius, 2*radius, 2*radius);

//                System.out.println("thread="+Thread.currentThread());      
                // thread=Thread[pool-1-thread-1,5,main]       <<<<<<<<< scheduled via executor
                // thread=Thread[AWT-EventQueue-0,6,main]      //???? why 2 different type names????   startup thread
                // thread=Thread[Thread-1,6,main]

                movedCnt++;
       }  // end moveIt()
       
       int lastChecked;  // move count when last checked

       //  Have we moved since the last time we were called?
       public boolean checkMoved() {
         boolean moved = movedCnt > lastChecked;
         lastChecked = movedCnt;
         return moved;
       }
 
        private void bounce() {
            // note: One could argue that parent.getWidth() and getHeight()
            // are not thread-safe. That's something worth pondering.
            int parentWidth = parent.getWidth();
            if (x > parentWidth) { x = 2*parentWidth - x; dx = -dx; }
            else if (x < 0) { x = -x; dx = -dx; }      // radius vs 0   <<<<<<<<<< causes double bounce???
            int parentHeight = parent.getHeight();
            if (y < 0) { y = -y; dy = -dy; }           // saa
            else if (y > parentHeight) { y = 2*parentHeight - y; dy = -dy; }
        }
    } // end static class BallWithOwnThread
 
}

[Norm Radder]

Also posted at: https://www.java-forums.org/threads-synchronization/97319-scheduledthreadpoolexecutor-losing-tasks.html#post419193

[Campbell Ritchie]

Norm Radder wrote:Also posted at: . . .

People on both websites need to know about multiple postings, so they don't simply repeat what has already been said elsewhere.

[Norm Radder]

The problem with losing balls was solved here:
https://www.java-forums.org/threads-synchronization/97319-scheduledthreadpoolexecutor-losing-tasks.html#post419217

[Christopher Dodunski]

Thank you, Brian, for making the effort to produce some demo code.  I've studied and scrutinised it very closely, and am hugely grateful for what I've learned from that.

I've pushed on with my project, and it is now at the stage where I can present it to my employer as a working proof-of-concept.

In the next day or two I will place a link to an MP4 demo of the code in action - it works beautifully!

Again, thank you all for the sharing of ideas.  What a great environment for intermediate programmers like myself to grow their skills.