Started? I have a fully working prototype!

And it's not just "parallelised" but it greatly improves the efficiency and 
utilisation of both the CPU (and cores) and the GPU(s).

> On 10 Nov. 2016, at 18:35, Tobias Bley <b...@jpro.io> wrote:
> 
> Do you have started any parallelization?
> 
> 
> 
>> Am 10.11.2016 um 01:02 schrieb Felix Bembrick <felix.bembr...@gmail.com>:
>> 
>> If you want to know how to parallelise the JavaFX pipeline (or how it's 
>> already been done with amazing results) then talk to me.
>> 
>> If, of course, this email gets moderated...
>> 
>>> On 10 Nov. 2016, at 10:57, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On 10 Nov. 2016, at 10:27, Jim Graham <james.gra...@oracle.com> wrote:
>>>> 
>>>> On 10/20/16 5:34 AM, Kevin Rushforth wrote:
>>>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single
>>>>>> instance) so it is single-threaded.
>>>>>> 
>>>>>> In MarlinFX I could prepare the multi-threading support by using 1
>>>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.
>>>>>> 
>>>>>> However it seems a complex task to enable parallelization in the javafx
>>>>>> pipeline but I could help there also...
>>>>>> 
>>>>> 
>>>>> Enabling parallel rasterization seems like a good follow-on task, but is 
>>>>> out of scope for the short term given the
>>>>> limited amount of time. Also, the only way that MarlinFX even has a 
>>>>> chance of getting approved for in JDK 9 is for the
>>>>> default OpenPisces path to be unaltered.
>>>> 
>>>> Also, such a parallelization of the javafx pipelines would be a fairly 
>>>> large task.
>>>> 
>>>> I would think an effort to parallelize a single shape rasterization would 
>>>> be much simpler in scope.  Still outside the current JDK 9 timeline, but 
>>>> definitely something that could help in future releases.  I believe that 
>>>> once we put the edges into the internal structures we could parallelize 
>>>> the rasterization of individual scanlines and maybe break a tall shape up 
>>>> into N horizontal bands for N threads.  Other thoughts would be a thread 
>>>> to generate the crossings and N threads to populate the alphas...?
>>>> 
>>>>         ...jim
> 

Reply via email to