Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Thread Issues

 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Suggestions?
 
Jason Dobies
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic