Mandelbrot explorer · qwen3.8-flash

Let me start by looking at the working directory.

I'll build a single-page Mandelbrot explorer with Canvas 2D, progressive rendering with chunks/requestAnimationFrame to keep controls responsive, dynamic iteration count based on zoom depth, smooth coloring (normalized escape time) with a procedural palette, interior points in a distinct color.

Key features:
- Full-screen canvas, devicePixelRatio handling.
- Complex coordinate mapping. Initial view: full set visible, e.g. center (-0.5, 0), width 3.5 in real axis.
- Drag to pan. Wheel zoom centered on cursor point.
- Reset view button (plus keyboard R).
- Iteration scaling: maxIter = base + k * log2(zoom). Show HUD with iter count, coords, zoom.
- Progressive rendering: render in tile bands across frames using requestAnimationFrame, with time budget per frame (~12ms). Also render at lower resolution first (preview pass) then refine — nice approach: render coarse pass quickly then progressive refinement passes. Let's implement: on invalidate, do a "coarse" pass at scale 1/4 quickly (blocky), then refine to full res in chunks. Simpler robust approach: render passes with decreasing pixel size: step = 8, 4, 2, 1. Each pass computed in horizontal bands within a frame time budget.

Use escape-time with smooth iteration count: n + 1 - log(log|z|)/log(2). Palette: procedural sinusoidal or interpolation between HSL colors. Use a color LUT of 512 entries built from smooth cycling palette; map smooth iteration with log scaling for good detail at high zoom.

Also double-click to zoom in, shift+double click or right-click zoom out. Add a zoom +/- buttons maybe. Also touch support optional (pointer events). Keep it modest but polished.

Also prevent page scroll on wheel: canvas fills viewport, body overflow hidden, and e.preventDefault() with passive:false.

Cancellation: when re-navigating during render, cancel current progressive render and restart.

Performance: full-screen at DPR could be heavy. Cap DPR to 1.5 or render in device pixels but limit to e.g. width*height <= ~2.6M px. Let's compute rendering scale so that total pixels manageable: scale = min(dpr, 2) but if canvas area > 2.5M, downscale. Then use ImageData and putImageData, then CSS scale up. Simpler: render buffer canvas at reduced resolution and drawImage to display canvas scaled (imageSmoothing on). Actually with step-passes we draw directly to main ImageData at full backing resolution but the first passes fill blocks.

Let me implement:

- displayCanvas sized to window inner * renderScale (renderScale = clamp based on area). CSS width/height 100%.
- Single ImageData of canvas size; passes at step sizes 8,4,2,1 writing into ImageData, then putImageData after each band group. Actually put whole ImageData at end of each frame chunk (cheap-ish for 2M pixels? putImageData each frame ~ few ms). Alternative: putImageData only for updated region: ctx.putImageData(imgData, 0, bandStartY, 0, bandStartY, w, bandHeight) — dirty rect version. Good.

Escape time algorithm with periodicity checking + cardioid/bulb shortcut for speed. Let's add: check if c inside main cardioid or period-2 bulb → inside, no iteration. Good speed boost for the initial view.

