Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28454

Re: threadpool and ui paint

Show all headers | View raw

On 5/13/2014 3:35 AM, Philipp Kraus wrote:
> Hello,
>
> I have a lot of objects, which are calculated within a thread pool (by a
> queue structure), so each object
> as got an individual paint method for visualization. At the moment I try
> to paint the objects within the threads
> of the pool, but this creates exceptions.

     Yeah.  Nearly everything that's done to or with a UI component must
take place on the Event Dispatching Thread, or EDT.  If you manipulate
UI components from other threads, bad things are likely to happen.  See
http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html
for an explanation and examples.

> Which is the correct way to do an UI painting? Each object needs an
> individual paint structure, but all objects
> can be painted after the thread has calculated the objects. In pseudo
> code my structure shows:
>
> class worker {
>     void run()
>     {
>
>      while (threadruns)
>      {
>           for all x = get object from queue
>           {
>              calculate x
>              push x back to the finish queue
>              - paint x -
>           }
>           - or here paint x -
>
>           thread await
>
>           for all y = ….
>      }
>
> }
>
> I'm a little bit confused with the Swing InvoceLater structure and in
> which way I can imlemented this in my pool

     Your outline is all right, so long as you make sure "paint x"
happens on the EDT.  That's what SwingUtilities.invokeLater() does:
You construct a Runnable that does the painting or whatever else is
desired, and you give that Runnable to invokeLater().  You can do
this on any thread you like, but when the Runnable actually runs it
will be on the EDT.  So, "paint x" looks something like

	final Thing x = ...;
	SwingUtilities.invokeLater(new Runnable() {
	    @Override
	    public void run() {
	        x.updateTheDisplay();
	    }
	});

     If you want to wait until all the calculating is finished
before updating the display, it might go like

	final Collection<Thing> finished = ...;
	SwingUtilities.invokeLater(new Runnable() {
	    @Override
	    public void run() {
	        for (Thing x : finished) {
	            x.updateTheDisplay();
	        }
	    }
	});

(By the way, Java 8 introduces a more compact notation for this sort
of thing -- but that's another story, and the old way still works.)

     Finally, you'll do yourself a favor if you divide the Thing into
two pieces: A "model" that owns the data and is responsible for the
computations that modify it, and a "view" that listens for notices
that the model has changed.  This may seem at first to be a rather
pointless division of labor, but trust me: It pays off.  See
http://docs.oracle.com/javase/tutorial/uiswing/components/model.html
for an explanation of this separation.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

threadpool and ui paint Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-05-13 09:35 +0200
  Re: threadpool and ui paint Joerg Meier <joergmmeier@arcor.de> - 2014-05-13 11:26 +0200
    Re: threadpool and ui paint markspace <markspace@nospam.nospam> - 2014-05-13 09:35 -0700
  Re: threadpool and ui paint Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-13 08:10 -0400
    Re: threadpool and ui paint markspace <markspace@nospam.nospam> - 2014-05-13 09:45 -0700
      Re: threadpool and ui paint Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-13 13:22 -0400
        Re: threadpool and ui paint markspace <markspace@nospam.nospam> - 2014-05-13 10:46 -0700

csiph-web