• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Thread Issues

 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic