Concurrency in Swing, Multi-processor system

Question

I have two questions:
1. This is a classic situation where I am looking for a definitive answer on: I've read about the single-thread rule/EDT, SwingWorker, and the use of invokeLater()/invokeAndWait(). The system I am designing will have multiple Swing windows (JInternalFrames) that do fairly complex GUI work. No direct interaction is needed between the windows which greatly simplifies things. Some windows are horrendously complex, and I simply want to ensure that one slow window doesn't bog the rest of the UIs. I'm not entirely clear on what exactly I should be threading: the entire JInternalFrame itself should be runnable? The expensive operation within the JInternalFrame? A good example of this is a complex paint() method: in this case I've heard of spawning a thread to render to a back-buffer of sorts, then blitting the whole thing when ready. In short, what's the cleanest approach here to ensure that one rogue window doesn't block others? I apologize if this is something addressed over and over but most examples seem to point to the classic case of "the expensive DB operation" within a Swing app.
2. Short and sweet: any way to have Swing take advantage of multi-processor systems, say, a system with 6 processors available to it? If you have one Swing process that spawns 10 threads, that's still just one process and the OS probably wouldn't be smart enough to distribute the threads across processors, I'm guessing. Any input on this would be helpful. Thank you!

Answer 1

(1) You need to use a profiler. This is the first step in any sort of optimization. The profiler does two important things: First, it tells you where are the real bottlenecks (which is usually not what you expect), and eliminates any doubt as to a certain section of code being 'slow' or 'fast'. Second, the profilter lets you compare results before and after. That way, you can check that your code changes actually increased performance, and by exactly how much.
(2) Generally speaking, if there are 10 threads and 10 CPU's, then each thread runs concurrently on a different CPU.
As per (1), the suggestion to use double buffering is the likely best way to go. When you think about what it takes to draw an image, 90% of it can be done in a worker thread. The geometry, creating Shapes, drawing then onto a graphics object, transformations and filters, all that can be done offline. Only copying the buffered image onscreen is the 10% that needs to happen in the EDT thread. But again, use a profiler first.