Every deep zoom video you have seen has the same problem hiding inside it: computers run out of numbers long before the fractal runs out of detail. Here is what breaks, and the trick that fixes it.
Pick a point on the plane. Treat it as a number c and run this loop: start at zero, square, add c, repeat.
Two things can happen. The numbers can stay small forever — that point is in the Mandelbrot set, and we paint it black. Or they can run away to infinity — that point is out, and we colour it by how many steps it survived before escaping.
That is the whole definition. A loop with one multiplication and one addition. Everything else — the spirals, the seahorses, the tiny copies of the whole shape buried miles down — falls out of those two operations. Nobody designed the detail; it is a consequence.
To zoom in, you shrink the gap between neighbouring pixels. At 10× magnification adjacent pixels differ in the fourth decimal place. At 10¹⁵ they differ in the sixteenth.
And sixteen is roughly where a computer's standard number type gives up. A double — the number type behind almost all arithmetic you will ever encounter — carries about 15 to 17 significant decimal digits. Past that there is nothing left to store the difference in.
| Method | Digits | Usable zoom |
|---|---|---|
| GPU float32 | ~7 | 10⁵ |
| Emulated double on GPU | ~10 | 10⁶ |
| float64 (CPU) | ~16 | 10¹³ |
| Perturbation (this page) | as many as you like | 10²⁶ measured |
The obvious fix is to use bigger numbers everywhere — hundreds of digits per pixel. That works, and it is unbearably slow: a million pixels × thousands of iterations × arithmetic hundreds of times more expensive than the hardware's native speed. Minutes per frame, not milliseconds.
Here is the insight, and it is genuinely elegant. Neighbouring points behave almost identically. Two pixels a hair apart trace nearly the same path through the loop. So instead of computing every pixel from scratch at enormous precision, compute one point properly — and describe every other pixel as a small deviation from it.
Call the carefully computed point C, and its path Z₀, Z₁, Z₂… — the reference orbit. Any nearby pixel is c = C + δc, where δc is a tiny offset. Its path is z = Z + δ. Substitute into the loop and expand:
That last line is the whole method. It is a rule for updating the difference directly, without ever computing the pixel's own value at high precision.
And the payoff: δ is tiny, so it needs almost no digits — ordinary fast arithmetic holds it fine. Z has already been computed once, expensively, and gets reused by every pixel on screen. The expensive part is paid once per frame instead of once per pixel.
There is a catch, and it took the fractal community years to solve properly.
The method assumes the pixel stays close to the reference. Sometimes it does not: the reference orbit swings far from zero while the pixel's true value passes very near it. Now you are computing a small number as the difference between two large ones, and the precision you were relying on evaporates. These pixels come out as ugly flat blotches — glitches.
The first fix, from a poster known as Pauldelbrot, was to detect glitched pixels and re-render them against a second reference chosen from among them, repeating until clean. It works, but it means several passes and bookkeeping about which pixels belong to which reference.
The renderer here uses a later and much neater idea, usually credited to Zhuoran: rebasing. If the pixel's true value ever becomes smaller than its own offset, the reference has stopped being useful — so throw it away and start again, treating the current value as a fresh offset from step zero of the same orbit. No second reference, no extra passes, no glitches. A few lines of code where the old approach needed a subsystem.
The reference orbit is computed in a background thread using BigInt fixed-point arithmetic — integers scaled by a power of two, giving as many digits as the depth requires. Precision is set from the zoom level: roughly 3.3 bits per decimal digit, plus a safety margin. It runs off the main thread so the interface never freezes.
The finished orbit is uploaded to the graphics card as a texture — a long list of Z values. Every pixel then runs the δ recurrence in parallel, reading Z from that texture. This is what makes it interactive rather than a render job.
One more wrinkle. At extreme depth δc is around 10⁻³⁰, and float32 cannot even represent numbers that small. So everything is rescaled: distances are measured in pixels rather than in units of the complex plane, which puts δ comfortably near 1. The scale factor is folded back in only where the maths requires it.
Escape counts are integers, so colouring by them directly gives visible bands. The fix is the smooth iteration count, which turns the step number into a continuous value using how far past the escape threshold the point landed:
The renderer also tracks the derivative alongside the value, which gives an estimate of each pixel's distance to the boundary of the set. That is what the contour setting uses — it darkens near the edge and makes the filaments legible instead of aliased. It also means detail stays crisp at any magnification, because it measures geometry rather than counting steps.
This implementation holds up cleanly to about 10²⁶, starts losing detail by 10²⁸, and is flat by 10³⁰. I measured that rather than guessed it. The limit is not the reference orbit — that can go as deep as you like. It is that the orbit is stored as float32, carrying only about seven digits, and that error compounds through the 2·Z·δ term over thousands of iterations.
Going deeper means storing each offset as a mantissa plus its own separate exponent, instead of relying on the hardware's. Fractal software calls this floatexp, and with it people have reached 10¹⁰⁰⁰ and further. The other missing piece is series approximation, which skips thousands of early iterations by approximating them with a polynomial — a large speed win, and orthogonal to everything above.
Both are on the list. Neither changes the idea, only how far it reaches.
The perturbation approach came out of the fractalforums community rather than academia — largely amateurs, working it out in public over about a decade. K. I. Martin's 2013 note SuperFractalThing Maths is the origin; Pauldelbrot's glitch criterion and Zhuoran's rebasing came later on the same forums. Claude Heiland-Allen has written the clearest technical accounts of the modern versions.