A question on parallel

[Gregg Wonderly]

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

On 8/27/2013 6:49 AM, David Holmes wrote:
> On 27/08/2013 7:47 PM, Jose wrote:
>>
>> David,
>>
>> These are paint related operations, placed inside paintComponent(g){}.
>>
>> In each render cycle the program must determine which tiles are visible in
>> that cycle and the EDT must wait until all the tiles are
>> collected from caches or built and transformed and/or clipped to match the
>> current viewport.
>>
>> Determininig wich the visible tiles are outside the render cycle produces
>> artifacts and too much flickering in my case.
>> It also happens if the tiles are drawed as they arrive, not blocking the
>> EDT, with an ExecutorCompletionService.
>> So my present approach is to launch all painting related tasks form the EDT,
>> using working threads when posssible,
>> but blocking the EDT to sychronize everything.
>> To be precise I'm not blocking everywere, build tasks are too long, so they
>> finish adding a tile to the cache outside the render cycle.
>> Only cached tiles are incorporated into the render cycle.
>>
>> With the Executors framework all auxiliary tasks were performed by working
>> threads and the results collected in the EDT.
>> The only difference I see is that now, with streams, the EDT is not idlle,
>> but cooperates also as a working thread in the maintime.
> But may not be available to collect the results the way it was
> previously. I'd be very surprised if you can have both useful
> parallelism and a responsive EDT here.
>
> David
>
>> I feeel performace should be similar with both approaches.
>>
>>
>>
>>
>>
>> -----Mensaje original-----
>> De: David Holmes [mailto:david.holmes at oracle.com]
>> Enviado el: martes, 27 de agosto de 2013 6:01
>> Para: Jose
>> CC: 'Brian Goetz'; lambda-dev at openjdk.java.net
>> Asunto: Re: A question on parallel
>>
>> On 27/08/2013 1:51 AM, Jose wrote:
>>> Fair enough,
>>>
>>> if the EDT is going to be blocked anyway until the operation
>>> completes, it makes sense to use it in the meantime as a working thread.
>> Ummm you _don't_ want the EDT to block! Anyone who thinks they need to
>> launch a parallel operation from an event handler needs to fork it off to
>> another thread, just like any long-running or potentially blocking
>> operation.
>>
>> David
>>
>>> Thanks for the info
>>>
>>>
>>>
>>>
>>>
>>> -----Mensaje original-----
>>> De: Brian Goetz [mailto:brian.goetz at oracle.com] Enviado el: lunes, 26
>>> de agosto de 2013 17:36
>>> Para: Jose
>>> CC: lambda-dev at openjdk.java.net
>>> Asunto: Re: A question on parallel
>>>
>>> The streams framework has no awareness of "special" threads like EDT.
>>> EDT is the initiating thread, no different from any other thread.
>>>
>>> When you initiate a terminal stream operation (sequential or
>>> parallel), the initiating thread is blocked until the operation
>>> completes.  If the computation is parallel, the initiating thread may
>>> get coopted into being a worker thread.
>>>
>>> So:
>>>      - No special behavior for EDT
>>>      - The seq/par distinction is indistinguishable from the EDT's
>>> perspective, since both block until the operation is done.
>>>
>>> Even if the initiating thread didn't temporarily join the worker pool,
>>> the EDT would still be blocked.
>>>
>>> On 8/26/2013 11:20 AM, Jose wrote:
>>>>
>>>> When running a parallel pipeline form the EDT, which policy
>>>> determimine which tasks will run on the EDT?
>>>>
>>>> There is a way to make all the resulting tasks to run in working threads?
>>>>
>>>>
>>>
>