Concurrency in Swing, Multi-processor system
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 operationwithin 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!
# 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.
# 2
Thanks for the reply - I will definitely look into a good profiler as we analyze what's causing the greatest bottleneck.
Here's the specific situation that's tripping me up: I have two swing windows, A and B. A loads quickly. B has a HORRENDOUS number of Swing widgets and takes awhile to load (B may also have custom drawing, but the double-buffering-via-thread solution may mitigate performance problems associated with this).
The question is, while B loads all its Swing widgets, we need A to still be responsive and not bogged down. The concern is that A and B are, necessarily, governed by the event dispatch thread. What exactly should one thread here, to keep the UI as responsive as possible?
# 3
This depends on where the cost is in generating your widgets. If the cost is number-crunching or waiting on resources then you can - and, if granularity isn't prohibitive and batching isn't possible - should farm those activities off onto other threads.
If the cost is simple UI object creation then this still needs to be done on the EDT.
The point I would raise is that the statement "B has a HORRENDOUS number of Swing widgets" suggests to me that you almost certainly have some UI design issues. If there's that much stuff then the user can't be expected to comprehend the UI anyway. At the very least, you can't be displaying it all on screen, so there may well be scope for delaying instantiation of many of the objects until required.
