pub fn render_parallel<A: Attractor + Send + Sync + 'static, T: ColorTransform>(
    renderer: &mut ParallelRenderer<A, T>,
    config: Config<A, T>,
    jobs_per_thread: usize
) -> FinalImage
Expand description

I recommend 16 for jobs_per_thread. If you get uneven images with low iteration counts, try 8.

At relatively low rations between iterations and pixels (<50), this isn’t much faster.

How it works

Because strange attractors are inherently chaotic, we can render multiply images and then add them together. Internally, this uses three textures, count for the number of visits to the pixel, steps for the velocity at the closest visitation, and the zbuf which can give information about which pixel is the closest. The zbuf also gives us the depth texture. When combining the rendered image, we have to combine all of these.

When rendering through render without resetting the Runtime, this is what naturally happens. When we use multiple threads however, we have to explicitly combine the runtimes consistently to what the render method implicitly does.