I'm working on a realtime WebGL Mandelbrot zoomer so the CPU / GPU time budget per frame is tight. It uses perturbation with the reference point calculated like this:

1. Find the next lowest period in the view using Robert Munafo's Jordan curve based algorithm.

2. Look for a minibrot with the period from the previous step using Newton-Raphson and an epsilon of one pixel.

3. If Newton-Raphson failed to converge at all, go to step 1.

4. If a minibrot was found inside the view, we're done.

5. If 3 minibrots outside the view have already been found, use the closest one as reference. Otherwise go to step 1.

This seems to converge near a minibrot pretty reliably, but with one pixel epsilon may be still be outside the set.

The full reference orbit is calculated in chunks sent to the GPU, which keeps the last low precision orbit coordinates for every pixel from the previous chunk of iterations.

However only after iterating past period length I can detect that the reference orbit actually escapes, epsilon needs to be smaller and the precision increased. Then the reference orbit needs to be re-calculated, which takes too long, and the pixels rendered on GPU so far are thrown away.

Sometimes this happens several times before epsilon is small enough for the particular minibrot - it may need to be smaller by a factor of 2^32 or even more.

I can see two possible solutions:

1. Can I use some size estimation algorithm like this...

https://code.mathr.co.uk/mandelbrot-numerics/blob_plain/HEAD:/c/lib/m_d_size.c...even if the "nucleus" is actually outside the set due to insufficient precision?

Knowing the size would help choose a sufficiently small epsilon, and that algorithm only needs to iterate for one period.

2. Can I "rebase" the previous low precision orbit coordinates (without knowing their full history) on the GPU to a new, more precise reference orbit?

All the GPU could see is some previous coordinates from the old and new reference orbits in single precision, and the latest perturbed coordinates using the old reference.

The epsilon is divided by 65536 and precision increased by 16 bits at a time, so the reference orbit itself could probably be perturbed on the CPU using only double precision.

The CPU sees the full history of both reference orbits and could also calculate a moderate number of parameters for some arbitrary function (series approximation?) to send to the GPU for application to every pixel there.

In case you're wondering, this is aimed for zooming up to 2^128. Really deep zooms are obviously never going to be real-time.