aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Thread Issues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Thread Issues" Watch "Thread Issues" New topic

Thread Issues

Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I have a custom JInternalFrame that displays a TIFF using JAI to get a BufferedImage and displaying it using ImageIcon, a JLabel, and a JScrollPane. I'm using a JSlider to control the scaling and using getScaledInstance() to do the zooming. This works fine, my problem is I'm not entirely happy with the performance and I'm wondering if there's an easy way to speed it up. I'd like to pass the stuff that takes a while to execute to a new thread and let it run there so the GUI remains responsive. My problem is I'm not entirely sure how to do this effectively AND safely.
icon.setImage(), label.invalidate(), pane.invalidate(), and repaint() are my main concerns. Which, if any, can be safely run from a thread other than the event-dispatching thread? I want to GUI to remain responsive, I don't care if it takes a short bit for the image to actually change just so long as it isn't holding up the GUI. I tried passing the whole thing off to a thread but I don't think that's thread safe and if I do the icon.setImage() and the rest in the event-dispatching thread it's slow.
Jason Dobies

Joined: Aug 13, 2003
Posts: 20
I'm pretty sure the answer to that is none. You might be able to buffer the image in a separate thread, but as far as repainting or changing the controls, you'll get weird (for lack of a better word) results appearing in the GUI.

JCP, JCD, WCD... and all around nice guy.
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24187

The methods invalidate() and repaint() can definitely be called from any thread, but they are not compute-intensive (repaint() merely queues a request for painting later.) setImage may indeed be expensive, but I suspect that actually it's the image scaling computation that's costly (you just do this once, right -- you don't scale the image in a paint() method).
Anyway, what you want to do is to do the scaling in a separate thread, and then have that thread use SwingUtilities.invokeLater() or invokeAndWait() to schedule the setImage() call on the Swing thread. To use these methods, you put the bit you want called on the event thread into the run() method of a Runnable, then pass the Runnable as an argument.
If you need more details let me know.

[Jess in Action][AskingGoodQuestions]
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I know how to do that Ernest, but thank you. I'm doing the scaling once, and it's all done using getScaledInstance of the image I originally loaded which remains in memory. I tried scaling the image in a separate thread and then calling setImage(), invalidate(), validate(), and repaint() only in the event-dispatching thread but that didn't seem to have any noticeable improvement.

[ August 15, 2003: Message edited by: Ken Blair ]
I agree. Here's the link:
subject: Thread Issues