Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: threadpool and ui paint
Date: Tue, 13 May 2014 08:10:40 -0400
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <lkt242$qea$1@dont-email.me>
References: <lkshvd$143g$1@ariadne.rz.tu-clausthal.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2014 12:10:43 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="27082"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1///5qpAf5DupACMGom1/fi"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
In-Reply-To: <lkshvd$143g$1@ariadne.rz.tu-clausthal.de>
Cancel-Lock: sha1:azSG3U20KhxjykNniuU9PIyRiNY=
Xref: csiph.com comp.lang.java.programmer:28454

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