Using thread pools with SwingWorker?

[TacoManStan]

Hey all,
I am attempting to use multi-threading with Swing, and I am running into some problems. For one, I learned that you have to do everything on the EDT when working with Swing, and that using any other threads could lock up the UI.

However, I also started looking into SwingWorkers. I might be misunderstanding this, but it seems that the SwingWorker will start a thread, add it to its own thread pool, and and execute anything that it needs to dealing with the UI on the EDT.

I have 2 threads; one is designed to perform static animation by updating the BufferedImage that designates that particular object. The other performs dynamic animation, which simply changes the position of the image and then re-paints it at the new location. There is actually a third that controls stats, but that doesn't really have anything to do with the UI. Each thread is added to it's own thread pool, so that all processing power won't be focused on any one of the three types of threads.

So here is my question. Would it be possible to create three different thread pools that the SwingWorker can use? I know there is a way to increase the amount of threads that can be in the "active queue" or whatever, but is it possible to run the SwingWorkers as thread pools?

Sorry if I don't really understand how this stuff works, I am new to Java, very new to multi-threading, and very very new to multi-threading in Swing.

Thanks.

[DarrylBurke]

I learned that you have to do everything on the EDT when working with Swing, and that using any other threads could lock up the UI.

Just the opposite. Doing non-GUI stuff on the EDT is liable to make the UI unresponsive.

Calling Swing methods/constructors on a Thread other than the EDT is not safe and can lead to intermittent, hard-to-debug glitches.

the SwingWorker will start a thread, add it to its own thread pool, and and execute anything that it needs to dealing with the UI on the EDT.

Please go through the documentation for the class, where it is clearly identified which methods run in a background thread and which on the EDT.

Would it be possible to create three different thread pools that the SwingWorker can use?

There's no need to do that. Barring a short period (~6u17 to ~6u21) when SwingWorker was messed up, the core API manages a pool of several (10, I think) threads for SwingWorkers to use.

Sorry if I don't really understand how this stuff works, I am new to Java, very new to multi-threading, and very very new to multi-threading in Swing.

I would suggest you go ahead with one or more SwingWorkers as required and don't mess with trying to coerce them into your own thread pools. If you have a performance problem, distill it to a SSCCE and post it here for review.

luck, db