Fwd: Re: Marlin-Renderer and JavaFX

[Jim Graham]

Another thought on multi-threaded scan-line rasterization would be to pre-scan the node tree and pre-rasterize all 
shapes into masks before we run through and render them to the destination.  Again, that would be outside the scope of 
9, but it would be a change only to the rendering process (and dealing with the caching of alpha masks) that would 
leverage your ability to create multiple Marlin contexts without any changes to MarlinFX...

			...jim

On 11/10/16 5:13 AM, Laurent Bourgès wrote:
> Jim,
>
>
>     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...?
>
>
> Multithreaded rendering is a complex task that should be discussed in another thread as it is totally out of my current
> scope.
>
> My 2 cents: there is two approach:
> - render shapes in parallel (but it requires the JavaFX pipeline to be parallelized = tricky as caching mask, gpu need
> single thread communication ...)
> - render shape with several threads (as you proposed) but the scanline algorithm requires the previous scanline
> information like previous edges (so it becomes tricky to make it efficient) and this will only speed up large shapes
> (point clouds will remain slow !)
>
> Anyway the major issue concerns latency ie how to spread the workload on several threads when the scene contains shapes
> with various sizes or complexity (edge count): the latency corresponds to the slowest thread to complete its rendering task.
> => adaptive algorithm to make a sort of load balancing (work stealing approach) or small tasks (average same cpu cost).
>
> PS: I have some experience on parallelization, but please let's postpone this discussion or let's do it in another thread.
>
> Laurent