A question on parallel

[Jose]

Hi Gregg

The render cycle starts in a paintComponent(). If I go out from the EDT and
wait until the whole picture is created, I need to present someting else to
paintComponent() instead. So I guess you are talking about using double
buffering or something like that.

I tried this approach sometime ago and didn't notice a difference. Maybe
this is because the program is not a video game, but a map visualizer, 
and the view only changes after user input. 

But maybe I will give this approach a second try, as many things has changed
since then.







-----Mensaje original-----
De: Gregg Wonderly [mailto:gregg at wonderly.org] 
Enviado el: martes, 27 de agosto de 2013 15:14
Para: David Holmes
CC: Jose; lambda-dev at openjdk.java.net
Asunto: Re: A question on parallel

The classic animation technique here, is to use background thread(s) to
generate new tiles, as fast as possible given the computers resources.
Then, when you have a complete view, lock the background thread around a
"repaint()" which allows the EDT to grab the current, complete view, and
render it.

Then, the background thread, can continue rendering the next view.  When you
see video games and other dynamic, animated views done this way, you see
that frames per second comes into play. Based on the complexity of the
details against the computer's resources, only a certain number of frames
can be generated each 
second.   However, the user is always looking at a timely display of what is

happening at the real-time moment that the "repaint()" occurs.

This allows the EDT to be as "free" to respond the users keyboard, mouse
etc. 
events as possible as well.

The EDT should only ever be used to paint resources to the display, or
respond to UI events.  It should never be used to "compose" the view.

Gregg Wonderly