A question on parallel

[Jose]

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. 
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?
>>
>>
>
>