Palette design: interior distinct color e.g. near-black deep (#05070f) with subtle? "distinct color for points treated as inside the set" — solid color distinct from gradient, e.g. black-ish (#04060c) while exterior gradient bright. Hmm typically interior is black. Let's do exterior luminous palette on dark and interior solid #050505... For a nicer look: interior solid deep indigo #0a0a1a, exterior palette from teal/gold/magenta cycles.

Color mapping: t = sqrt(smooth) or log; index = (log2(smooth+1) * 8 ) ... Use: v = Math.pow(smooth / maxIterSmoothRef, 0.4)? Better: use cyclic based on log scale so detail remains visible at all zooms: idx = (Math.log2(escapeIter+1) * 40) mod 512? Common approach: color = palette[(smoothIter * colorScale) mod LUT]. I'll use a hybrid: base = smoothIter; use log-scaled: s = Math.log(1 + smoothIter) * 12, cycling. Plus a "shading" using fractional part for fine structure. Let me keep it simple but pretty:

hue cycling with palette LUT of 720 entries:
c = (t*0.15) mod 1 where t = smooth iterations. Use cosine palette: rgb = a + b*cos(2π*(c*freq + phase)). Standard IQY palette: a=(0.5,0.5,0.5), b=(0.5,0.5,0.5), c=(1,1,1), d=(0.0,0.33,0.67) gives rainbow. With c cycling rate controlled.

I'll precompute LUT: for i in 0..LUT-1: u=i/LUT; color = cosine palette with u*1 (one full cycle). Then map smooth iter: u = (0.5 + 0.5*Math.log2(1+ (iter % ...)))... Let's do: u = (Math.log(1 + iter) / Math.log(1 + maxIter)) ... that gives a non-cycling gradient scaled to maxIter: nice since it always spans full range and reveals detail at high zoom, but adjacent bands compress at high zoom. Add brightness modulation from fractional part for smooth banding.

Better classic: smooth coloring looks great when the palette cycles with escape count: u = frac(iter * 0.02 + something)? For deep zoom, iter counts large so cycling reveals fine structure and creates "onion" rings around boundary — pretty. Let's combine: u = frac( 0.10 * log2(1 + iter) )? At iter up to 3000, log2 ~ 11.6, times ... hmm.

Design decision: I'll compute:
si = smooth iter (>=1, <= maxIter).
band = Math.log2(si + 1) / Math.log2(maxIter + 1) → in [0,1], monotonically spanning whole palette regardless of zoom. Then add a cyclic detail term: u = frac(band*1.0 * ? ) Actually to reveal fine detail near boundary, cycling is important. Let me use two-term: u = frac(band * 3.0 + 0.02 * si)?? mixing linear might alias.

Practical approach used by many: u = frac(0.02 * si) at low zoom; at high zoom, iteration counts vary hugely so cycling with si produces many color cycles — high contrast texture. Combine with brightness from continuous si.

I'll do: 
lum = 0.30 + 0.70 * (si / maxIter)^0.35  (or band-based)
hueU = frac(0.018 * si)
color = palette(hueU) * lum. Interior = fixed color.

That yields bands of cycling colors modulated by brightness — looks good and shows detail. Let me also add a slight shift with log to avoid uniform band width at deep zooms: hueU = frac(0.018*si) fine.

Actually careful: at deep zoom maxIter grows, si ~ maxIter for most near-boundary points; brightness term (si/maxIter) makes everything bright... The interior-ish points reach maxIter → dark? Let's define: points that escape with si small = bright? Let's just do: color from cycling palette where the "cycle index" uses log: u = frac(Math.log2(si) * 0.35) maybe. Hmm.

I'll do a well-tested approach:
t = si / maxIter in [0,1] for escaping; near-boundary t → 1.
value = 0.5 + 0.5*cos(2π*(3*t))? Not standard.

Let me just use the cosine-palette with an argument that mixes: 
a = 0.5*si^0.4? 

OK simplest attractive: 
u = Math.pow(si / maxIter, 0.55); // 0..1
color = palette(u) where palette is multi-cycle cosine rainbow (freq 2 cycles across the LUT).
Then brightness modulated by fractional part to give onion rings: shade = 0.75 + 0.25*Math.sin(si*0.35). Hmm, sin(si*0.35) creates fine stripes near boundary which is a hallmark nice look.

I'll go: 
u = si / maxIter (0..1), cycled: uc = frac(u * 6) → 6 color cycles from fast-escape to slow-escape, plus brightness from log: b = 0.35 + 0.65 * Math.log(1+si)/Math.log(1+maxIter). Multiply. At deep zoom, si near boundary large, log ratio compresses; fine structure appears in uc since u changes rapidly across pixels near boundary. That's decent and adaptive.

Honestly, visual quality is my choice; I'll implement something reasonable and check in the browser via screenshots, then tune.

Controls UI: top-left panel with Reset view button, iteration display, auto-iteration toggle, quality selector maybe, zoom level, coordinates, and a hint. Keep responsive: rendering chunks in rAF; UI in DOM; also use a Web Worker? No external files allowed but inline worker via Blob is possible... Blob worker might be blocked in sandbox? data/blob URLs may be restricted. Avoid; use chunked main-thread rendering with time budget, which keeps controls responsive. Also add per-band putImageData so panning shows progressive updates.

Responsive during rendering: use `requestAnimationFrame` loop with ~10ms budget, so pointer events still process between frames. Good.

Also: during drag, instead of re-rendering every frame fully, we could re-render at low res (step 4 preview) for responsiveness — implemented automatically since drag invalidates and passes restart at step 8/4 quickly. Let's use a "fastMode" during interaction: only coarse pass (step 4) while dragging, then full quality on pointerup. That keeps it smooth.

Let me write the code.

Implementation details:

```js
const view = {cx: -0.7, cy: 0, scale: 3.2}; // scale = width of view in complex plane (real units)
```
Initial bounds must show full main cardioid + surrounding lobes: real range about [-2, 0.7] (width 2.7), imaginary [-1.3, 1.3]. With aspect ratio, compute so that entire set fits: choose scale so both fit: required width 2.9+margin, height 2.4+margin. Compute: if canvas w/h aspect > required, fit by height else width. Let's implement resetView():
const pad = 1.08;
const wantW = 2.95*pad? Actually real extent needed: -2.05..1.05 → 3.1 ; imag: -1.3..1.3 → 2.6 (with pad).
cx = -0.5, cy = 0.
pxPerUnit = min(canvasW/(3.2*pad), canvasH/(2.7*pad))... then compute view as halfWidth/halfHeight in complex units: halfH = canvasH/2/pxPerUnit, etc. Store view as {cx, cy, ppu} (pixels per complex unit) — simplest for zoom math.

Mapping: complexX = cx + (px - W/2)/ppu ; complexY = cy - (py - H/2)/ppu (y flipped so up is +imag). Using render buffer pixels (buffer scale). I'll map with css pixels: use factor = dprScale since ppu defined in buffer pixels... I'll define ppu in buffer pixels and convert pointer coords from CSS px to buffer px by multiply by bufferScale (=canvas.width / clientWidth).

Zoom: wheel → newPpu = ppu * exp(-deltaY * k) or factor = deltaY<0 ? 1.15 : 1/1.15. Keep complex point under cursor fixed: cx += (bx - W/2)/ppuOld - (bx - W/2)/ppuNew... precisely: u = cx + (bx - W/2)/ppu; after change, set cx = u - (bx - W/2)/ppuNew. Same for v with sign.

maxIter auto: base 250 + 60*log2(ppu/ppuInitial)? Common: maxIter = clamp(100 + 90*Math.log2(ppu/ppu0), 100, 6000)? At ppu/ppu0 = 1 → 100... For full view 250 is good. Let's use: zoomLevel = ppu/ppu0; maxIter = Math.round(200 + 120*Math.log2(Math.max(1,zoomLevel)) *  ... ) e.g. at zoom 1000 (log2≈10) → 200+120*10=1400. at zoom 1e6 (log2=20) → 2600. Maybe scale more aggressively: 250 + 250*log2 → at 1000x = 2750, at 1e6x = 5250 (heavy). Let's do 200 + 150*log2 and cap at 5000. Also allow user to add iterations via +/- buttons and lock auto.

Floating point precision limits around zoom 1e14 with doubles; fine. Could add perturbation but too much. Provide note.

Smooth iteration: bailout radius 1<<16 (65536) for accurate smoothing; use zs = |z|^2 and smooth = i + 1 - log2(log(|z|)/log(bailR))... Standard: mu = i + 1 - Math.log(Math.log(Math.abs(z)))/Math.log(2). With bailout 2 gives exact; with larger B: mu = i + 1 - log2(log(|z|)/log(B))? Common approach: mu = i - log2(log|z|) works for bailout radius 2^2^k... To be safe: use bailout R = 2^16 = 65536, escape check |z|^2 > R*R? Let's use B = 1e8 (|z|^2 > 1e16). Then mu = i + 1 - Math.log2(Math.log(Math.abs(z)) / Math.log(B))? Let's derive: normalized escape continuous function: G(c) = lim 2^i |z_i| → smooth = i + log2( log|z_i| / log(B) )?? Standard formula: 
mu = n + 1 - log(log|z|)/log(2), valid when bailout is large and |z| huge. The generalized: mu = n - log2(log(|z|)/log(B0)) ... hmm. For our purposes use B large (like 1e10 for z^2 escape → |z| > 1e5) and mu = n + 1 - log2(log(|z|)) + log2(log(B)) roughly? Let me use the well known: with bailout radius R, and continuous potential G = |z|^(1/2^n) ... define smooth = n + 1 - Math.log2(Math.log(Math.abs(z)) / Math.log(R)) — check: at |z| = R, smooth = n+1 (since log(log R/log R)=log(1)=0 → smooth=n+1). Hmm at the moment of escape |z| slightly > R, gives smooth ≈ n+1. Just below escape, |z| slightly less → log(|z|)/log(R) <1 → log negative → problem. Since we break only when |z|>R, |z| is >= R roughly (could be much larger after squaring, up to R^2 scale). So the ratio ranges [1, ~log(R^2)/log(R)=2] → log2 of that in [0,1] → smooth in [n, n+1]. 

With R = 65536 (R^2 = 4.3e9 > 2^31 but fine in doubles), |z| after escape can be up to ~R^2 = 4e9, ratio log up to log(4e9)/log(65536)=2 → fine, smooth ∈ [n, n+1] approximately. Good: use `mu = i + 1 - Math.log2(Math.log(Math.abs(z)) / Math.log(BAILOUT))` with BAILOUT = 65536 and escape check |z|^2 > BAILOUT^2.

Cardioid test:
main: q = (x-0.25)^2 + y^2; if q*(q + x - 0.25) < 0.5*y*y → inside.
period-2 bulb: (x+1)^2 + y^2 < 0.0625 → inside.

Bands/chunking: iterate rows per band of height e.g. 16 rows; within each frame process bands until time budget exceeded. Passes with step sizes.

Implementation of pass rendering: for step s, iterate py over rows in the buffer, px over cols. For each pixel compute color; fill s×s block in ImageData. Cache: for step>1 we still compute at reduced sample. Then putImageData dirty rect for full rows.

Simplify: implement render pass as full-image loop but with early exit per frame using time checks (check every N rows). Structure:

```
function startRender(){ cancel; passes = [8,4,2,1] (or [4,1] in fast mode); passIdx=0; row=0; }
function frame(t){ deadline = t + 14ms; while(passIdx < passes.length){ const s=passes[passIdx]; const end = ...; for(;row<H && performance.now()<deadline; row+= s){ renderRowBand(s,row); } putImage(s,rowDone); if(row>=H){passIdx++; row=0;} } }
```
Where renderRowBand computes the whole row (all cols) in one go; row+=s.

But putImageData per pass at end of the pass, after each frame chunk we should flush partially-updated rows so the user sees progress: keep track of dirty start/end rows in this frame, then putImageData with dirty rect after the loop and reset row pointer.

Careful with row index resetting across passes: since for-loop increments row and we return mid-row-loop, the partial rows are flushed by tracking flushFrom..row.

I'll structure:

```
let passes=[], pi=0, row=0, dirtyFrom=-1, dirtyTo=-1, ctx, img, data;
function tick(){
  const t0=performance.now();
  let done=false;
  while(!done){
    done = runPass(t0);
  }
  flush();
  if(!done) raf(tick); else onRenderComplete();
}
```
runPass: while row < H and performance.now()-t0 < budget: renderRow(pass, row); dirty record; row++. When row>=H: pi++, row=0; if pi>=passes.length → all done true.

Then flush: if dirtyFrom>=0 ctx.putImageData(img,0,0,W,H, 0,dirtyFrom,W,dirtyTo-dirtyFrom+1)... putImageData args (imgData, dx, dy, dirtyX, dirtyY, dirtyW, dirtyH). Use dx=0,dy=0 and full-width dirty rect.

renderRow for step s: y = row (which is multiple of s... ensure rows start at 0 and increment by s). For each col x multiple of s: compute; fill block via inner loop writing s rows and s cols. Writing block into ImageData indices.

Data length: buffer size. Let's set render scale: 
`const cssW = innerWidth, cssH = innerHeight; const dpr = Math.min(devicePixelRatio||1, 2); let scale = dpr; const maxPix = 2_400_000; if(cssW*cssH*scale*scale > maxPix) scale = Math.sqrt(maxPix/(cssW*cssH));` canvas.width = round(cssW*scale) etc.

Coordinate helpers: `pixelToComplex(bx,by)`, `complexToPixel`.

Zoom level display: ppu/ppu0 formatted (e.g. "×1.0e4").

Also show FPS/render time in HUD maybe. Add progress bar.

Extra features: 
- double-click zoom in ×2.5 at point; Shift+double-click or right-click (contextmenu prevented) zoom out.
- keyboard: R reset, +/- zoom, arrows pan, Esc? 
- "Auto iterations" checkbox + slider for min iterations? Keep panel minimal: Reset view, Zoom in/out buttons, Auto-iter toggle, iteration display, coords, zoom.
- Also render info: "computing..." progress.

Also nice: draw a HUD with coordinate crosshair? Skip.

Let's write the file, then run the browser tool to test: screenshot, check console, simulate wheel zoom at a point (e.g. 300,300) several times and check the point stays fixed by computing mapping in-page? Browser tool has 'key', 'type', 'click', 'drag', 'screenshot', 'inspect', 'motion', 'scroll'. There's scroll with delta — probably wheel at current position or given coords. Let me test zoom by evaluating... The tool doesn't include evaluate. I could add a debug hook: expose window.__mandel so I can inspect via... inspect returns DOM/console only. Hmm. To verify the anchor math, I could expose a test that logs to console — console messages are readable. Better: build in a self-test? Alternative: add data attributes updated in DOM: show under-cursor complex coordinate in HUD, and after zooming show it too; then via inspect read the HUD text and compare with pixel expectation.

Simplest verification: after each wheel zoom at fixed cursor location, the HUD shows "center" and cursor coords. I can compute manually? Let's just add a self-check that runs on load (in console): test anchor invariance by simulating zoom and asserting the complex point at the cursor maps to same pixel. Log result to console. But I need it to be genuinely exercised. I can write a small internal function `verifyAnchor()` invoked on wheel events that logs the pre/post complex coordinate at cursor. Let me instead log on wheel: console.debug with the complex point under cursor before and after. Then inspect console output.

I'll rely on: read the "cursor" readout from DOM before/after zoom via screenshot/inspect. That's a good check: HUD shows cursor complex coords, and a separate readout "anchor" showing the complex point under cursor before and after zoom (should match to ~6 decimals). Let's implement: on wheel, capture anchor = pixelToComplex(cursor) before, then after apply compute complexToPixel(anchor) and show the pixel delta in HUD: "anchor drift: 0.00 px". That's a solid verifiable metric and genuinely useful. Nice.

Let me write the code now.

Also handle window resize → re-render (keep center & ppu).

Touch: pointer events handle drag. Pinch zoom optional — could implement with 2 pointers. Let's add basic pinch via pointer events map. Keep it short but include since "dragging pans with the pointer" uses pointer events anyway.

Let me write.

Palette function (procedural):
```
function buildPalette(){
  const N = 1024; pal = new Uint8Array(N*3);
  for(let i=0;i<N;i++){
    const u = i/N;
    // cosine palettes layered
    const r = 0.5+0.5*Math.cos(6.28318*(1.0*u + 0.0));
    ...
  }
}
```
Use IQY-ish: r = a + b*cos(2π(c*u+d)) with a=(0.5,0.5,0.5) b=(0.5,0.5,0.5) c=(1,1,1) d=(0,0.33,0.67) → smooth rainbow. Then apply a slight gamma/tint. And add brightness modulation.

I'll precompute a table indexed by u in [0,1) → color, and separately multiply by luminance factor per-pixel computed from the "cycle" position? Multiplying per pixel requires 3 mults — cheap.

Per pixel:
```
if inside → interior color
else {
  mu = smooth;
  // normalized
  const t = Math.log2(Math.max(mu,1)) / Math.log2(maxIter); // hmm
```
Let's do: `u = mu / maxIter` then `cyc = u * CYCLES` with CYCLES ~ 5; index = floor(frac(cyc)*N) but to get multiple cycles with brightness variation across the set, luminance factor L = 0.45+0.55*sqrt(1 - ... ) hmm.

Let me define:
```
const f = Math.log(mu + 1) / Math.log(maxIter + 1);   // 0..1
const ring = mu - Math.floor(mu); // fraction gives fine texture? no, mu floor increments at boundaries; fractional part is smooth within escape order (fine)
u = (0.6*f + 0.4*(mu*0.05)) ...
```
Overcomplicating. Choose: u = frac(0.35*Math.log2(mu+1) + 0.0)? At mu from 1..maxIter: log2(mu+1) from 1..~12 → *? To cycle: 0.35*12 = 4.2 cycles — that's nice: about 4 cycles across the whole iteration range, independent of maxIter, and near the boundary (large mu) cycles compress in mu giving fine rings as you zoom. Then brightness: L = 0.35 + 0.65 * (1 - f)?? We want fast-escape (outside, far from set) to be dark-ish background and near-boundary bright? Common look: bright near set. Let's do L = 0.30+0.70*Math.pow(f, 0.6) where f = log(mu+1)/log(maxIter+1) so near boundary (mu→maxIter) L→1. Also add a subtle fine modulation: L *= (0.85 + 0.15*Math.cos(6.283*(frac(0.35*log2(mu+1)) * 3)))? Skip; keep clean.

I'll tune with screenshots.

Interior color: solid #0b0d14-ish? "distinct color" — I'll use a very dark blue-black, clearly distinct from the bright exterior gradient. Hmm but maybe exterior bright near boundary and dark far away makes interior dark blend in. Let's instead make exterior darker away from set... Then near-boundary exterior is bright and interior is dark → distinct enough. Also add slight: interior solid pure #07070c with the panel note.

Actually maybe give the interior a subtle procedural tint? The requirement just says "distinct color for points treated as inside the set" → solid.

Now writing.

For performance of the inner loop, write a tight function computing escape:
```
function iterate(cxv, cyv, maxIter){
  // shortcuts
  const y0=cyv, x0=cxv;
  ... periodicity check + cardioid
  let zx=0, zy=0, i=0, zx2=0, zy2=0;
  const B2 = BAILOUT*BAILOUT;
  while(i<maxIter){
    zx2 = zx*zx; zy2 = zy*zy;
    if(zx2+zy2 > B2) break;
    zy = 2*zx*zy + y0;
    zx = zx2 - zy2 + x0;
    i++;
  }
  if(i>=maxIter) return Infinity (inside)
  // smooth
  const r = Math.sqrt(zx2+zy2) // careful: zx2,zy2 are pre-update magnitudes at break time. At break, we computed zx2+zy2 for current z before updating; so |z| = sqrt(zx2+zy2). Good.
  mu = i + 1 - Math.log2(Math.log(r)/Math.log(BAILOUT));
  ...
```
Wait careful with indices: if break at i (having completed i iterations), then escape happened at iteration i... Let me structure loop: for(i=0;i<max;i++){ compute z_{i+1}? } Standard:
```
zx=zy=0; i=0;
while(i<maxIter){
  const zx2=zx*zx, zy2=zy*zy;
  if(zx2+zy2>B2) break;  // |z_i| > B
  zy = 2*zx*zy + cy; zx = zx2-zy2+cx; i++;
}
```
Hmm then after update i++ so i counts completed iterations, and break occurs at start when |z_i|>B → mu = i + 1 - log2(log|z_i|/log B)? Since escape "at iteration i" with |z_i|>B, continuous: mu = i - log2(log|z_i|/log2? Let me use the standard: mu = i + 1 - Math.log2(Math.log(r)) + ... Standard formula uses bailout 2 and |z| at escape: mu = n + 1 - log2(log2(|z|))... For B: mu = n - log2(log(|z|)/log(B)) where n is the index of |z_n| that exceeded B. With |z_n| = r slightly > B → mu ≈ n. Since r can be up to ~B^2, mu in [n-1, n]. That's continuous and fine. Let me use `mu = i - Math.log2(Math.log(r)/Math.log(B))`... check: r=B → mu = i - 0 = i. r = B^2 → log(B^2)/log(B) = 2 → log2(2)=1 → mu = i-1. And z_{i-1} had |z|>B... it's the standard-ish. Good, mu in [i-1, i]. Hmm, sign convention: escape-time smooth: nu = i + 1 - log2(log r) (for B=2, r>2). Whatever—continuity is what matters; my formula gives continuous mu across iteration boundaries since r at the break varies continuously with c. Yes continuous: as c moves, r jumps from B^2 to B as i increments by 1, and mu formula compensates. Good.

But mu could be < 1 → clamp min 1? For i=0: z_0 = 0, |z_0|=0 never > B, so break can't happen at i=0. Fine, min i=1.

Cardioid shortcuts: apply before iterating: 
```
const x=cx, y=cy;
const q=(x-0.25)**2 + y*y;
if(q*(q+x-0.25) < 0.5*y*y) → inside
if((x+1)**2+y*y < 0.0625) → inside
```

Periodicity checking helps speed for interior-ish points: track z, if repeats within maxIter → inside. Adds complexity; include simple version? I'll include it (cheap): store zx_old, zy_old every 20 iterations? Standard but tricky in the loop. Let me skip; cardioid/bulb shortcut + chunking is enough.

Max iterations cap: also add a "detail" slider? Provide auto iterations with slider for iteration multiplier? I'll include an iteration slider that sets base and auto scaling. Keep: checkbox "Auto iterations" + numeric display, and +/− iteration buttons. Simpler: slider 0..100 mapping? I'll do: checkbox auto + buttons "+ / −" for min iterations.

Let me now consider the fast preview during drag: On pointerdown, set interactive=true → passes = [8,4] only? Actually during drag, the whole image must be recomputed each frame; using step 4 (or 8) gives ~1/16–1/64 of the work → responsive. Then on pointerup, do refinement passes [4,2,1]. Implementation: on invalidate(mode): if mode 'fast' passes=[6,3] else passes=[8,4,2,1]. Then when rendering completes on fast, and user still dragging, next frame will re-run fast passes. On pointerup schedule full quality. Also if full quality triggered while fast in progress, restart at coarse.

To avoid losing detail from already-computed fine pass, simplest: restart passes each time.

Progress indicator: show small "rendering…" dot / progress percentage based on overall pass row progress. Also show last render time.

Let's write the HTML.

Also: prevent page scroll: `html,body{overflow:hidden;height:100%}` and wheel listener with {passive:false} + preventDefault. Also touch-action:none on canvas.

Color LUT: Float? Use Uint8ClampedArray of 2048*3 precomputed with cosine palette.

Let me write code:

```js
const LUTN = 2048;
const LUT = new Uint8Array(LUTN*3);
function buildLUT(){
  for(let i=0;i<LUTN;i++){
    const u=i/LUTN;
    const r = 0.5 + 0.5*Math.cos(2*Math.PI*(u*1.0 + 0.00));
    const g = 0.5 + 0.5*Math.cos(2*Math.PI*(u*1.0 + 0.33));
    const b = 0.5 + 0.5*Math.cos(2*Math.PI*(u*1.0 + 0.67));
    ...
  }
}
```
Then apply brightness per pixel at runtime: `LUT[i*3]*L`. But LUT stores base 0..255 colors; per-pixel multiply → need float ops. Store as Uint8 and multiply by L then clamp: `(r*L)|0` where r in 0..255 and L in 0..1. Fine.

Palette aesthetics: I want a "plasma" style. Use mix of two cosine palettes for richer colors. Let's define function palUV(u) using coefficients: a=[0.5,0.5,0.5], b=[0.5,0.5,0.5], c=[1,1,1], d=[0.0,0.10,0.20]. Then raise to gamma 1.2 for contrast, plus vignette? Keep simple; tune after screenshot.

Interior color: [10,12,24]? Let's use solid near-black with a hint of blue: (7,8,18).

Now write file.

HUD layout: fixed top-left glass panel; bottom-right legend showing mapping? Add "inside set" swatch to show distinct color. Nice touch: legend showing iteration→color gradient (drawn on a small canvas procedurally). Add a small gradient strip canvas in the panel — procedural, no external asset. Good, include: 180x10 canvas with palette strip and labels min/max iterations, plus interior swatch.

Time to write. Also self-check function run at load: verify anchor invariance numerically without rendering:
```
window.__selfTest = () => {...}
```
And also log to console on load: "Mandelbrot ready". Maybe run an automated anchor test at load and console.info the drift. Let's add `runSelfTest()` that: sets view, picks pixel (0.3W, 0.4H), computes p = toComplex, applies zoomAt(px,py, factor) twice (in and back out), and checks round-trip drift; logs to console.info. Then also on each wheel we display drift.

Now, the browser tool: drag(from x,y toX,toY), scroll(delta) presumably at last mouse pos or given x,y, screenshot, inspect. Let me write code first.

Let me be careful about the rendering loop's `putImageData` cost — for a 2.4MP buffer it's maybe 5-10ms per flush. With budget 14ms/frame plus flush, ~ fine at reduced flush frequency (once per frame). OK.

Write file now.

Empty directory (except .home). Let's write index.html.

There's a bug: in `pointermove`, I use `lastBuf` before it's declared with `let lastBuf = [0,0];` after the handler — `let` declarations are hoisted but in temporal dead zone until executed. Since the handler runs after the whole IIFE executes, `lastBuf` will be initialized by then. OK fine, but cleaner to move it up. Also `invalidate` is called at resize before `autoIterEl` const declaration → TDZ error! `resize()` is called at the bottom after HUD consts... Let's check order: `resize()` call is at the bottom after HUD consts and drawLegend. Good. But `resize` uses `invalidate` → `maxIterFor` → `autoIterEl` — defined by then. Also the wheel handler references `zoomAt` (function declaration, hoisted). Fine.

Another bug: in tick(), the flushRects logic with `dirtyFrom`/`segFrom` is messy. Let me review:

```
while (true){
  const step = passes[pi];
  if (dirtyFrom < 0) { dirtyFrom = row; }
  if (segFrom < 0) segFrom = row;
  while (row < H){ render...; row += step; if over deadline break; }
  flushRects.push([segFrom, Math.min(dirtyTo, H-1)]);
  if (row >= H){ pi++; row = 0; segFrom = -1; dirtyFrom = -1; if (pi >= passes.length) break; }
  else break;
}
```
Wait `dirtyTo` accumulates across segments and passes; I set dirtyTo = yEnd in the row loop. Then push [segFrom, min(dirtyTo, H-1)]. After the inner while breaks on deadline, dirtyTo is the last rendered row end. segFrom is start row of this frame for this pass. Then break out of the outer loop → flush. If pass finished (row>=H) and next pass begins with row=0, segFrom=-1→set to 0, then inner loop renders rows from 0. But dirtyTo was set from the previous pass's last row (e.g. H-1). Then push [segFrom=0, dirtyTo=H-1] → flushes whole image which is fine (all rows have content? previous rows 0.. were rendered in the earlier pass so yes valid). Actually there's a subtle issue: dirtyTo isn't reset when new pass segment begins, so the flush range may be larger than needed but always valid content. It's correct since putImageData flushes rows [a,b] from the img buffer — all those rows contain rendered data (from this or a previous pass). Fine.

Also `dirtyFrom` isn't used meaningfully; harmless.

One concern: putImageData with a dirty rect — signature `putImageData(imagedata, dx, dy, dirtyX, dirtyY, dirtyWidth, dirtyHeight)`. I pass (img, 0, 0, 0, a, W, b-a+1). Correct.

Note: at first frame, before anything rendered, if passes finished quickly, fine.

Potential perf concern: in renderRow, computing maxIter = maxIterFor() per row (calls Math.log2, checkbox read) — cheap-ish but per row it's fine.

Also colorOf uses `logMaxIter` computed at invalidate; good.

Another bug: `curEl.textContent` uses `Math.ceil(Math.log10(view.ppu/10)*1.2)` which could produce weird digits count; and for the initial view ppu ≈ maybe 400 → log10(40)=1.6*1.2=1.95 → ceil 2 → +3 = 5 digits in HUD. In pointermove digits = max(3, min(15, ceil(1.95)))= max(3,2)=3. OK.

Also `pointerleave` handler references `curEl` before const declaration? Handlers defined earlier but executed later. `curEl` is const in TDZ during IIFE execution but by the time events fire it's initialized. Fine.

Now let me run in the browser and check.

One more: `dragged` reset on pointerdown but never reset when starting a fresh wheel-zoom — click handler checks dragged. Fine.

Also `window.addEventListener('wheel', ...)` duplicate preventDefault — harmless.

Let's test.

The set renders correctly, initial framing shows the cardioid and lobes. Anchor drift self-test = 0. 

Issues:
1. The far-field background has a big smooth gradient (purple/teal) that looks washed out — because luminance ramps with f and the palette cycles slowly at low iteration counts. It's actually attractive but a bit flat/muddy. The "smooth escape" region is dominated by a large gradient. Could improve by making the cycling more prominent in the outer region. Let's tune: increase cycle rate for low mu so more rings appear away from the set, and reduce the brightness gradient dominance. Also the background is quite bright/washed; maybe make far-field darker.

2. "computing" status badge still showing and progress bar at ~90% — it was mid-render at the screenshot. Fine.

3. render time shows "—" — hmm, at pass 3/4 not finished yet.

4. Also the "cursor" readout shows -2.56+1.37i which is outside the visible? The cursor position (600,400)? Wait, cursor shows the last pointer position from the harness. Fine.

Let me improve the palette: make outer regions darker with more visible rings. Adjust:
- L = 0.18 + 0.82 * pow(f, 0.7)? Wait f is log(mu+1)/logMaxIter; far-field escapes quickly → mu small → f small → L small → dark. But the screenshot shows bright purple far-field. Because LUT has +18 lift and cos palette minimum ~0.1*237+18. Hmm L=0.34 min → colors at 34% brightness still fairly saturated purple. The washed look is because the whole far field is one smooth gradient of similar hue, low contrast.

Let's change: L = 0.06 + 0.94*pow(f,0.8) → far field nearly black, bright near boundary. And cyc rate: use `cyc = 0.9*log2(mu+1) + 3.0*f`? At mu=2: log2(3)=1.58*0.9=1.42 → frac .42; at mu=250: log2(251)=7.97*0.9=7.2. So about 7 cycles across the range plus 3 from f. Good — more rings.

Also add a fine texture term: `+ 0.06*mu`? At high mu (deep zoom) that gives many rings near boundary. Might alias at deep zoom. Let's keep moderate.

Let me also make the deep background have a subtle dark blue tone rather than pure black.

I'll tune and re-screenshot. Also check: legend gradient.

Another consideration: the interior color #0a0c18 vs far-field dark — need distinct. With L min 0.06, far field colors ≈ 0.06*237+18 ≈ 32 → dark grayish blue, similar to interior (10,12,24). Risky for "distinct". Better: keep interior distinctly different — maybe make interior a deep near-black #05050c and far field brighter? Hmm.

Alternative: give interior a clearly distinct color like dark magenta-ish? Many explorers use black interior. To be safe and distinct, I'll make interior a solid very dark color (#06070d) while ensuring far-field minimum luminance stays above ~0.28 so it's visibly brighter/different. So L = 0.28 + 0.72*pow(f,0.6). And boost ring contrast so the far field isn't a flat wash.

Actually the washed look mostly comes from low ring frequency in the far field. With more cycles (0.9*log2 term) the far field will show concentric bands → looks much more like a fractal explorer. Let's do that and keep L min ~0.3.

Let me test with the changes.

Also I want to check pan + reset, and zoom at a boundary point (e.g., Seahorse Valley at -0.743, 0.131). I'll use window.mandel API via... the browser tool has no evaluate action. Hmm. I can only click/drag/scroll/type/key. To zoom into a specific boundary point, I can position the cursor via a click? Actions: click at x,y (which for shift-click zooms out; plain click does nothing unless dragged). Clicking moves the pointer there presumably, then scroll at that position. Let me check whether scroll action takes x,y — yes it has x,y params.

Plan for verification:
1. Reload after palette tweak → screenshot.
2. Drag pan → screenshot; then click Reset view → screenshot compare with initial (compare center readout & pixel sampling? Just visual + HUD).
3. Wheel zoom at a boundary point (e.g. x=700,y=330 near the neck/seahorse valley) several times → screenshot, check HUD anchor drift = 0.0000 px and zoom/iter increase, and that detail appears.

Let me also verify the point stays near cursor: the anchor drift readout gives exactly that. Plus visually check the same feature is centered at the cursor location across screenshots.

Let me tune the palette now.

Also the interior color: make it distinctly dark: INSIDE = [8, 9, 18] is fine but with L min 0.30 the far field min channel = 18+0.3*237*something... LUT min value is 18 + cos*... where cos min ~0.1 → ~41; times L=0.3 → ~12. Hmm so far-field darkest ~12-40 per channel vs interior 10,12,24 — could blend. Let me make the interior a distinctly different color: e.g. deep ink blue-black #05060f vs exterior minimum brightness raised so it never goes that dark. Set L min to 0.34 and interior [6,7,14]. Actually the screenshot showed interior clearly distinguishable from far field. Keep interior [8,10,20] and L min 0.30.

Let me reload and screenshot.

Now there are concentric rings — more "fractal explorer" look. But the corners are quite saturated green/red rainbow; the palette cycling across the whole range makes the far field rainbow rings. It looks decent, though a bit garish. Let me reduce the ring frequency slightly in the far field and add a smoother overall hue ramp. Options: cyc = 0.6*log2(mu+1) + 2.6*f. Let me also darken the far field more so the set pops: L = 0.22 + 0.78*pow(f, 0.9).

Actually the current look is fine and clearly a "smooth escape-time color gradient". Let me slightly tone it down and darken far field, then move on to interaction testing (time budget matters).

Let me do one tweak: L = 0.24 + 0.76 * pow(f, 0.85), cyc = 0.75*log2(mu+1) + 3.0*f.

Now test interactions. First: drag pan. Let's drag from (700,400) to (400,250) and screenshot, then check HUD center changed. Then Reset view and compare.

Actually, let me first do the zoom test at a boundary point since that's the key verification. Plan:
1. Reload.
2. Scroll wheel up several times at a point near the seahorse valley boundary. In the initial view: buffer 1200x800, ppu 290.91, center (-0.5, 0). Complex at pixel (x,y): re = -0.5 + (x-600)/290.91, im = -(y-400)/290.91. Seahorse valley around (-0.75, 0.1): x = 600 + (-0.75+0.5)*290.91 = 600 - 72.7 = 527; y = 400 - 0.1*290.91 = 371. So scroll at (527, 371) — but the HUD panel covers up to x≈270, so fine.

Let me reload and do a sequence of scrolls at that point, then screenshot. Note the scroll action probably dispatches a wheel event at x,y.

Let me do: reload, then scroll at (527,371) with delta... delta positive = scroll down = zoom out. Use negative delta to zoom in. Each scroll of -100 → factor exp(0.32)=1.38. Hmm the harness may send the delta as deltaY directly. Let me use delta: -400 → factor exp(1.28) = 3.6x per call. Do a few calls.

I'll batch: reload first, then check.

Nice look now. Note the screenshot is taken mid-render (pass 3/4), so the corners still show the coarse pass. Fine.

Now test wheel zoom at a boundary point: (527, 371) seahorse valley. Do several scrolls.

Anchor drift 0.0000 px — good math. But the view jumped to center (-1.989, 0.993)! That's wrong: zooming at pixel (527,371) should keep the center near (-0.75, 0.1)-ish region, not move to (-1.99, 0.99).

Why? Because the scroll event's clientX/clientY... The harness's scroll may dispatch a wheel event with coordinates, but maybe the last pointer position used by my `eventBuf` is fine... Hmm, drift is 0 which means the anchor under the cursor stayed fixed. But the anchor was computed at the pixel the event reported. If the harness dispatched wheel with clientX/clientY = (0,0) or the last mouse position (which was maybe (600,400)?)... Let's compute: if the anchor pixel were (x,y) and after zoom center = (-1.989, 0.9927) with ppu = 290.91*3.6 = 1047.3.

Before: center (-0.5, 0), ppu 290.91. Anchor complex = center + (bx-600)/ppu, cy - (by-400)/ppu. After zoom: cx' = anchor.re - (bx-600)/ppu'. So anchor.re = cx' + (bx-600)/ppu'.

If bx = 527: (527-600)/1047.3 = -0.0697 → anchor.re = -2.0587. Then from before: -0.5 + (bx-600)/290.91 = -0.5 - 0.2509 = -0.751. Not equal → so bx wasn't 527.

Solve: anchor.re = -0.5 + (b-600)/290.91 = -1.989 + (b-600)/1047.3 → let u = b-600. -0.5 + u/290.91 = -1.989 + u/1047.3 → u(1/290.91 - 1/1047.3) = -1.489 → u(0.003437 - 0.000955) = u*0.002482 = -1.489 → u = -599.9 → b ≈ 0.01. So the wheel event had clientX ≈ 0! Similarly for y: anchor.im = 0 + (400-b_y)/290.91... let's check: cy' = anchor.im + (by-400)/ppu' → 0.9927 = anchor.im + (by-400)/1047.3 and anchor.im = -(by-400)/290.91 → 0.9927 = (by-400)(1/1047.3 + 1/290.91)... wait sign: anchor.im = 0 - (by-400)/290.91 = (400-by)/290.91. Then cy' = anchor.im + (by-400)/1047.3 = (400-by)/290.91 + (by-400)/1047.3 = (400-by)(0.003437 - 0.000955) = (400-by)*0.002482 = 0.9927 → 400-by = 400 → by ≈ 0.01.

So the harness's scroll dispatched the wheel at (0,0) — or maybe it doesn't set clientX/clientY on the wheel event. So my test is inconclusive regarding cursor-centered zoom via the harness, but the math is verified by the self-test (drift 0.00e+0 px across multiple zoom factors at a real pixel).

Hmm, but wait: maybe the scroll happened at the last known mouse position (0,0 default). The 'click' action takes x,y and probably moves the mouse first. Maybe I should click at (527,371) first to move the virtual mouse there, then scroll. Let me try: click at 527,371 (plain click does nothing in my handler since not shift), then scroll.

Also note: the render time 663ms for a full 4-pass render at 1200x800 with maxIter 730. That's slow-ish but it's progressive so UI stays responsive. Hmm, 663ms total. The first pass (step 8) should be fast. Let's see: 1200x800 = 960k pixels; passes 8,4,2,1 → work = 960k*(1/64+1/16+1/4+1) ≈ 1.31M sample computations. At maybe 5M simple iterations/sec... The escape loop with 730 iterations for interior points is heavy. Interior shortcut helps for cardioid but not for near-boundary points. 663ms is acceptable for progressive rendering. But we could speed up by dropping the step-2 pass or by using a cheaper approach. Let's keep but maybe reduce budget work: passes [8,4,2,1] is fine.

Actually let me reconsider: at deeper zoom with maxIter 3000+, full render could take several seconds. Progressive + fast preview during interaction handles it. Also add periodicity/skip? Let me consider adding a simple optimization: in renderRow, skip re-computation for identical rows? No.

One legit speedup: reduce the final pass work by using step 1 only where needed? Too complex. Alternatively lower MAX_BUFFER_PIXELS (already 2.2M cap; here DPR=1 so 960k).

Another optimization: use the "escape radius early exit" already; plus precompute per-row? The main cost is the inner loop. Could implement a small optimization: check |z|>2 bailout (B=2) for speed? No, we need large bailout for smooth. Actually we can use bailout 4 (|z|^2>16) and still smooth-color using the formula — with smaller bailout the escape happens earlier (fewer iterations for escaping points), which is faster. With R=4 (|z|>4... hmm my formula uses r up to R^2). Using BAILOUT=16 with |z|^2 > 256: escaping points break sooner. The smoothness formula remains valid for any R>2. Smaller R = fewer iterations for escaping points (a point that escapes needs log log |z| growth; from |z|~2 to 65536 requires ~4 extra doublings of the exponent... roughly 4-5 extra iterations). Not a big win.

A bigger win: periodicity checking for interior points. In the initial view, ~30% of pixels are interior but they're caught by cardioid/bulb tests mostly... Not all (boundary filaments). Let's add a cheap cycle detection: every 24 iterations, store zx,zy; if |z - z_old| < 1e-12 → inside. This can dramatically speed up deep interior regions. Implement:

```
let px=0, py=0, cnt=0;
while(i<maxIter){
  ...
  if (i === (periodicity save point)) ...
}
```
Standard: 
```
if ((i & 31) === 0){ if (Math.abs(zx-px)<1e-13 && Math.abs(zy-py)<1e-13) return -1; px=zx; py=zy; }
```
Hmm, that check happens at the top of loop. Cheap enough (1/32 iterations). Add it.

Also add: for deep zooms, "mini-Mandelbrot" detection? Skip.

Let me also reconsider the far-field: since most far-field pixels escape in 1-3 iterations, cost is dominated by near-boundary + interior. Periodicity check helps interior.

Let me add the periodicity check and test the timing.

Also, the harness's scroll at (0,0) means my "cursor" readout is stale. Let me test with click-then-scroll.

Also I noticed the status badge said "computing" while pass 4/4 shown — the status is set false only when finished or when interactive. In the last DOM it showed pass 4/4 and computing — probably mid-render at screenshot time. Fine.

Let me now: (1) add periodicity check, (2) test click then scroll sequence.

Wait: the periodicity check compares z_i with z_{i-64} sampled at the previous checkpoint. If the orbit has period dividing 64 (or has converged to a cycle of period k where 64 is a multiple of k... approximately), it returns inside. But there's a subtlety: it could false-positive on slowly diverging orbits (parabolic points), treating them as inside. That's acceptable (they're effectively inside visually). But careful: the check `Math.abs(zx-px)<1e-13` — with px sampled 64 iterations earlier. For attracting cycles with period p dividing 64, exact. For period not dividing 64, the difference won't be < 1e-13 unless convergence is extremely fast. It's a standard heuristic. Risk: at deep zoom, near parabolic points, points may be misclassified as inside — but they'd take maxIter anyway and look nearly inside. Acceptable.

Hmm, but one risk: false positives could create visible banding artifacts of "inside" color in deep zooms. Let me use a slightly looser threshold (1e-12) — no, tighter is safer against false positives. 1e-13 is fine.

Now reload and test: click at (527,371) then scroll.

Now click at (527,371) to move the pointer there (plain click shouldn't change the view since not shift and not dragged), then scroll.

Cursor readout = -0.75 + 0.10i — mapping is correct. Plain click did not change the view. Render time 522 ms (was 663 before periodicity check; ~20% faster).

Now scroll at the current pointer position (should be 527,371 now).

Zoom 2.61×, center (-0.6549, 0.0615), anchor drift 0.0000 px. The neck region between the period-1 bulb and period-2 bulb is now centered around x≈530,y≈420... Let's verify the anchor: the complex point -0.75+0.10i should be at pixel: x = 600 + (-0.75+0.654855)*ppu where ppu = 290.91*2.61 = 759.3 → x = 600 + (-0.095145)*759.3 = 600 - 72.3 = 527.7 ✓. y = 400 - (0.10-0.061518)*759.3 = 400 - 29.2 = 370.8 ✓. 

Now continue zooming deeper at the same point a few times to check detail appears and stays under the cursor.

Hmm — I'm zooming into the neck between the main cardioid and period-2 bulb, which is the "valley" — at 6.82x, the neck pinches at (-0.75, 0)... The view is dominated by black (interior of bulbs) with the pinch point. The anchor point (-0.75, 0.1) is in the seahorse valley region? Actually seahorse valley is around (-0.75, 0.1). Hmm, at 6.82x the image shows the region between the two bulbs with the pinch. The interesting seahorse structure is at (-0.745, 0.113) roughly. Let's continue zooming deeper at the same cursor point and see the seahorse shapes appear.

Also I notice the "computing" status badge remains visible even when pass = complete. Bug: after finishing, setStatus(false) is called in the branch... Let's look: in tick, when finished and !interactive and !pendingFull → setStatus(false). But the DOM text still says "computing" in the badge — the badge has class 'on' removed? The screenshot shows the badge visible at top-right with "computing". Hmm, at pass "complete" and render time 250ms, the badge should be hidden. The screenshot might be taken slightly before completion... but the DOM readout says complete. Wait, DOM readout and screenshot are from the same frame. Let me check the transition: `#status{opacity:0;transition:opacity .18s}` — so after removing 'on', it fades over 180ms; the screenshot right after may still show it partially. Actually the badge appears fully opaque in the screenshot. Hmm.

Wait, there's a real bug: in `tick`, when the render finishes but `interactive` is false and pendingFull false → setStatus(false). But then the next invalidate sets it true. In this case, the last wheel triggered invalidate(false) → interactive=false → renders → finished → setStatus(false). So the badge should be hidden. Unless... `updateProgress` is called before setStatus? No, updateProgress then the if-chain.

Look at the screenshot: badge at top-right shows "computing" with dot. Maybe the fade transition (0.18s) means it's still visible in the screenshot taken immediately. The screenshot is taken after the action's frame; timing uncertain. Not a big deal.

Actually wait — there might be a subtle issue: the screenshot for the previous action showed pass "1/1 px · pass 4/4" and "computing", so it was mid/just-finished. This one shows "complete" and still computing → likely mid-fade. Fine.

Let me continue zooming to check detail appears at the same anchor.

At 17.8× we're inside the valley — the pinch is at (-0.75, 0) region. The anchor (-0.75, 0.1) is at pixel (527, 371) — checking: ppu = 290.91*17.8 = 5178; x = 600 + (-0.75+0.7368512)*5178 = 600 - 67.2 = 532.8 ≈ 527 (rounding of displayed zoom) ✓. y = 400 - (0.1-0.0940916)*5178 = 400 - 30.6 = 369.4 ✓. Drift 0.0000 px.

The image at this zoom shows a valley with detail along the boundary but mostly black. The interesting seahorse structures are at around -0.745+0.1130i. Let me continue deeper a couple times to reveal detail (the spiral).

Note render time 180ms now (fewer pixels to compute since interior shortcut + periodicity). 

Let me zoom twice more and then check the detail.

The zoom is working and detail is appearing (seahorse-like structures along the boundary at 46.5×). Anchor drift stays 0.0000 px.

Now let me do the remaining verifications without repeating the same scroll:
1. Pan test (drag) then Reset view, compare to initial framing.

I'll do a drag from (700,400) to (450,250), then screenshot, then click Reset view and screenshot to compare with initial.

Note the panel is at top-left; drag from 700,400 → 450,250 is clear of it.

Let me do the drag.

Pan works: center moved from (-0.7455439, 0.0975449) to (-0.7405937, 0.0886049). Expected: dragging from (700,400) to (460,250) → dx = -240, dy = -150 buffer px. panBy: cx -= dxBuf/ppu → cx -= -240/13528 = +0.01774 → -0.7455+0.0177 = -0.7278. Hmm, actual change is +0.00495. The drag may have been performed in steps and the final center reflects... Actually the drag delta: ppu = 290.91*46.5 = 13528. -240/13528 = 0.01774. Observed Δcx = +0.00495. Hmm, that's about 1/3.6 of expected. 

Wait — during the drag, each pointermove pans by the delta from lastBuf. But `lastBuf` is set at the beginning of the handler (`pointers.set(e.pointerId, b)`) then `panBy(b[0]-lastBuf[0], ...)` then at the end `lastBuf = b`. That looks right. But: `invalidate(true)` restarts rendering each move — fine.

Hmm, but the total should still be the sum of deltas = final - initial = (-240, -150) regardless of steps, unless the last move's delta got lost. Let me check: the sequence is pointerdown at (700,400) → lastBuf is stale (from previous events, e.g. the click at 527,371 or the scroll position). On pointerdown I don't set lastBuf! So the first pointermove pans by (b - lastBuf_old) which could be a spurious jump. Then... hmm, that would make the pan bigger, not smaller.

Actually wait — the direction: dragging from 700→460 means content should move left, so center re increases: cx += 240/ppu = +0.0177. Observed +0.00495 ≈ 0.0177 * 0.28. Hmm.

Also possible: the harness's drag dispatches a few moves and then pointerup, and my pointerup handler calls invalidate(false) — fine.

Another possibility: the first pointermove had lastBuf = the previous position from the scroll (527,371)? Then delta = (700-527, 400-371) = (173, 29) → pan cx -= 173/ppu = -0.0128. Then subsequent moves sum to (-240,-150) relative to (700,400) → total = (460-527, 250-371) = (-67, -121) → cx += 67/13528 = +0.00495. That matches exactly! Δcx = +0.00495 ✓ and Δcy: -121/13528 → cy change = +121/13528? Let's check: panBy(dx,dy): cy += dyBuf/ppu. dy total = -121 → cy += -121/13528 = -0.00894 → 0.0975449 - 0.00894 = 0.088605 ✓ matches exactly (0.0886049).

So the bug is confirmed: `lastBuf` isn't initialized on pointerdown, so the first move pans by the delta from the previous pointer position (a jump). Fix: set `lastBuf = b` in pointerdown.

Also on pointerdown with 1 pointer, set lastBuf to that pointer's position.

Let me fix that. Also in endPointer when pointers.size===0 I set lastBuf = eventBuf(e) — that's fine but unnecessary; keep.

Fix: in pointerdown handler after computing b: `lastBuf = b;`.

Also `let lastBuf = [0,0];` is declared after the pointermove handler but before use at runtime — fine, but I'll move it up for clarity. Let me just add `lastBuf = b;` in pointerdown.

Then Reset view test.

Wait, the second edit replaced the `let lastBuf = [0,0];` that appears after the pointermove handler — but there were two occurrences? No: originally there was one `let lastBuf = [0,0];` after the pointermove handler. My first edit added a new `let lastBuf = [0,0];` in the pointers block. Then the second edit renamed the old one to `let lastBufUnused;`. But careful: the first edit's oldText included `pointers.set(e.pointerId, eventBuf(e));` — and the second edit's oldText `let lastBuf = [0,0];` — these don't overlap. But the second edit matched the first occurrence of `let lastBuf = [0,0];` in the original file... In the original file, the only occurrence was after pointermove. My first edit's newText also introduced a `let lastBuf = [0,0];` but edits are matched against the original file, so the second edit matched the original occurrence (the one after pointermove). Good — but I should verify the result.

Also, there's a subtlety: `let lastBuf` declared in the pointers block (before the handler) — and the `function zoomAtSilent` follows. Let me read the region to confirm correctness.

Good. Now let me also clean up: remove `let lastBufUnused;` line. And check line 421 context.

Also on `endPointer` when a second pointer is released, `lastBuf = it[it.length-1]` — good.

Let me remove the unused var.

Also I see a potential issue in the 2-pointer pinch branch: `if (lastMid && lastDist > 0){ panBy(mid[0]-lastMid[0], ...); }` — but on the first move with 2 pointers, lastMid was set in pointerdown, so fine.

Let me remove the unused declaration.

Now retest: reload (initial view), drag pan, verify the pan delta matches expectation, then Reset view and compare with initial framing.

Reload → then drag from (700,400) to (460,250) in the initial view: ppu = 290.91. Expected Δcx = +240/290.91 = +0.825, Δcy = +150/290.91 = +0.5156 → center = (-0.5+0.825, 0+0.5156) = (0.325, 0.5156). Let's check.

Note: pointerdown at (700,400) — the previous pointer position matters no longer since we seed lastBuf.

Let me reload and drag.

Initial view confirmed (center -0.5, 0, zoom 1.00×). Now drag pan.

Pan is now exact: center = (0.325, -0.51562) which matches predicted (+0.825, +0.5156 → wait, cy predicted +0.5156 but got -0.51562).

Hmm: dragging up (from y=400 to y=250, dy = -150) should move the content up, meaning we see lower imaginary values → center im decreases. panBy: cy += dyBuf/ppu = -150/290.91 = -0.5156 → cy = -0.5156 ✓. My earlier sign prediction was wrong; the code is right: content follows the pointer (grab & drag). Good.

The image is mid-render (pass 2/4, coarse 1/4 px). The set moved as expected (dragged right/up → set moved right/up, showing the set shifted).

Now click Reset view and compare with initial framing.

Reset view restores the exact initial framing (center -0.5, 0, zoom 1.00×, max iter 250) — identical to the first screenshot. 

Remaining checks/improvements:
1. The "computing" badge stays visible after render completes — verify. In this DOM it says pass 3/4 so still rendering. Let me do a final `inspect` after a moment to confirm the badge hides. Actually the badge is only hidden on completion; the screenshots are taken right after the action, mid-render. I'll do an inspect call which happens later in time.

2. Responsiveness during rendering: the UI stays interactive (we clicked Reset while... well, renders complete between actions). The chunked budget of 14ms/frame ensures pointer events process. Good enough.

3. One concern: `render time 410ms` for the full 4-pass render at 250 iterations. Fine.

4. Another possible issue: during a drag, invalidate(true) uses FAST_PASSES [8,4], and after pointerup invalidate(false) restarts from scratch at [8,4,2,1]. Slight redundancy but fine.

5. Potential issue: when `interactive` is true and rendering finishes, we stop the rAF loop and wait for the next pointermove. If the user stops moving mid-drag, the image shows a coarse render. Acceptable.

6. Check the wheel-preventDefault on the page: body has overflow hidden; wheel listener with passive:false on canvas. Good.

Let me do an inspect to check the status badge disappears after completion, and also test keyboard 'R' and the auto-iter checkbox quickly. Also test dblclick zoom.

Let me run: key 'r'? First inspect.

Render complete, full detail, and the "computing" badge is now gone (hidden). 

Remaining quick checks:
- dblclick zoom at a point (uses zoomAt) — should work like wheel.
- keyboard R reset.
- No console errors. ✓ (only the sandbox iframe warning).

Let me test dblclick at a boundary point (e.g., 640,300 near the top of the cardioid... let's use the seahorse valley at (527,371)) and then press 'r' to reset. Also check that after dblclick the drift is 0.

Time check: I've used maybe 6-7 minutes. Let's do a couple more quick checks then finalize.

One thing I should double check: the `click` handler with shiftKey zooms out; a plain double-click fires dblclick + click events; my click handler returns early if e.detail > 1. Good.

Let me test dblclick.

Plain click did nothing (correct). Now test keyboard 'r' — but the view is already at initial, so let me instead test the '+' key zoom (center) and then 'r' to reset. Actually let me test dblclick via two rapid clicks — the harness's click may not register as a dblclick. Skip; dblclick uses the same zoomAt path already verified.

Better use of remaining time: test keyboard 'r' after a zoom. Let me press '+' (zoom in at center) then 'r'.

Actually, an important untested path: the auto-iteration growth at deep zoom and precision limits. Also the "iter +/−" buttons. Let me do a quick key test: press '+' twice, then 'r', and check the HUD returns to 1.00×.

Keyboard '+' zoomed to 1.50× centered at the middle (center unchanged at -0.5, 0), maxIter auto-increased to 402. Good.

Now press 'r' to reset.

'R' key resets to the exact initial framing. 

Everything required is verified. A couple of small polish items I could add with remaining time:

1. The `pointerleave` handler sets cursor to '—' — fine.
2. Add a "deep zoom precision" note? At ppu clamp 1e18 the double precision breaks down (~1e14 zoom) and the image becomes blocky/noisy. Should I clamp max zoom to something sane like 1e13 and show a note? Let me set the ppu upper clamp based on precision: view.ppu max = ppu0 * 1e13? Currently Math.min(1e18, ...). Double precision gives ~15-16 significant digits; at zoom 1e13 the pixel size is ~1e-13 relative to coordinates ~1 → borderline. I'll clamp to 5e12 and show "precision limit reached" in the status when clamped. Small improvement; let me implement simply: in zoomAt/zoomAtSilent, if the requested factor would exceed the clamp, set a flag and show it in the drift/status row.

Let me implement a minimal version: MAX_PPU = ppu0 * 4e12 (clamped), and show a status text "max precision reached" briefly. I'll add to the status badge: if clamped, statusText shows 'precision limit'.

Also add a small "render time" is already there.

Let me do this edit carefully — the zoom clamps appear in zoomAt and zoomAtSilent. I'll add a helper `applyZoom(bx, by, factor)` returning drift and setting `atLimit`.

Implementation:

```js
const PPU_MAX_FACTOR = 4e12;
let atLimit = false;
function applyZoom(bx, by, factor){
  const before = toComplex(bx, by);
  const target = view.ppu * factor;
  const lim = ppu0 * PPU_MAX_FACTOR;
  atLimit = target > lim;
  view.ppu = Math.min(lim, Math.max(10, target));
  view.cx = before.re - (bx - W/2) / view.ppu;
  view.cy = before.im + (by - H/2) / view.ppu;
  const after = toComplex(bx, by);
  return Math.hypot((after.re-before.re)*view.ppu, (after.im-before.im)*view.ppu);
}
function zoomAt(bx,by,factor){ lastDrift = applyZoom(bx,by,factor); invalidate(false); }
function zoomAtSilent(bx,by,factor){ applyZoom(bx,by,factor); }
```
And in updateProgress: if atLimit, statusText shows 'precision limit reached'. But setStatus(false) hides the badge. Instead show in the drift row? Add: driftEl text stays; use the pass row? Let me add to the status badge: keep it visible with "precision limit — further zoom needs extended precision" — but the badge is hidden when not computing. Simplest: show the zoom readout with a "⚠" when at limit, plus a tooltip title. I'll do: zoomEl.textContent = fmtZoom(...) + (atLimit ? ' ⚠limit' : '').

Also, note that at extreme zoom the iteration count auto formula gives 250+260*log2(4e12)=250+260*41.9 ≈ 11,000 — capped at 20000, fine.

Let me apply this edit.

Careful: `atLimit` is declared with `let` in the navigation section (line ~430?) but `fitInitialView()` is called from `resize()` which is invoked at the bottom of the IIFE — after all declarations execute. So `atLimit = false` inside fitInitialView is fine (TDZ resolved by then). ✓

But `applyZoom` uses `lastDrift`? No, zoomAt assigns lastDrift which is declared with `let lastDrift = null;` after panBy — declared before use at runtime. ✓

Let me reload and check console for errors, then do a final deep-zoom test to confirm the limit works and detail renders.

No errors. Now one final deep-zoom check: zoom at a boundary point repeatedly to a high zoom to see detail and confirm iterations scale. Let me do 4 quick scrolls at (527,371) — but I need the pointer there first. The click action moves the pointer. Let me do: click at 527,371 then scroll 4x with -300 each → 2.61^4 ≈ 46x... Each -300 gives factor exp(0.96)=2.61. 4 scrolls → 46x. Let me do 5 scrolls → 121x. To go deeper faster, use delta -600 → factor exp(1.92)=6.8 per call. 5 calls → 1.5e4 x. Let's do that: click then 5 scrolls of -600.

I'll batch: click, then scroll (dependent order matters but they're sequential in one call? No — each tool call is separate; I can't guarantee ordering within one block for dependent calls, but these are independent-ish... they are order dependent. The instructions say make independent calls in the same block; these are sequential. I'll just do them one at a time but that costs turns. Let me do click + one scroll in one message? They'd run in order presumably. Risky. I'll do click first, then a single message with 5 scrolls (they'll execute in the given order within the block, I believe sequentially). Let me try: put 5 scroll calls in one block.

Good, complete render. Now 4 scrolls of -600 at the same point (sequential in one block).

6.82× in one -600 scroll. Let me do 4 more scrolls to reach ~2000x, then screenshot to check detail. Then also test the "iter" buttons? Not needed.

Let me do 4 scrolls in one block (sequential).

46.5×, drift 0. Seahorse structures visible. Continue 3 more scrolls to ~2000×.

At 317× we see the seahorse valley spiral structures — mid-progressive-render (pass 2/4 at 1/4 px). Anchor drift 0.0000 px, and the anchor point (-0.75,0.1) is at pixel (527,371) — checking: ppu = 290.91*317.3 = 92,306; x = 600 + (-0.75+0.75014677)*92306 = 600 + 13.6 = 613? Hmm that gives 613, not 527.

Wait: -0.75 - (-0.75014677) = +0.00014677 → x = 600 + 0.00014677*92306 = 600+13.5 = 613.5. That's not 527!

Hmm, that suggests drift! Let me recompute ppu: 290.91 * 317.3 = 92,306. And the displayed center has 8 decimals: -0.75014677. So the anchor at pixel 527: re = -0.75014677 + (527-600)/92306 = -0.75014677 - 0.000791 = -0.750938. But the cursor readout says -0.75 + 0.10i (displayed with only 2-3 decimals because the digits calc is broken!).

Ah — the "cursor" readout uses digits = max(3, min(15, ceil(log10(ppu/10)*1.2))) = ceil(log10(9230)*1.2) = ceil(3.965*1.2)=ceil(4.76)=5 → 5 digits. It shows "-0.75 + 0.10i" which is only 2 decimals... because toFixed(5) of -0.750938 = "-0.75094". But it displays "-0.75". Hmm, that means the cursor readout is from the stale pointermove (before the zoom) — the cursor hasn't moved since; the readout is only updated on pointermove, not after a zoom. That's a minor UX wart: after zooming, the "cursor" readout is stale. I should update the cursor readout on render/zoom if the pointer position is known.

So the displayed "-0.75 + 0.10i" is the complex point under the cursor from before the zoom (correct at that time). After the zoom, the same pixel maps to -0.750938+0.0992...i. Wait, that contradicts anchor invariance!

Hold on. The anchor should be invariant: the complex point under pixel 527,371 before the zoom should equal the point after. Before this last zoom: center (-0.7455439, 0.0975449), ppu = 290.91*46.5 = 13,527. Point at (527,371): re = -0.7455439 + (527-600)/13527 = -0.7455439 - 0.005397 = -0.750941. im = 0.0975449 - (371-400)/13527 = 0.0975449 + 0.002144 = 0.099689.

After the zoom: re = -0.75014677 - 0.000791 = -0.750938, im = 0.09937337 + (29/92306)=0.09937337+0.000314 = 0.099687.

Both agree to ~1e-6 (limited by the displayed precision of the center). ✓ So the anchor IS invariant — the earlier discrepancy was my arithmetic error (I used -0.75 instead of the true anchor -0.750941).

So the cursor readout showing "-0.75 + 0.10i" is stale (from the earlier pointermove at 1× zoom when the pixel mapped to exactly -0.75+0.10i). It's just a display staleness issue. Let me fix: store the last pointer buffer position and recompute the cursor readout in updateProgress.

Also the initial click at (527,371) in the 1× view mapped to exactly (-0.75, 0.10) as computed — consistent.

Let me fix the stale cursor readout: keep `lastPtr = [bx, by]` set in pointermove, and in updateProgress recompute curEl from lastPtr if set.

That's a small polish. Let me implement and then do a final check.

Also, note the render at 317× took ~500ms+ (progressive). Fine.

One more consideration: the images at 317x show the "seahorse valley" spiral — recognizable boundary detail. 

Let me make the cursor-readout fix, reload, and do a final quick sanity check (screenshot at deep zoom + confirm no console errors).

`showCursor` is a function declaration (hoisted) but it references `curEl` (const declared later in HUD section) — at runtime, calls occur after the IIFE body has executed, so fine. But `let lastPtr = null;` is declared after the pointermove handler in the source; the pointermove handler assigns lastPtr — at runtime after init, fine. However, `updateProgress` → `showCursor` uses lastPtr; also fine.

Wait, one problem: `showCursor` is defined *after* the pointerleave listener but before... it's a function declaration inside the IIFE → hoisted. ✓

Let me reload and verify no errors, then do a final deep-zoom + reset check.

The reload shows the initial view rendering progressively (pass 2/4) — no console errors. Let me do one final quick check that the cursor readout updates after a zoom, then finish.

Actually, time is short. Let me do one combined quick verification: click at a point, scroll once, and check the cursor readout reflects the same complex value as before the zoom (proving both the fix and anchor invariance). Then finish.

Cursor readout: -0.75 + 0.10i at pixel (527,371) in the initial view. Now scroll once and check the cursor readout stays ≈ -0.75 + 0.10i (it should now update live after the fix).

The cursor readout now updates live after the zoom: "-0.751 + 0.100i" at the same pixel (527,371) — essentially identical to before the zoom (-0.75 + 0.10i), with the tiny difference being the last-digit rounding of the display precision (3 digits at this zoom). Anchor drift 0.0000 px. 

Everything is verified. Let me do a final syntax sanity check (node --check on the extracted script) and confirm the file is saved. Then finish.

Everything checks out with a single self-contained file and no external dependencies.

Reset restored the exact initial framing (center -0.5, 0; zoom 1.00×; maxIter 250) — pixel-identical to the first screenshot. Final file is saved.

Wait — the file timestamp is 02:54 but I edited after the last reload? Let me check: the last edit (cursor readout fix) was before the reload, and the reload at that point showed the fix working. Actually no: the sequence was edit → reload → click → scroll (verified live cursor readout) → bash check → click Reset. The file hasn't changed since the edit, and the running page reflects the file. Good — timestamp 02:54 corresponds to my last edit. Fine.

Done. Write the final report.