Mandelbrot explorer · mimo-v2.5

Let me build a Mandelbrot explorer in a single index.html file. Requirements:

- Full-screen canvas, smooth escape-time gradient, distinct inside color.
- Initial view showing full cardioid and lobes (e.g., real -2.5 to 1.0, imaginary -1.25 to 1.25 or similar aspect-correct).
- Drag pan, wheel zoom centered on cursor point.
- Recompute fractal after navigation (progressive rendering: render low-res preview, then full res).
- Sufficient iterations scaling with zoom depth; keep controls responsive (use tiles/chunks or progressive passes, requestAnimationFrame).
- Reset view button; prevent wheel page scroll.
- Canvas 2D or WebGL. I'll use Canvas 2D with an ImageData renderer, computed in chunks via requestAnimationFrame to keep responsive.

Implementation plan:

State: center (cx, cy), scale (units per pixel or width in complex plane). Initial bounds: x from -2.6 to 1.2 (width 3.8), aspect fit so height matches. Let's compute based on canvas aspect: fit the region [-2.5, 1.0] × [-1.25, 1.25] into view. Simpler: set initial so the view width = 3.7 (from -2.5 to 1.2) centered at cx=-0.75, cy=0, and height = width / aspect. But requirement: "Initially show the complete main cardioid and surrounding lobes" — so ensure both x range covers [-2.1, 0.6] cardioid and [-2, -0.7] bulb, and imaginary range covers ±1.1ish. Let's define: fitBox = { x0: -2.5, x1: 1.0, y0: -1.25, y1: 1.25 }. Compute scale so that both fit: scale = min((x1-x0)/w, (y1-y0)/h) → complex units per pixel, then center = (-0.75, 0). Actually center of that box is (-0.75, 0). Fine.

Renderer: use a resolution approach. When view changes, render progressively:
- Pass 1: render at coarse stride (e.g., 8x8 blocks, sample center of block), draw scaled to canvas with imageSmoothing enabled → fast preview.
- Then render full res row by row in chunks over rAF frames, writing into ImageData.

Simpler robust approach: keep two ImageData buffers: preview ImageData at1/8 resolution, and final ImageData at full res. Render preview quickly (few ms), then full-res in row chunks with a time budget per frame (e.g., 12 ms per frame). Draw: put preview scaled via drawImage of a small canvas, then progressively putImageData for completed rows (or draw the full-res canvas as rows get filled — putImageData of completed strip).

Also: "sufficient iterations to reveal new detail as user zooms" — iterations = base + f(zoom). Use something like: iters = clamp(round(110 + 90 * log2(initialScale/scale)), 100, 3000). Maybe scale more generously: iters = 120 * (1 + 0.6*log2(zoom))? Let's do: zoomDepth = log2(initialSpan/currentSpan); iters = Math.min(4000, Math.floor(120 + 100*zoomDepth) )? At zoom depth 20, that's 2120 iterations. Good. Add periodicity checking and Cardioid/bulb early-out for speed.

Escape radius: R=2 standard but smooth uses nu = n + 1 - log(log|z|)/log2 with R=2... better use R² = 16 or escape radius 4? Use standard: bailout 16 for smoother: nu = n + 1 - log2(log|z| / log(R))... Use: mag2 = x*x+y*y; if mag2 > 256 (R=16): nu = n + 1 - Math.log(Math.log(mag2)*0.5/Math.LN2)/Math.LN2 → let me get formula: with escape radius R, smooth = n - log2(log|z|/log R). Let's implement: logZn = Math.log(mag2)/2 (that's log|z|); nu = Math.log(logZn / Math.log(R)) / Math.LN2; smoothN = n + 1 - nu. With R=16.

Coloring: procedural gradient — map t = sqrt(smoothN / maxIter) or use a periodic palette: t = smoothN; color = palette( t * 0.05 or so ) using sinusoidal palette: 
r = 0.5 + 0.5*cos(2π*(a*t + p1)), etc. Use multiple palettes? Keep one nice smooth palette with continuous bands. Let's use: s = Math.sqrt(smooth) * 0.12 or something... Actually a common approach: f = smooth/maxIter then gamma. But sqrt-based gives better banding distribution. I'll use:

const t = Math.pow(smooth, 0.5); then color cycles:r = 127.5*(1+Math.cos((t*0.05+0.0)*2π))... let's design palette:

function color(t) where t is smooth escape value:
  a = t * 0.045 (cycle density)
  r = 128 + 127*Math.cos(6.283*(a) + 0.0)
  g = 128 + 127*Math.cos(6.283*(a) + 2.094)
  b = 128 + 127*Math.cos(6.283*(a) + 4.188)

That's a rainbow cycle. Multiply by a subtle darkening as t grows? Maybe blend to keep variety. Add a second modulation for richness: multiply by (0.85 + 0.15*cos(t*0.01)). Fine — procedural, smooth.

Inside: distinct color, e.g., dark navy/black: (8, 10, 18) or deep blue (12, 12, 40).

Better coloring: use palette with a few color stops interpolated, e.g., deep blue → cyan → yellow → orange → dark. Let's do a small palette array of stops with linear interpolation on t01 = something. But palette with sqrt mapping: t01 = Math.sqrt(smooth)/Math.sqrt(maxIter) → too compressed at high iteration. Common: t01 = (smooth - min)/(max-min) with logarithmic: t01 = Math.log(smooth+1)/Math.log(maxIter+1). Then color via cosine palette of t01*2. Hmm, with log mapping bands spread.

I'll go: esc = smooth (float ≥ 1... could be less); s = Math.log(esc + 1) / Math.log(maxIter + 1); then palette using cosine with4 stops, plus cycle repeat: use s directly in cosine palette — creates cycles. Let's just do:

const a = 0.55, b = 0.45; 
angle = s * 6.283 * 3.5 + phase? At high zoom maxIter big, s ranges full0..1.

Actually many explorers use: color index = smooth escape value directly with a repeating palette, giving nice self-similar rings. I'll use t = smooth, and cycle = t * k where k depends: to keep banding similar regardless of maxIter, use t scaled: u = Math.sqrt(smooth) * 0.15. Then cosine palette with3 channels offset. This gives constant-ish band width in sqrt space. Good enough — it's smooth and colorful.

Let me add subtle shading: multiply by (0.7 + 0.3 * something)? Keep simple.

Interaction:
- pointerdown on canvas: capture, track last pointer pos, on pointermove: dx pixels → pan: center.x -= dx*scale; center.y += dy*scale (screen y down → imaginary up). Then request render (preview immediately on drag; full res after drag ends).
- During drag, use last rendered frame scaled? Requirement says recompute after navigation rather than scaling a static image. During drag we can render preview at coarse stride quickly (e.g., 1/6 res preview is fast enough). To keep smooth, during drag render only preview; on pointerup render full res progressively.
- wheel: preventDefault (need { passive: false }); zoom factor = exp(-deltaY * 0.0015) clamp; anchor at cursor: compute complex point under cursor, then adjust center so that point stays under cursor: newCenter = anchor - (cursorPx - canvasCenterPx)*newScale. Standard formula.

Let me define scale = complex units per CSS pixel. view: cx, cy center; scale s.

complexFromPixel(px, py): re = cx + (px - w/2)*s; im = cy - (py - h/2)*s.

On wheel: anchor = complexFromPixel(px,py); newS = clamp(s * factor, minScale ~1e-14, maxScale 10); then set cx so that anchor maps to same pixel: anchor.re = cx' + (px - w/2)*s' → cx' = anchor.re - (px-w/2)*s'. Similarly cy' = anchor.im + (py - h/2)*s'.

Also keyboard maybe (optional). Add + / - keys? Not required. Keep minimal but maybe add +/- and arrow keys, R for reset. Nice extras.

Responsive: renderer uses a worker? No — use chunked rAF loop with time budget. Also cap device pixel ratio (use dpr = min(devicePixelRatio, 2)).

Progressive rendering design:

```
renderToken++ (invalidate)
state: { token, level: 'preview'|'final', rows done }
schedule:
  - renderPreview(): compute at stride P=8 (w/P × h/P ImageData), full loop in chunks too? Preview with stride 8 is 1/64 pixels; for 1600×900 that's ~22.5k pixels × iterations... at 120 iters ≈ few ms. Could be done in one go. But deep zoom with2000 iterations → 22.5k × 2000 = 45M ops ≈ 100+ms. Do preview chunked too, in strips.
```

Simplest robust: single progressive pipeline: render into offscreen canvas at current "quality". Levels: stride 16 → 4 → 1 (full). Each level draws to main canvas scaled up (with imageSmoothing on). Start with stride 16 quick, then 4, then 1. Each level rendered in chunks with per-frame time budget (~10ms). If a new navigation occurs, cancel and restart.

Each level writes its ImageData progressively into an offscreen canvas of size (ceil(w/stride), ceil(h/stride)), and we drawImage the offscreen onto main canvas scaled to full size. To show progressive filling within a level, draw the strip after each chunk. Draw order: drawImage offscreen (scaled) for the whole area each frame — completed rows show; uncompleted rows show garbage/stale? Initialize offscreen ImageData to a background (transparent or dark) at level start. Then drawImage with imageSmoothing → partially filled levels look like blurry bands appearing. Acceptable and typical.

To avoid full-canvas drawImage each frame cost: it's cheap (GPU). Fine.

Implementation:

```js
const off = document.createElement('canvas');
const offCtx = off.getContext('2d');

let job = null;
function startRender(qualityOnly) {...}

function requestRender(levels) {
  jobToken++;
  job = { token: jobToken, levels: [ {stride:16}, {stride:4}, {stride:1} ], idx:0, ... };
  startLevel();
  pump(); // schedule rAF
}
```

pump(): loop while performance.now()-frameStart < budget: compute next chunk rows. Then draw; if job continues, rAF again.

For pan drag responsiveness: on pointermove, we can pan by drawing the existing rendered content translated (that's just moving the image during drag, which is fine — the recompute happens after). Actually during drag, translating the already-rendered image is standard and not "scaling a static image" for navigation — recompute occurs after. But requirement says "Recompute the fractal after navigation rather than scaling a static image." During drag, panning the existing raster with a slight gap is acceptable; simplest: during drag, draw the previous offscreen shifted by the drag delta, and on pointerup do a full re-render. Or even simpler: render a coarse preview each pointermove (stride 16 with reduced iterations?) — could be janky. I'll do: during drag, blit shifted previous frame (with background fill for exposed area), throttle re-render to pointerup... but nicer: during drag, periodically (throttled, e.g. every 90ms) start a coarse preview render at stride 16 and blit. Complexity risk.

Plan: 
- onPointerMove during drag: update center; draw shifted previous offscreen (fast, smooth pan). Set flag needsRender.
- onPointerUp: requestRender().
Also during drag, we can immediately start a stride-16 preview job; when a chunk completes it draws unshifted, which would conflict with the shifted blitting... The job draws in its own coordinate frame — since center is changing during drag, the job would be stale anyway. So: cancel job on drag start; during drag just blit-shift; on pointerup start full pipeline. That keeps controls responsive and simple.

Hmm, but "keep controls responsive during rendering" — chunked pipeline handles that; also pointerdown during a render cancels the job immediately (so drag is smooth).

Now write the code.

Pixel loop (per pixel, per level):

```js
function renderRows(level, y0, y1) {
  const {stride, iw, ih, data, imgData} = level;
  const s = state.scale * stride; // complex units per level pixel
  const x0re = state.cx - (iw/2)*s; // wait careful: iw = w/stride
```

Hmm, mapping: full canvas pixel px maps to re = cx + (px - W/2)*S where S = scale (complex per full pixel). Level pixel ix corresponds to full pixel ix*stride (plus stride/2 for center). So re = cx + (ix*stride + stride/2 - W/2)*S. Let me define step = S*stride, and startX = cx + (stride/2 - W/2)*S, so re(ix) = startX + ix*step. Similarly im(iy) = startY - iy*step where startY = cy + (stride/2 - H/2)*S... check: im = cy - (py - H/2)*S, py = iy*stride + stride/2 → im = cy - (iy*stride + stride/2 - H/2)*S = (cy + (H/2 - stride/2)*S) - iy*step. So startY = cy + (H/2 - stride/2)*S.

Mandelbrot inner loop with cardioid/bulb check:

```js
const q = (re - 0.25)^2 + im^2;if (q*(q + (re-0.25)) <= 0.25*im*im) → inside (main cardioid)
if ((re+1)^2 + im^2 <= 0.0625) → inside (period-2 bulb)
```

Only for stride level 0? It's cheap; use for all.

Loop:
```js
let zr=0, zi=0, zr2=0, zi2=0, n=0;
for (; n < maxIter; n++) {
  zi = 2*zr*zi + im; zr = zr2 - zi2 + re; zr2 = zr*zr; zi2 = zi*zi;
  if (zr2 + zi2 > 256) break;
}
```
Careful: compute order — need old zr. Standard:
```
const t = zr2 - zi2 + re;
zi = 2*zr*zi + im; zr = t;
zr2 = zr*zr; zi2 = zi*zi;
```

Then if n === maxIter → inside color. Else smooth:
```
const logZn = Math.log(zr2+zi2)/2;
const nu = Math.log(logZn/Math.LN2)/Math.LN2;   // with R effectively arbitrary? 
```
Standard smooth iteration: nu = log2(log|z| / log(R)) = log(log|z|/log R)/log 2. With bailout R²=256 → R=16, log R = 2.7726. Use: nu = Math.log(logZn / Math.LN2... wait log|z| = logZn (already natural log of |z|). log R = Math.log(16) = 2.7726. So nu = Math.log(logZn / 2.7726) / Math.LN2. smooth = n + 1 - nu.

Coloring function (precompute a lookup table? values up to maxIter; could be 4000 entries, cheap to build per render: LUT of 256 entries mapping index → but smooth values are continuous; build LUT of 1024 entries over smooth range [0, maxIter] with sqrt-ish mapping and interpolate? Simpler: compute cosine palette per pixel — a few cos calls per pixel; full res1600×900 = 1.44M pixels × maybe 6 cos = heavy but chunked. Better: LUT with 512 entries indexed by mapped t and do linear interpolation manually. Let's do LUT of 256 with float index interpolation.

t mapping: t = Math.sqrt(smooth) * K, where K chosen so bands cycle. Use frac = (Math.sqrt(smooth) * 0.08) % 1 → 256-entry palette over frac. Then index = frac*256, lerp between LUT entries. Good.

Palette: cosine-based, 4 stops:
```
function buildPalette() {
  for i in 0..255: u = i/256;
 r = 0.5 + 0.5*Math.cos(6.283*(u + 0.00)); // maybe with different freqs for interest ...
}
```
Let's make a nicer palette: interpolate through stops:
0.00 #0b0d2b (deep indigo)
0.25 #1b6ca8 (blue)
0.45 #35d6c3 (teal)
0.62 #fdf06a (yellow)
0.78 #f0803c (orange)
0.90 #8b2d8f (purple)
1.00 #0b0d2b (loop back)
Smooth (linear) interpolation is piecewise-linear — derivative discontinuities but visually fine; cosine smoothing between stops would be nicer. Use smoothstep interpolation between stops for smoothness. I'll implement with cosine easing.

Multiply color with slight depth shading: value *= 0.9 + 0.1*Math.cos(...)? Skip.

Inside color: (10, 12, 22) — distinct dark.

Also add a subtle "distance" ... no, keep it.

Iterations: 
```
const zoomDepth = Math.log2(initialSpan / (state.scale*W)); // span = width in complex units
maxIter = Math.min(3000, Math.floor(110 + 140*Math.max(0, zoomDepth)));
```
At depth 10 → 1510. At depth 20 → 2910 capped 3000. Hmm at deep zooms you need more but let's cap 4000 and coefficient 150: depth 20 → 3110. OK: base 120, +120 per doubling, cap 4000.

Also low quality levels could use fewer iterations? No — preview with fewer iterations changes colors; fine to use same (preview pixels are few).

Now display info: show iteration count and magnification in an overlay; also a "Reset view" button. UI: top-left panel with title and controls; bottom-left status. Keep wheel event on canvas only, and preventDefault. Also `touch-action: none` on canvas for pointer drags.

Requirement: "Provide Reset view to restore the initial bounds. Prevent wheel navigation from scrolling the surrounding page." So wheel listener with {passive:false} preventDefault. Also body overflow hidden.

Reset: state = initial; requestRender().

Resize handling: on window resize, recompute W/H (canvas backing size with dpr), refit initial bounds? On resize keep center and scale, re-render. If never zoomed/panned, re-fit initial. I'll just keep center/scale and re-render.

Let me also handle pointer events: use setPointerCapture; support touch via pointer events (touch-action:none).

Double-click zoom in? Not required; skip or add (nice). Add dblclick zoom ×2 at cursor. Fine, cheap.

Now writing the file.

Draw logic per chunk: after computing rows [y0,y1) for the level, we need to update the offscreen canvas. Maintain per-level an ImageData covering full offscreen; putImageData with dirty rect (0, y0, iw, y1-y0) → but ImageData of full size; use offCtx.putImageData(imgData, 0, 0, 0, y0, iw, y1-y0). Then main draw: offCtx image → main canvas: ctx.drawImage(offCanvas, 0, 0, iw, ih, 0, 0, W, H) with imageSmoothingEnabled = true (for stride>1) / false for stride 1 (or just true, at stride 1 it's 1:1 so no smoothing matters).

Main canvas backing size W×H = CSS size × dpr. Level stride relative to backing pixels: strides [8, 2, 1]? At dpr 2, stride 8 → 1/16 CSS res preview. Let's use strides [12, 4, 1] or adaptive: choose first stride so that level pixels ≤ ~4000 for speed. Simpler: strides = [16, 6, 2, 1]? Each level full recompute multiplies work by ~ (1/stride²): 1/256 + 1/36 + 1/4 + 1 ≈ 1.32× full cost. Fine. I'll use [16, 5, 1]. Hmm 1/256 + 1/25 + 1 = 1.06. Good.

For each level, init ImageData filled with background (e.g., fill with inside color? or transparent black). Use transparent? drawImage of transparent shows previously drawn content beneath → confusing. Clear main canvas to background color before drawing each level's first chunk. I'll fill level ImageData with a dark bg (the inside color) — looks like a dark render filling in. Then draw. Good.

Chunking: per level, iterate rows in chunks; rows per chunk computed adaptively: aim ~8ms per chunk: track time. Simpler: fixed rows per chunk based on stride: chunkRows = stride===1 ? 4 : 64; then measure elapsed and adjust chunkRows dynamically (adaptive controller: after each chunk, chunkRows *= target/measured, clamp). Let's implement simple adaptive: after each chunk, if elapsed > 12ms → chunkRows = max(2, chunkRows*0.7); if < 4ms → chunkRows *= 1.4. Keep it per job.

Also handle devicePixelRatio.

Also skip work with periodicity check (bail on cycle detection):```
if (n > 0 && zr === prevZr && zi === prevZi) → inside
```
Check every 32 iterations. Implement cheaply:```
let zrPrev=0, ziPrev=0;
...
if ((n & 31) === 0) { if (zr===zrPrev && zi===ziPrev) { n = maxIter; break; } zrPrev=zr; ziPrev=zi; }
```
Floating exact equality works since same operations repeat. This greatly speeds deep zooms in interior. Good.

Status text updates: iterations, magnification (initialSpan/span, formatted ×e.g. 1.2e6), and render state ("rendering…" / "ready").

Also add subtle crosshair? No.

Let me now write index.html.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Mandelbrot Explorer</title>
<style> ... </style>
</head>
<body>
<canvas id="view"></canvas>
<div id="hud"> ... </div>
<script> ... </script>
</body>
</html>
```

CSS: body margin 0, overflow hidden, background #05070f, font system-ui. Canvas position fixed inset 0, cursor grab/grabbing, touch-action none, display block. HUD: fixed, top12px left 12px, panel with glass style, buttons. Reset button styled. Also a hint line.

JS code:

```js
(function(){
const canvas = document.getElementById('view');
const ctx = canvas.getContext('2d', {alpha:false});
let W=0,H=0,dpr=1;

const INITIAL = {cx:-0.75, cy:0, spanW: 3.5}; // real range [-2.5, 1.0]
// height derived from aspect; but we must guarantee vertical coverage ±1.25 too:
// compute initial scale = max(spanW/W, 2.5/H) so both fit.
```

Wait: scale per pixel S such that real range covered = W*S ≥ 3.5 and imaginary range H*S ≥ 2.5 (from -1.25..1.25). Take S0 = Math.max(3.5/W, 2.5/H). Then recompute on resize: recompute S from current W,H if at "home" (not moved) — track a flag `atHome` = view matches home. Simpler: store homeScale recomputed on resize; if user hasn't navigated (state.isHome true), set scale = homeScale, cx=-0.75, cy=0.

Magnification = homeScale/scale.

State object:
```js
const view = {cx:-0.75, cy:0, scale:1};
```

Functions:
- resize(): set canvas.width/height from clientWidth*dpr etc. compute homeScale; if view.isHome → update; requestRender().
- pixToComplex(px,py)
- reset(): view.cx=-0.75; cy=0; scale=homeScale; isHome=true; requestRender()

Rendering pipeline code:

```js
let jobToken = 0, job = null, rafId = 0;

function requestRender(){ jobToken++; job = {token: jobToken, li:0, y:0, chunkRows: 32, levels:null}; ensureLevels(); if(!rafId) rafId = requestAnimationFrame(frame); }

function ensureLevels(){ // build level canvases sized to current W,H
  const strides=[16,5,1];
  job.levels = strides.map(stride => {
    const iw = Math.max(1, Math.ceil(W/stride)), ih = Math.max(1, Math.ceil(H/stride));
    const cv = document.createElement('canvas'); cv.width=iw; cv.height=ih;
    const c2 = cv.getContext('2d');
    const img = c2.createImageData(iw, ih);
    // fill bg    fill(img.data, insideColor r,g,b, a255)
    c2.putImageData(img, 0, 0);
    return {stride, iw, ih, cv, c2, img, maxIter: computeIter(), sx, sy, step};
  });
}
```

Wait — level geometry: level pixel ix covers full pixels [ix*stride, (ix+1)*stride). Sample at center: py = (ix+0.5)*stride. Then re = cx + ((ix+0.5)*stride - W/2)*S = cx + ((0.5*stride) - W/2)*S + ix*(stride*S). So sx = view.cx + (stride*0.5 - W*0.5)*view.scale; step = view.scale*stride. Similarly sy = view.cy + (H*0.5 - stride*0.5)*view.scale; im(iy) = sy - iy*step.

Compute these per level at job creation (snapshot view).

frame():
```js
function frame(){
  rafId = 0;
  if(!job) return;
  const t0 = performance.now();
  while (performance.now() - t0 < 12 && job) {
    if (!stepJob()) break;
  }
  drawMain();
  if (job) rafId = requestAnimationFrame(frame);
  updateStatus();
}

function stepJob(){ // returns false when waiting/done
  const L = job.levels[job.li];
  if (!L) { job = null; return false; }
  if (job.y === 0) { ctx.fillStyle='#0a0c16'; ctx.fillRect(0,0,W,H); } // clear bg when starting level (so unfilled area is dark)
```
Hmm, drawing bg then drawImage of the level canvas (which is fully filled with bg anyway) covers it. So the fillRect isn't needed; drawImage covers whole canvas. Fine, skip. But the first draw of level 0 will show dark bg + computed rows. OK.

```js
  const y1 = Math.min(L.ih, job.y + Math.max(1, Math.round(job.chunkRows)));
  computeRows(L, job.y, y1);
  L.c2.putImageData(L.img, 0, 0, 0, job.y, L.iw, y1 - job.y);
  job.y = y1;
  const dt = performance.now() - t0;
  // adapt
  ...
  if (job.y >= L.ih) { job.li++; job.y = 0; job.chunkRows = ... reset }
  return true;
}
```

Careful with adapt inside stepJob (t0 defined in frame). Let me restructure: do chunk in frame and adapt there.

drawMain(): 
```js
const L = job.levels[job.li];
ctx.imageSmoothingEnabled = true; // 'high'
ctx.drawImage(L.cv, 0, 0, L.iw, L.ih, 0, 0, W, H);
```
Note W,H are backing pixels; drawing1:1.

When job done, job=null; final draw already happened for last chunk. Good. But ensure final drawMain called after job finishes: in frame loop, after while loop, drawMain(); then if job null, done.

Drag pan rendering:```js
let drag = null;
canvas.addEventListener('pointerdown', e => { cancelJob(); canvas.setPointerCapture(e.pointerId); drag = {id:e.pointerId, x:e.clientX, y:e.clientY, ox:0, oy:0, sx:e.clientX, sy:e.clientY}; canvas.classList.add('grabbing'); });
pointermove: if drag: dx = e.clientX - drag.x ... view.cx -= dx*dpr*view.scale; view.cy += dy*dpr*view.scale; drag.ox += dx; ... then drawPanned(dx,dy) blit previous composite shifted.
```

For drawPanned: we need the last rendered full-res-ish image. Keep a `snapshot` canvas updated after each completed job and each chunk? Simplest: on pointerdown (before cancelling job), copy main canvas into a snapshot canvas: snapCtx.drawImage(canvas,0,0). Then during drag: 
```js
function drawPanned(dx, dy){ // CSS px
  const px = dx*dpr, py = dy*dpr;
  ctx.drawImage(snap, px, py, W, H);
  // fill exposed strips with bg color
  ctx.fillStyle = '#0a0c16';
  if (px > 0) ctx.fillRect(0,0,px,H); else if (px<0) ctx.fillRect(W+px,0,-px,H);
  if (py > 0) ctx.fillRect(0,0,W,py); else if (py<0) ctx.fillRect(0,H+py,W,-py);
}
```
Since view.cx -= dx*dpr*scale means content moves right by dx*dpr px. Yes: if drag right (dx>0), image shifts right → exposed area on left → fill left strip px>0 → fillRect(0,0,px,H). ✓.

On pointerup: drag=null; remove class; requestRender(). Also pointercancel.

Also mark isHome false when panning/zooming unless result equals home (just set isHome=false).

Wheel:
```js
canvas.addEventListener('wheel', e => {
  e.preventDefault();
  const rect = canvas.getBoundingClientRect();
  const px = (e.clientX - rect.left)*dpr, py = (e.clientY-rect.top)*dpr;
  zoomAt(px, py, Math.exp(clampDelta(e.deltaY)));
  requestRender(); // but re-render at every wheel event could thrash — cancelJob + restart each event; that's ok since job restarts from coarse levels giving fast feedback. Throttle: schedule after small delay? Restarting each event means while scrolling you see only coarse previews (fine, responsive). But continuous wheel generates many jobs each starting at stride 16 → good feedback.
}, {passive:false});
```

Wheel delta normalization: deltaMode: 0 pixels, 1 lines, 2 pages. 
```js
let dy = e.deltaY; if (e.deltaMode === 1) dy *= 16; else if (e.deltaMode === 2) dy *= 100;
const factor = Math.exp(-dy * 0.0016);
```
Clamp factor per event to [0.2, 5]? exp(-dy*0.0016): typical deltaY100 → factor e^-0.16 = 0.85 per notch. Good.

zoomAt(px,py,factor):
```js
const re = view.cx + (px - W/2)*view.scale;
const im = view.cy - (py - H/2)*view.scale;
const ns = clamp(view.scale*factor, minScale, maxScale);
view.cx = re - (px - W/2)*ns;
view.cy = im + (py - H/2)*ns;
view.scale = ns; view.isHome=false;
```

minScale: homeScale * 1e-14 (zoom depth ~46 → beyond float precision anyway; float64 gives ~1e-15 relative; but pixel offsets ~1e-16*span... set min = homeScale*5e-15). Let's allow down to 1e-13 of home. maxScale = homeScale*4.

Debounce wheel: use a small timeout to start render after last wheel event (e.g., 60ms) so rapid wheel doesn't thrash? But then no feedback while scrolling. Alternative: start render immediately each event (cancel previous). The stride-16 preview for a 1600×900 canvas = 100×56 = 5600 px → trivially fast even at 4000 iters? 5600 × 4000 worst case = 22M iterations ~50-100ms worst-case (interior). Acceptable-ish but could cause stutter during fast wheel. Mitigate: preview levels use maxIter capped at e.g. min(maxIter, 350)? That changes colors in preview slightly — visually a preview with fewer iterations shows more points escaping (interior looks smaller). Hmm, could look glitchy. Alternative: stride 16 preview + periodicity check makes interior fast. I'll cap preview iterations at 600 for strides > 1 and note preview quality. Actually the periodicity check makes interior points bail quickly regardless of maxIter (cycle detected in < ~50 iterations for interior). So no cap needed. 

But an important detail: smooth coloring uses sqrt(smooth) — for capped iterations colors differ between preview and final only if points escape after600. Minor. I'll skip caps and rely on periodicity check + chunking.

Also: add keyboard: R reset, +/- zoom at center, arrows pan. Cheap and nice. Include.

Status overlay: "Iterations: 1240 · Magnification: ×1.2e+5 · rendering…" update in frame and after.

Also add small "deep zoom" note? Skip.

Let me also add a color palette toggle button? Not required; but "procedural colors" satisfied. Could add a palette cycle button for fun — maybe skip to save time. I'll add a small palette selector (3 palettes) as a bonus? Keep scope tight — time budget. I'll add just one extra: pause? No. Keep Reset + maybe "iterations" slider? Requirement mentions "Use sufficient iterations to reveal new detail as the user zooms" — automatic. I'll skip extras except keyboard shortcuts.

Now write the palette LUT:

```js
const STOPS = [
  [0.00, 10, 12, 34],
  [0.16, 18, 46, 110],
  [0.34, 26, 130, 190],
  [0.50, 60, 220, 200],
  [0.64, 240, 235, 120],
  [0.78, 240, 140, 60],
  [0.90, 150, 40, 120],
  [1.00, 10, 12, 34],
];
function paletteAt(u){ // u in [0,1)
  find segment, t local, ease t = t*t*(3-2t), lerp rgb
}
const LUT = new Uint8Array(256*3);
for i: LUT[i*3..] = paletteAt(i/256)
```

Color per pixel:
```js
const sq = Math.sqrt(smooth); // smooth ≥ ~1
let u = (sq*0.09) % 1;  // banding
const fi = u*256; const i0 = fi|0; const fr = fi - i0; const i1 = (i0+1)&255;
r = LUT[i0*3] + (LUT[i1*3]-LUT[i0*3])*fr; etc.
```

Inside: [7,9,18].

Band width: sqrt(smooth)*0.09 — for smooth=100 → 0.9; smooth=1000 → 2.85 (≈2.85 cycles); smooth=4000 → 5.7 cycles. Reasonable.

Add slight brightness variation to make it pretty: multiply by 0.92+0.08*cos(sq*0.02)? Skip.

computeRows(L, y0, y1):

```js
function computeRows(L, y0, y1){
  const {iw, step, sx, maxIter, stride} = L;
  const data = L.img.data;
  const sy = L.sy;
  const bailout = 256; // R^2
  const logBailout = Math.log(bailout)/2; // log R  = ln(16)
  for (let iy=y0; iy<y1; iy++){
    const im = sy - iy*step;
    let p = iy*iw*4;
    for (let ix=0; ix<iw; ix++, p+=4){
      const re = sx + ix*step;
      // cardioid/bulb      const xm = re - 0.25, q = xm*xm + im*im;
      if (q*(q+xm) <= 0.25*im*im || (re+1)*(re+1) + im*im <= 0.0625){ setInside; continue; }
      let zr=0, zi=0, zr2=0, zi2=0, zrP=0, ziP=0, n=0;
      for(; n<maxIter; n++){
        const t = zr2 - zi2 + re;
        zi = 2*zr*zi + im;
        zr = t; zr2 = zr*zr; zi2 = zi*zi;
        if (zr2+zi2 > bailout) break;
        if ((n & 31) === 0 && zr===zrP && zi===ziP){ n = maxIter; break; }
        if ((n & 31) === 0){ zrP = zr; ziP = zi; }
      }
      if (n >= maxIter){ inside; continue; }
      const logZn = Math.log(zr2+zi2)/2;
      const nu = Math.log(logZn/logBailout)/Math.LN2;
      const smooth = n + 1 - nu;
      ... color
    }
  }
}
```

Wait: the periodicity check sets n=maxIter and breaks → then n>=maxIter → inside. ✓. But careful: break happens when n&31===0 and equal — at n=0, zr=zi=0=zrP,ziP → would mark every point inside! Guard n>0: use `if (n > 0 && (n & 31) === 0 && ...)`. At n=0, (n&31)===0 → sets zrP=zr=0, ziP=0. That's fine as long as equality check requires n>0. Let me restructure:

```js
if ((n & 31) === 0){
  if (n > 0 && zr === zrP && zi === ziP){ n = maxIter; break; }
  zrP = zr; ziP = zi;
}
```
✓

Note: cardioid test `q*(q+xm) <= 0.25*im*im` — standard: (x - 1/4)² + y² ≤ ... Let me verify: the main cardioid test: let q = (x-0.25)² + y²; q*(q + (x-0.25)) ≤ 0.25*y². Yes standard. And period-2 bulb: (x+1)² + y² ≤ 1/16 = 0.0625. ✓

Also careful: these tests mark points inside the set — they're mathematically exact so fine.

Escape check uses bailout R²=256, but cardioid/bulb tests happen before loop; fine.

Now the smooth nu formula: standard with escape radius R: mu = n + 1 - log(log|z|)/log(2). Many implementations use log2(log|z|/log R). With R=16: nu = Math.log(logZn / Math.LN2... wait careful, logZn here = ln|z| = log(zr2+zi2)/2. log R = ln16 = 2.7726 = Math.LN2 * 4. nu = ln(ln|z| / ln16) / ln2. Yes as coded with logBailout = Math.log(bailout)/2 = ln(256)/2 = ln(16). ✓

Status/magnification formatting: mag = homeScale/view.scale; format: if mag < 1000 → toFixed(1); else exponent notation: mag.toExponential(2).

Iteration count display uses levels[last].maxIter or computeIter().

Now let me also ensure "keep controls responsive during rendering": chunked rAF with ~12ms budget, pointer events cancel job on pointerdown. Good.

One more: while a final (stride 1) job is running, coarse levels were drawn before → user sees progressive refinement. ✓

Edge: resize during job → cancel and restart (levels sized to old W). On resize: jobToken++; job=null; rebuild; requestRender().

Also handle window resize with debounce (150ms).

Also should I use `canvas.width = Math.round(clientWidth*dpr)`. Use ResizeObserver on canvas or window resize listener. Use window resize + initial layout.

DPR change (zooming browser) — handled by resize listener.

Let me write the full file now.

Also add HUD elements: 
- Panel: "Mandelbrot Explorer", instructions ("Drag to pan · Scroll to zoom · R to reset"), Reset view button.
- Status bar bottom-left: iterations, magnification, state.
- Maybe a small render indicator (spinner-free: text "rendering…").

Style: translucent dark panels, backdrop-filter blur (works offline), rounded, monospace numbers.

Accessibility: button focus styles.

Write it.

Also touch pinch zoom? Pointer events give single pointer; multi-touch pinch would need tracking two pointers. Nice-to-have; adds risk. I'll add simple pinch support: track active pointers map; if two pointers, zoom by distance ratio. It's maybe 25 lines. Given time budget (15 min), and verification focus on desktop behaviors, I'll include a modest pinch implementation carefully.

Let me implement pointers map:
```js
const pointers = new Map();
pointerdown: pointers.set(id, {x,y}); if size===1 → start pan; if size===2 → start pinch (record start dist, start scale, midpoint px/py).
pointermove: update pointers; if pinch active (size===2) → compute new dist, factor = dist/startDist... incremental: zoom anchored at midpoint. Implement: on move with 2 pointers: const mid = midpoint; const d = dist; factor = d/lastD; zoomAt(mid, factor); lastD = d; redraw panned? During pinch just re-render coarse? Simplest: during pinch, blit-shift approximation won't be right for zoom. Alternative: during pinch, render a stride-16 preview on each move throttled? Could be janky but pinch is secondary; I'll do a coarse preview render throttled at ~60ms using a "quick" job with strides [16] only (preview-only mode) then full render on release.

Hmm, that adds complexity. Simpler: during pinch, update view and call renderPreviewOnly() throttled. Let me implement job with `previewOnly` flag: levels = [stride16] only (plus maybe 5). Then on pointerup (pointers.size<2 → when it drops to 1, restart pan mode) full render.

Actually the same previewOnly approach could serve pan-during-drag too, giving live recomputed preview during drag! That's nicer and satisfies "recompute rather than scale" more strongly. But shifting blit is smoother. I could do both: blit shift immediately, plus throttled preview job that draws over when ready. During drag the job drawing would be at the current (updated) view so it's correct. Risk: job's drawImage overwrites the shifted blit showing a correctly-positioned coarse render — that's fine and looks good.

But complexity of interleaving job draws and drag blits... job draw uses its own offscreen, drawn at correct position for current center. Since center updates on every move, and job rows computed with snapshot at job start, if user continues dragging, the job's partially-filled rows become misaligned relative to the shifting center. Ugly artifacts during drag.

Decision: keep it simple — during drag/pinch, blit-shift (pan) and for pinch do nothing fancy: blit an unchanged snapshot while pinch (no live zoom feedback except scale changes on release)? That feels broken. Alternative for pinch: allow the coarse preview job during pinch but cancel-and-restart on each move with throttle80ms and don't blit during pinch. At stride 16 with time budget 12ms per frame, a preview completes in a couple frames typically → decent live feedback at ~15-30fps. OK do that: pinch → throttled previewOnly jobs, no blit.

I think that's acceptable. Mobile isn't the primary verification target.

Let me write code now. Careful with details.

```js
function computeIter(){
  const spanPx = W * view.scale;
  const depth = Math.log2(INIT_SPAN / spanPx); // INIT_SPAN = 3.5
  return Math.max(80, Math.min(4000, Math.round(110 + 120*Math.max(0, depth))));
}
```

Job creation:

```js
function startJob(previewOnly){
  jobToken++;
  const token = jobToken;
  const strides = previewOnly ? [16] : [16, 5, 1];
  const maxIter = computeIter();
  const levels = strides.map(stride => makeLevel(stride, maxIter));
  job = {token, levels, li:0, y:0, chunkRows: 48};
  if (!rafId) rafId = requestAnimationFrame(frame);
}
```

makeLevel computes iw,ih, canvas, ctx, ImageData filled with bg color (use the inside color [7,9,18], alpha 255) via data.fill? Need per-channel: 
```js
const d = img.data; for (let p=0;p<d.length;p+=4){d[p]=7;d[p+1]=9;d[p+2]=18;d[p+3]=255;}
```

frame():
```js
function frame(){
  rafId = 0;
  if (!job) return;
  const t0 = performance.now();
  while (job && performance.now() - t0 < BUDGET){
    const L = job.levels[job.li];
    if (!L){ finishJob(); break; }
    const c0 = performance.now();
    const y1 = Math.min(L.ih, job.y + Math.max(1, job.chunkRows|0));
    computeRows(L, job.y, y1);
    L.c2.putImageData(L.img, 0, 0, 0, job.y, L.iw, y1 - job.y);
    L.c2... // drawImage to main
    ctx.drawImage(L.cv, 0, 0, L.iw, L.ih, 0, 0, W, H);
    job.y = y1;
    const dt = Math.max(0.5, performance.now() - c0);
    const rows = y1 - (y1 - ...)... 
```
Adapt: rowsDone = y1 - yStart; rate = rowsDone/dt (rows per ms); target6ms per chunk: chunkRows = clamp(rate*6, 2, 1024). Simpler:
```js
const rows = y1 - yStart;
job.chunkRows = Math.max(1, Math.min(1024, Math.round(rows / dt * 6)));
```
When moving to next level, reset chunkRows relative to level size: chunkRows = Math.max(1, Math.round(L.ih/8))? For stride 16 level ih≈56 → 7 rows per chunk — too small granularity but cheap; set chunkRows = max(1, ih/4) when entering level. Fine.

finishJob: job = null; update status 'ready'.

Status update: setStatus() called in frame and after events. Let me maintain DOM text updates only when changed to avoid layout thrash (cheap anyway).

drawMain when job null (e.g., after pan blit) is fine.

Also on cancelJob: jobToken++; job=null; (rAF loop exits since job null; rafId reset). If rafId pending and job null → frame returns early. ✓

Pan handling with preview job during drag: I decided blit only, no job during drag. Let me reconsider quickly: it's actually easy to start a previewOnly job on drag start and let it draw... but misalignment while moving as discussed. However, if I re-start the preview job on every pointermove (throttled to every ~100ms), rows computed from a fresh snapshot align with current center only at the moment of start; rows drawn over the next ~100ms drift. The drift per100ms of dragging could be tens of pixels → visible tearing between the stale top region (drawn by job from older center) and the blit underneath. Skip. Blit only during drag; full render on release. 

Now write everything. Also the double-click zoom: zoomAt(px,py,0.5) then render.

Also `canvas.addEventListener('contextmenu', ...)` — no need.

Prevent page scroll on wheel: also add `overscroll-behavior: none` on html/body and preventDefault in wheel handler attached to canvas. Also handle wheel on document? The page doesn't scroll (overflow hidden) but to be safe, preventDefault on document wheel when target is canvas or HUD. Keep canvas-only with passive:false.

Let me write the file.

Also I should verify with the browser tool: load, screenshot, zoom in, pan, reset, check console.

Write file now.

One more consideration for computeRows performance: inner loop with function calls avoided; ok.

Let me write:

```js
'use strict';
const canvas = document.getElementById('view');
const ctx = canvas.getContext('2d', { alpha: false });
let W = 1, H = 1, dpr = 1;
let homeScale = 1;

const HOME = { cx: -0.75, cy: 0 };
const INIT_W = 3.5;      // real range [-2.5, 1.0]
const INIT_H = 2.5;      // imaginary range [-1.25, 1.25]
const view = { cx: HOME.cx, cy: HOME.cy, scale: 1, isHome: true };
```

resize():
```js
function resize(){
  dpr = Math.max(1, Math.min(2, window.devicePixelRatio || 1));
  const cw = canvas.clientWidth || window.innerWidth;
  const ch = canvas.clientHeight || window.innerHeight;
  W = Math.max(1, Math.round(cw*dpr)); H = Math.max(1, Math.round(ch*dpr));
  canvas.width = W; canvas.height = H;
  homeScale = Math.max(INIT_W/W, INIT_H/H);
  if (view.isHome){ view.scale = homeScale; view.cx = HOME.cx; view.cy = HOME.cy; }
  cancelJob(); startJob(false);
}
```

Canvas CSS: position fixed; inset 0; width 100%; height 100%.

Now full code. Also min/max zoom: view.scale clamp: min = homeScale*1e-13, max = homeScale*2.

zoomAt:
```js
function zoomAt(px, py, factor){
  const s0 = view.scale;
  let s1 = s0*factor;
  s1 = Math.max(homeScale*1e-13, Math.min(homeScale*2, s1));
  if (s1 === s0) return;
  const re = view.cx + (px - W/2)*s0;
  const im = view.cy - (py - H/2)*s0;
  view.cx = re - (px - W/2)*s1;
  view.cy = im + (py - H/2)*s1;
  view.scale = s1; view.isHome = false;
}
```

Status: update text of #status: `Iterations ${maxIter} · ×${mag} · ${rendering? 'rendering…':'ready'}`.

HUD markup:

```html
<div class="panel">
  <h1>Mandelbrot Explorer</h1>
  <p class="hint">Drag to pan · Scroll to zoom · R resets</p>
  <button id="reset" type="button">Reset view</button>
</div>
<div class="status" id="status"></div>
```

CSS: .panel fixed top-left with rgba(10,14,26,.72), border 1px rgba(255,255,255,.12), border-radius 12px, padding 12px 14px, color #cfe0ff, font 13px system-ui; h1 15px letter-spacing .04em; button: background #2b6cb0? Use accent gradient; cursor pointer; :hover lighten; focus-visible outline.

.status fixed bottom-left, monospace 12px, color rgba(200,215,255,.75), background rgba(10,14,26,.6), padding 6px 10px, radius 8px, pointer-events none.

Also maybe show "double-click to zoom in" hint. Include in hint text: "Drag to pan · Wheel to zoom · Double-click zooms · R resets".

Keyboard handler on window: 'r' or 'Home' → reset; '+'/'=' zoom in at center; '-' zoom out; arrows pan by 10% of width.

Guard: if e.target is button and key is space/enter → let it be. Only handle r/+/-/arrows; fine.

Now write it all out. Then test in browser.

Let me be careful about the palette easing: 

```js
const STOPS = [...];
function paletteRGB(u){
  u = u - Math.floor(u);
  let i = 0;
  while (i < STOPS.length-2 && u >= STOPS[i+1][0]) i++;
  const a = STOPS[i], b = STOPS[i+1];
  let t = (u - a[0]) / Math.max(1e-6, b[0]-a[0]);
  t = t*t*(3-2*t);
  return [a[1]+(b[1]-a[1])*t, a[2]+(b[2]-a[2])*t, a[3]+(b[3]-a[3])*t];
}
```

LUT size 512 for smoothness.

Write the file.

Also: alpha:false context — putImageData on offscreen with alpha 255 fine; drawImage onto opaque main fine.

Potential issue: ctx.imageSmoothingQuality = 'high'? Set 'low' for preview speed? drawImage of small canvas scaled to1600x900 is a one-time GPU op; fine either way. Use default.

Let me write the code now, then test.

Also note: for stride 1 level, imageSmoothing doesn't matter (1:1). For preview levels smoothing gives blurry upscale — desired.

Time to write.

Also note about `job.chunkRows` adapt: measure per chunk including putImageData + drawImage. Fine.

Now write file.

Let me syntax-check the JS by extracting the script and running node --check, then open in browser.

The initial view renders correctly — full cardioid and lobes visible. The bottom black band suggests the canvas clientHeight vs viewport: canvas is fixed inset 0 with 100% height — the screenshot shows a black band at the bottom ~85px. Hmm, that could be the final render still in progress (status says "rendering…"), or the canvas height mismatch. Actually the black band is uniform dark (#05070f background) — maybe the last full-res level hasn't finished the bottom rows... no, the band is at the bottom, and progressive rendering fills top-down. The bottom band height ~85px suggests rows still rendering. Status said "rendering…". Let me wait and take another screenshot.

Also note the fractal appears shifted: the black region extends to the edges. Wait — the image looks zoomed in more than expected? The view should be real [-2.5,1.0] with center -0.75. In the screenshot, the cardioid occupies the right portion... Actually with INIT_W=3.5 fit and viewport1200x800 (dpr1?), homeScale = max(3.5/1200, 2.5/800) = max(0.002917, 0.003125) = 0.003125 → width span = 1200*0.003125 = 3.75 real range [-2.625, 1.125]. Hmm but the rendered image seems to show the set larger. Let me check: in the screenshot the cardioid spans roughly x from 600 to 990 px, i.e., ~390 px wide. Cardioid width is ~1.0 in real units → scale≈ 1.0/390 = 0.00256. And center of view should be -0.75 at x=600. Cardioid center ~ -0.25 → should appear at 600 + (0.5/0.003125)= 600+160=760px. In the screenshot cardioid spans ~600-990, center ~795. Hmm close-ish. But the left bulb: period-2 bulb centered at -1, radius 0.25 → in screenshot the left bulb spans ~440-600px, center -1 at 600 + (-1+0.75)/0.003125 = 600-80 = 520px. Screenshot bulb center ~520. ✓ Good, the framing matches. The view is dpr=1? dpr capped at 2, browser devicePixelRatio likely 1. Fine.

Wait, but the black band at bottom — the bottom ~85 px. Actually looking more carefully, the whole background around the set is deep blue gradient which fades to darker at the edges — bottom band is uniform very dark, matching background color #05070f of body. This suggests the canvas doesn't extend to the full viewport height: maybe clientHeight = 715 while viewport is 800? Canvas is position:fixed inset:0 with width/height 100% — should fill. Unless the browser viewport is 1200x800 and the canvas CSS height 100% of ... fixed element with inset:0 plus width/height:100% resolves against the ICB, should be 800.

Hmm, maybe the render just hadn't finished bottom rows. Status said "rendering…". Let me reload/wait and screenshot again.

Let me check what's happening.

The render completed — full cardioid and surrounding lobes visible, status "ready". The earlier dark band was just incomplete rendering.

Now verify: zoom into a recognizable boundary point, check it stays near cursor, iteration count increases. Let me use the wheel action at a boundary point, e.g., near the "seahorse valley" between cardioid and bulb around (-0.745, 0.113) or the top of the cardioid. Let me pick a screen point on the boundary, e.g., the cusp between the bulb and cardioid at (-0.75+? ). The point at complex -0.75 (junction) is at screen x = 600 + (-0.75 - (-0.75))/0.003125 = 600, y=400. That's the pinch point between the cardioid and the period-2 bulb — recognizable. Zoom there.

Actually a better recognizable boundary point: the "seahorse valley" at -0.745 + 0.113i → screen x = 600 + (-0.745+0.75)/0.003125 = 600+1.6 = 601.6, y = 400 - 0.113/0.003125 = 400-36 = 364. Hmm that's the valley just left of the cardioid near the top. Fine, zoom at (620, 370).

Let me do multiple wheel events at the same point (browser tool wheel? The browser action list has scroll with delta). Let me use scroll action with delta -600 maybe multiple times. The tool's scroll uses delta param.

Then verify zoom level in status and that the boundary point stays near cursor. Also verify pan drag, and Reset view returning to initial framing.

Let me scroll at (620, 370) with delta -400 several times. Note my code clamps dy to ±400, factor = exp(0.64)=1.9 per event. Each event ~2x zoom.

Let's do 4 scroll actions then screenshot.

Hmm — the scroll went the wrong way: it zoomed OUT (zoom 0.5×), not in. My sign: factor = exp(-dy*0.0016); dy = -400 → factor = exp(0.64) = 1.9 → scale increases → zoom out. Wrong direction! The wheel delta convention: scrolling up gives deltaY negative; to zoom in when scrolling up, we need factor < 1 when dy < 0. So factor should be exp(+dy * k). I had the sign flipped.

Fix: `Math.exp(dy * 0.0016)` so dy negative (scroll up) → factor < 1 → zoom in. Let me check zoom anchoring: it did anchor at cursor (the set moved toward the cursor point — set shifted so that the point at cursor stays; at 0.5x zoom-out, the complex point under cursor620,370 should stay at same screen position. In the screenshot, cursor point (620,370) — hmm, the set moved to the upper-left. Let's verify anchoring math with this zoom-out: originally complex at (620,370): re = -0.75 + (620-600)*0.003125 = -0.6875, im = 0 - (370-400)*0.003125 = +0.09375. After zoom out ×0.5 scale doubles: new scale 0.00625. center: cx = re - (620-600)*0.00625 = -0.6875-0.125 = -0.8125; cy = im + (370-400)*0.00625 = 0.09375 - 0.1875 = -0.09375. Then where does -0.6875+0.09375i appear? x = 600 + (-0.6875+0.8125)/0.00625 = 600+20 = 620 ✓, y = 400 - (0.09375+0.09375)/0.00625 = 400-30 = 370 ✓. Anchoring math correct.

In the screenshot, the set's boundary... at 0.5× (scale 0.00625), the cardioid spans 1.0/0.00625 = 160px wide, center at -0.25 → x = 600 + (-0.25+0.8125)/0.00625 = 600+90 = 690. But screenshot shows the set centered around x~415. Hmm, that suggests something is off!

Wait — the screenshot shows the whole set shifted left and up. Set center around (415, 200)? Expected cardioid at x 690, y: cy=-0.09375, im=0 → y = 400 - (0+0.09375)/0.00625 = 400-15 = 385. But screenshot shows the set near the top-left, roughly centered at (415, 210). That doesn't match the anchored math at all.

Hmm, wait. Maybe the scroll fired more than one wheel event? Status says zoom 0.5×, i.e., single factor. So one event. But the rendered image shows the set positioned differently than expected.

Let me reconsider: is the rendered geometry consistent with cx=-0.8125, cy=-0.09375, scale 0.00625? Real range: 600±? W=1200 (dpr 1). re range = [-0.8125 - 600*0.00625, -0.8125 + 600*0.00625] = [-4.5625, 2.9375]. Cardioid (width 1.0, from -0.75 to 0.25... actually cardioid spans about -0.75 to 0.25? The cardioid real extent: from cusp at 0.25 to -0.75? The main cardioid spans x ∈ [-0.75, 0.25]? Hmm, cardioid spans roughly [-1.4?]. The set spans real [-2, 0.47]. In screenshot the set spans x from ~110 to ~525, width ~415px. Set real width ~2.5 → scale = 2.5/415 = 0.006. OK scale matches 0.00625. Set left edge (x=-2) → screen x = 600 + (-2 + 0.8125)/0.00625 = 600 - 190 = 410. But screenshot set left edge ~110. Set right edge (0.473) → 600 + (0.473+0.8125)/0.00625 = 600+205 = 805. Screenshot ~525.

So the rendered set is shifted left by ~290px and up. That's exactly consistent with a center difference: shift of 290px * 0.00625 = 1.81 in real units... Hmm. Actually wait:290px≈ 0.6 scale factor... hmm what if the dpr is 2 in this browser? If dpr=2, W=2400, H=1600 backing, but CSS canvas is 1200x800. My eventPx multiplies by dpr → px in backing pixels. If dpr were 2, then eventPx at (620,370) → (1240, 740) and W/2 = 1200. Hmm, that would still anchor correctly.

Hmm, but wait: the initial screenshot looked correct in framing: the set centered. With dpr=2, homeScale = max(3.5/2400, 2.5/1600) = max(0.001458, 0.0015625) = 0.0015625. Set real [-2,0.47] → screen backing [1200 + (-2+0.75)/0.0015625, ...] = [1200-800, 1200+0.47+0.75)/0.0015625 → 1200+781] = [400, 1981] backing → CSS [200, 990]. In the initial screenshot the set spans x≈210 to ~980. ✓ consistent with dpr=2 as well (either way).

Let me recompute with dpr=2 for the post-zoom: scale = 0.0015625*2 = 0.003125 (backing px). cx = re - (1240-1200)*0.003125 where re = -0.75 + (1240-1200)*0.0015625 = -0.75+0.0625 = -0.6875. cx = -0.6875 - 0.125 = -0.8125. cy = im + (740-800)*0.003125, im = -(740-800)*0.0015625 = +0.09375. cy = 0.09375 - 0.1875 = -0.09375. Same as before (scale factor 2 in both pixel and scale). Set left edge x=-2 → backing 1200 + (-2+0.8125)/0.003125 = 1200 - 380 = 820 → CSS 410. Same as before. But screenshot shows ~110.

So the image is shifted ~300 CSS px left and ~175 up from expectation. Interesting: shift = (-300, -175)? Let's see what center would produce the screenshot: set left edge (-2) at CSS x110 → backing 220: cx = -2 - (220-1200)*0.003125 = -2 + 3.0625 = 1.0625?? That means cx = 1.0625, cy: set im=0 at CSS y~210 → backing 420: cy = 0 + (420-800)*0.003125 = -1.1875. Hmm, weird values: cx=1.0625, cy=-1.1875.

Hmm wait, maybe I'm misreading the screenshot. Let me look again: the fractal in the second screenshot appears at upper-left, spanning roughly x 100-525, y 20-410. Its vertical extent: full set height ~2.4 units (±1.15)... but the image looks squashed: width 425, height 390. Ratio should be width/height = 2.5/2.4 ≈ 1.04 in complex units → pixel ratio 1.04. Observed 425/390 = 1.09. OK consistent-ish.

So scale = 2.5/425≈ 0.0059 per CSS px ≈ 0.003 per backing px... hold on, if dpr=1: scale 0.0059 ≈ expected 0.00625 ✓. Center: set left edge -2 at x=110 → cx = -2 - (110-600)*0.00625 = -2 + 3.06 = 1.06. cy =0 - (210-400)*0.00625 = +1.19. So center ≈ (1.06, +1.19)?? But expected (-0.81, -0.09).

Hmm interesting: 1.06 = -0.81 + 1.875? and 1.19... Hmm, what if there were TWO wheel events fired (the scroll tool might dispatch multiple)? Two events at factor 1.9 each → 3.61× zoom out; then scale = 0.0113; but status shows zoom 0.5× exactly (mag = homeScale/scale = 0.5). So one event.

Unless... status text is throttled? No, it updates.

Wait, maybe the tool's scroll dispatched a wheel at (620,370) but also scrolled the page? Page can't scroll (overflow hidden, prevented).

Alternatively, maybe my eventPx uses getBoundingClientRect which might include some offset if the page is inside an iframe with the canvas offset? Canvas is fixed inset:0 so rect.left=0, top=0... unless the iframe viewport is larger and the screenshot is scaled. Hmm.

Let me actually debug: instrument the page to log view state and computed complex point under cursor after the wheel. Let me use browser inspect to read internal state? The IIFE hides state. I can add a debug hook: expose window.__view = view for verification. Let me add `window.__mb = {view: view, homeScale: function(){return homeScale;}, W: W, H: H}` — but W/H are captured by closure at creation... use getters.

Actually let me just add a debug exposure and re-test with explicit wheel simulation via the `type`/`click`? There's no wheel action other than scroll. Fine.

Let me add to the script: 
```js
window.__mb = { view: view, get W(){return W;}, get H(){return H;}, get dpr(){return dpr;}, get homeScale(){return homeScale;} };
```
That's harmless to leave in (small debug hook). Then after scroll, inspect window.__mb values and compute expected mapping.

Let me do that.

Wait — zoom direction: mouse wheel deltaY negative when scrolling up (toward user = zoom in conventionally). With dy negative, exp(dy*0.0016) < 1 → scale shrinks → zoom in. Correct now.

Now reload and inspect state before/after a scroll, and compare expected positions.

Reload mid-render. Now let me inspect the internal state to check dpr, W, H, and verify the mapping.

The inspect didn't return the JS evaluation result visibly. Maybe the inspect tool evaluates in the page and returns console output only. Let me instead use console: assign to console.log so it appears in the "console" field.

Console output isn't surfacing. Maybe the inspect tool's `text` isn't executed, or console messages from evaluate aren't captured. Let me instead write state into the DOM (the status element) temporarily... but better: use the tool's inspect with default (no text) which "inspects DOM/console" — earlier it returned dom text. Perhaps the text param evaluates in page context and prints result, but output not shown here? It returned only console warning. Hmm.

Alternative approach for verification: write state into document.title or into the status element via a keyboard shortcut debug? Simpler: since I can't easily read JS state, verify visually — screenshots are reliable enough.

Let me reason about the earlier discrepancy again with fresh eyes, because the second screenshot's set position contradicts my math. Actually wait — maybe the scroll tool's `scroll` action ALSO scrolls the page/iframe by delta, and my preventDefault blocks it — fine. But maybe the tool dispatched wheel events at coordinates relative to the iframe's own coordinate system, which may be offset from the viewport. If the actual wheel position was different, the zoom anchor point differs, explaining the shift. E.g., if the wheel event was at a different position, the image shifts accordingly.

Hmm, but the tool reported coordinates as given (620,370).

Let me test the anchoring precisely by scrolling twice with the corrected sign and visually checking whether the boundary feature under the cursor stays put. If anchoring works, features under (620,370) stay there.

Actually, let me reconsider the previous screenshot once more. Expected for zoom-out anchored at (620,370): the point complex(-0.6875, +0.09375) stays at (620,370). Where is -0.6875+0.09375i? That's in the seahorse valley region between bulb and cardioid, slightly above the real axis, at the boundary. In the initial screenshot, that point is indeed near (620,370) — right at the pinch between the bulb and the cardioid, slightly up.

After the zoom-out, the pinch region should still be at (620,370). In the screenshot, at (620,370)... the set is at upper-left; (620,370) is empty blue background. The pinch point appears at about (320, 215)?? Hmm, so it moved by (-300,-155).

Hmm! What if the scroll tool dispatched the wheel event at page coordinates but my `eventPx` uses getBoundingClientRect of the canvas — inside an iframe, the canvas rect could be offset if the iframe is scrolled or the page has a scrollbar... The page has overflow hidden.

OR: dpr! If the tool's browser reports devicePixelRatio = 1 but screenshots are rendered at some scale... the screenshot is 1200x800 which matches the viewport.

Hmm, wait. What about this: my zoom uses `px` in backing pixels via (clientX - rect.left)*dpr. If dpr = 1, fine. But then the mapping re = cx + (px - W/2)*scale is consistent.

Let me test the alternative hypothesis: the scroll action might send wheel events with deltaMode=1 (lines) with a large deltaY, or it might send multiple events (e.g., 3 events of -400 each?). Status shows zoom 0.5× = exactly one event's factor. Unless multiple events happened but the status updated at the last... no, 3 events → 0.125×.

Hmm, another hypothesis: my `document.addEventListener('wheel', preventDefault)` — irrelevant.

Actually — WAIT. Maybe the scroll action of the harness first scrolls the page natively and dispatches the wheel at those coordinates... The page can't scroll.

Let me look at the third screenshot (after reload): it's identical to the initial one. Good.

Let me do a controlled experiment: dispatch a wheel event programmatically via evaluate and see the state. But evaluate results don't show... Let me test whether evaluate works at all by having it change the status text: `document.getElementById('status').textContent = 'X' + __mb.dpr`. If that shows in the DOM/screenshot, evaluate works.

Let me try: inspect with text that writes into the DOM.

The DOM text still shows the original status — so the `inspect` text parameter is apparently not evaluated as JS in the page (or it is but the render loop's updateStatus overwrote it — updateStatus only writes when text changes, and it computes 'Iterations...' — it would overwrite since s !== lastStatus? lastStatus equals current s, so it wouldn't overwrite. Hmm, so likely evaluate isn't running, or it runs in a different context).

The tool docs: "Run index.html, inspect DOM/console..." — the inspect action takes `text` perhaps as a filter for DOM inspection rather than JS eval. So no JS evaluation available.

OK, so I'll verify behavior purely visually. The key question earlier: after one wheel zoom-out, the set appeared shifted left/up more than expected. Let me redo that test now with corrected direction and carefully compare positions. But first, is it possible that the earlier mismatch was because the wheel event in that harness used clientX/clientY in the iframe but dispatched at a different point? Let me test with a scroll and observe.

Actually, let me reconsider: maybe the harness `scroll` action scrolls the *page* (window.scrollBy) at those coordinates, and the wheel events delivered have clientX/clientY = (0,0) or similar... If clientX/Y were 0,0 the anchor would be top-left, causing the set to shift right-down on zoom-out, not left-up. On zoom-in (corrected sign), anchor at top-left would shift the set right-down.

Hmm, in the observed zoom-out at "cursor": set moved left and up. For zoom-out anchored at some point P, points move away from P. The set moved away from... set center moved from (795,400) to (415,210) — moving away from a point to the lower-right of the set center. Anchor P satisfies: pos' = P + 2*(pos - P) → P = pos' - 2*(pos - pos')... For the set center: (415,210) = P + 2*((795,400) - P) → P = 2*(795,400) - (415,210)*... let me solve: p' = P + k(p - P) with k=2 → P = (p' - k p)/(1-k) = ((415,210) - 2*(795,400))/(-1) = (2*(795,400) - (415,210)) = (1175, 590). So the effective anchor was (1175, 590), not (620,370). Hmm, interesting — that's like the cursor plus (555, 220)?

Hmm, what if the scroll happened twice: first at (620,370) factor 1.9 (correct anchoring), then a second wheel event with different coordinates? Two events → zoom 0.361× not 0.5×. So no.

What if the wheel event delivered deltaY = -400 but ALSO the tool scrolled the container causing the canvas rect to shift? No.

Alternative: what if dpr=2 in the browser, but the tool's coordinate system for the wheel is CSS pixels (as I assumed), and my code multiplies by dpr=2 → px = (620-0)*2 = 1240 backing, W=2400 → (1240 - 1200) = 40 backing px offset. Consistent math → anchor correct. Unless clientWidth isn't 1200. If the iframe viewport were 1200x800 CSS and canvas clientWidth = 1200 → W = 2400 with dpr 2. That's what I assumed. Consistent.

Hmm, so why the discrepancy? Let me reexamine the post-zoom screenshot once more. Actually let me re-measure the set in the second screenshot: black region spans x from ~320 to ~520 for the cardioid... Actually I described "set spans x 100-525". Let me look again at the image: the set (black blob + bulb) is in the upper-left quadrant: the bulb at ~x=270, cardioid ~x=330-520, tail extending left to ~100. Overall spans x∈[100,525], y∈[25,410].

Center of mass ≈ (315, 215)? I earlier estimated (415,210) for cardioid center; let me use whole set: from -2 (left tail tip at x=-2) to +0.47 (right edge) → 2.47 units over 425 px → 0.00581 px/unit... i.e., 172 px per unit... scale≈ 0.00581 (close to expected 0.00625, within measurement error). Left edge (-2) at x=100 → cx = -2 - (100-600)*0.00581 = -2 + 2.90 = 0.90. Vertical: set spans im ±1.15 → 2.3 units * 0.00581 = 13.4 px/unit → 310px tall; observed ~385. eh, measurement is rough. im=0 (real axis) at y: the set is symmetric about the real axis; observed y center ≈ (25+410)/2 = 217 → cy = -(217-400)*0.00581 = +1.06.

So the effective center ≈ (0.9, +1.06) — this looks like cx,cy got shifted by (+1.7, +1.15) relative to expected (-0.81,-0.09). Weird, non-round numbers.

Hmm, what if the wheel event's clientX/clientY were relative to the *iframe document* while the tool thinks in outer viewport coords, and the iframe is offset/scaled? Then eventPx would compute a different anchor — e.g., if clientX/clientY were something like (0,0)... anchor top-left (0,0): on zoom-out ×1.9? no, factor 1.9: p' = P + k(p-P) with k = 1.9? Let's compute with anchor (0,0), k=1.9: set center (795,400) → (1510, 760) — moves right/down. Not matching.

Anchor at (1175,590) as computed... = 1200 - 25 and 800 - 210. Hmm, (1175,590) ≈ mirrored-ish of (25,210)? The tool's coordinate system might be a scaled-down iframe: e.g., iframe is 1200x800 CSS but the actual page rendered at a different size and screenshot upscaled. If the real viewport were, say, 1500x1000 and the screenshot scaled to 1200x800 (0.8 scale), then a click at screenshot (620,370) would be at real (775, 462). Anchor (775,462) with k=1.9: p' = P + 1.9(p-P) → for set center (795,400)*? in real coords it'd be (994, 500)... this is getting messy.

Let me instead test anchoring in a scale-independent way: zoom in toward a distinctive feature and check whether that feature remains under the cursor in *screenshot* coordinates. If the harness coordinates map affinely (scale+translate) between tool coords and screenshot coords, the anchor will appear off in the screenshot even though the code is right.

Given uncertainty, the robust verification: zoom in and confirm the same feature stays under roughly the same screenshot position across successive zooms with the cursor at the same tool coordinate. If there's a fixed affine offset between tool coords and screenshot coords, the anchor point will be consistent within the screenshot space... Actually yes: if tool coord T maps to screenshot coord S = aT + b, and I always scroll at tool (620,370), the anchor in screenshot space is fixed at S0 = a*(620,370)+b. Successive zooms keep features at S0 fixed. So I can verify anchoring by checking that the feature under S0 stays at S0 across multiple zoom steps.

Earlier data point: initial view, feature at tool (620,370): the pinch between bulb and cardioid. After the zoom-out, that feature should be at the same screenshot position. In screenshot 2, at (620,370) there was nothing. So anchoring appears broken regardless of coordinate scaling... unless the tool's scroll coordinates are simply not delivered as clientX/clientY.

Hmm! That's plausible: some CDP-based scroll implementations use Input.dispatchMouseEvent with type mouseWheel at given x,y — clientX/clientY would be right. But maybe the harness scrolls via a different mechanism.

Wait — maybe the harness dispatched the wheel event but ALSO performed a real scroll gesture, and since I preventDefault, the wheel's clientX/clientY might be 0. Anchor (0,0) doesn't match the observed direction though. Let me compute what happens with anchor exactly at canvas center (600,400) with k=1.9 (zoom out): the set would grow and stay centered — set center stays at (600,400)... observed set center moved up-left. Not that either.

Alternatively the observed image might be explained by TWO zoom-out events plus something? k = 1.9² = 3.61: set center (795,400) with anchor (620,370): p' = (620,370) + 3.61*((795,400)-(620,370)) = (620 + 632, 370 + 108) = (1252, 478). Off-screen right. No.

Hmm, what about zoom IN events with k = 1/1.9 = 0.526 anchored at (620,370)? Set center (795,400) → (620,370) + 0.526*(175,30) = (712, 386). The set would shrink toward the cursor and be centered right-ish. Observed set is smaller and at upper-left. Not matching.

What if the anchor was around (300, 100)? p' = P + 1.9*(p-P) = (300,100) + 1.9*(495,300) = (1240, 670). No.

Let me solve for k too. Using two features: set center initial (795,400) → final (315,215); set left tip (-2): initial x = 600 + (-2+0.75)/0.003125 = 600-400 = 200, y=400 → final (100, ~215?). Since it's on the real axis, its final y = cy - (0-cy_final)... hmm.

Using scale ratio k = 0.00581/0.003125 = 1.86 ≈ 1.9 ✓ single event.

Two reference points: left tip: initial (200,400) → final (100,215)?? but the real axis maps to y_final = 400 + (cy_final - 0)/scale... The real axis (im=0) is at y = 400 - (0 - cy)/scale. If cy_final = +1.06 and scale 0.00581 → y = 400 + 182 = 582?? That contradicts the set being in the upper half (y 25-410) symmetric about y≈217.

Hold on. If the set (symmetric about the real axis) appears spanning y 25..410, the real axis is at y ≈ 217, meaning cy_final = (400-217)*0.00581 = +1.06 (positive = imaginary up ✓ since real axis is above center).

Anchor equation for y: 217 = P_y + 1.9*(400 - P_y) → 217 = 1.9*400 - 0.9*P_y → 0.9*P_y = 760-217 = 543 → P_y = 603.
For x: real-axis left tip (-2) initial x = 600 + (-2+0.75)*0.003125^-1... careful: x = 600 + (re - cx)/scale = 600 + (-2+0.75)/0.003125 = 600 - 400 = 200. Final x = 600 + (-2 - cx_final)/0.00581. With cx_final ≈ 0.9 → 600 + (-2.9)/0.00581 = 600 - 499 = 101 ✓ (matches ~100).
Anchor: 101 = P_x + 1.9*(200 - P_x) → 101 = 380 - 0.9 P_x → P_x = 310.

So effective anchor ≈ (310, 603). I dispatched at (620,370). Hmm, (310, 603)... that's not a simple transform of (620,370) (like mirrored about center (600,400) → (580,430)). Hmm,600-310 = 290; 620-600 = 20. Not a mirror.

Hmm, maybe my measurements are too rough. Let me redo this experiment more carefully with the corrected zoom-in direction: scroll in several steps at a fixed point and see whether the feature under the cursor stays put.

Actually — an important realization: maybe the scroll tool dispatches wheel with clientX/clientY, but ALSO the page zoom... let me just test empirically now. Do3 zoom-in scrolls at (620,370) and screenshot; if anchoring is right, the valley feature at the cursor stays there and detail deepens.

Let me first let the current page finish rendering (it's ready) then scroll.

Zoom direction now correct (zoom 1.6×, iterations increased to 181 ✓). But anchoring looks off: the view moved right/down relative to cursor — the set shifted right/down, i.e., the feature that was at (620,370) (the valley pinch) is now at ~(975, 520)? The pinch between the bulb and cardioid is now at about (975, 525).

Hmm. So the tool coordinate → page coordinate mapping appears offset. The shift is consistent with the harness delivering the wheel event at a different position than the tool coordinate, OR my eventPx being wrong.

Wait — maybe the browser viewport for the tool is 1200x800 but the *page* is inside an iframe that is smaller/offset? The screenshot shows the full page (panel top-left aligned with the screenshot corner), so the page occupies the whole screenshot. So rect.left=0, top=0, clientWidth=1200, clientHeight=800.

So if the wheel event had clientX=620, clientY=370 and dpr=1, anchor is exactly (620,370). The observed shift says the anchor was elsewhere. Let me compute the effective anchor for this zoom: k = 1/1.6 = 0.625 scale factor (new scale = 0.625 old). p' = P + 0.625 (p - P). Feature "valley pinch" initial at (620,370) → final observed ~(975,525).

Solve: 975 = P + 0.625(620 - P) → 975 = 0.625*620 + 0.375 P → 975 = 387.5 + 0.375P → P = 1566?? That's outside the viewport. Something's clearly wrong with my feature reading.

Hmm wait. Maybe I misidentify the feature. Let me think again about what the initial view looks like at (620,370): complex re = -0.75 + 20*0.003125 = -0.6875; im = -(370-400)*0.003125 = +0.09375. That point: is it on the boundary? -0.6875+0.09375i — hmm, that's just to the right of the bulb/card... The period-2 bulb is centered at -1 with radius 0.25, so it spans [-1.25,-0.75]. -0.6875 is to the right of -0.75, i.e., inside the main cardioid? The cardioid boundary near the cusp (-0.75 is the cusp where the bulb touches the cardioid). At im=0.09375, the cardioid boundary real part≈ -0.75 + O(y²)... The cardioid near cusp: c = -0.75 + small. Actually the cardioid cusp is at -0.75 exactly. At im = 0.09375, the cardioid's left boundary is around re ≈ -0.735? So -0.6875+0.09375i is INSIDE the cardioid. Hmm — that means the cursor was on an interior point. Zooming in on an interior point means the view fills with black and the set's boundary moves off toward the edge.

Wait but in the zoomed screenshot, the black region is at the right/bottom. The cursor (620,370) should still be an interior (black) point. Looking at the screenshot at (620,370): it's blue background, not black! The black region near the cursor: the bulb edge is at ~(700,640). So (620,370) is background — outside the set. That means the anchoring is definitely wrong... OR the anchor math shifted the view so that the point moved out.

Hmm, hold on. Let me reconsider: is the pinch/bulb boundary really at (975,520) in the new image? The image shows: bulb (small black circle) centered ~(680,650) with radius ~50; the big cardioid black region on the right (from x~970 to beyond 1200), and the "seahorse valley" pinch between bulb and cardioid at about (975, 520)? Hmm, actually the pinch point is where the bulb touches the cardioid along the real axis: y should be at the real axis (the line of symmetry of both shapes). The bulb center is (680,650), and the cardioid's leftmost point on the real axis... The real axis here: both shapes are symmetric about it → real axis at y≈650. The pinch (cusp at -0.75) would be at y=650, x = boundary between bulb and cardioid ≈ (960,650).

The initial view's real axis was y=400 (cy=0). The zoom-in anchor at (620,370) with the real axis: the real axis (im=0) is at screen y = 400. After zooming by k=0.625 anchored at (620,370): real axis maps to 370 + 0.625*(400-370) = 388.75. But observed real axis is at y≈650. Huge mismatch.

Alternatively the observed image suggests the anchor was below-left. Solve P from real axis: 650 = P + 0.625(400 - P) → 650 = 250 + 0.375P → P = 1066 (y). And x from the cusp (-0.75): initial screen x = 600 + (-0.75+0.75)/0.003125 = 600. Final: cusp at x≈ 960: 960 = P + 0.625(600-P) → 960 = 375 + 0.375P → P = 1560 (x).

Anchor≈ (1560, 1066)?? That's way outside the viewport, and interestingly≈ (1.3*1200, 1.33*800). Hmm, and for the earlier zoom-out: anchor≈ (310,603) with k=1.9: let me double check with the new hypothesis. Hmm, if the actual anchor used by my code were (clientX, clientY) values larger than my assumed coords... e.g., if dpr=1 but the harness sends clientX in *device* pixels of a larger screen?

What if the harness's browser viewport is actually larger than 1200x800 — say the page is 1200x800 CSS but... the screenshot is 1200x800.

Hmm, what if dpr = 2 in this browser?! Then clientWidth = 1200, W = 2400, scale = 0.0015625 (backing). My eventPx: px = 620*2 = 1240; anchor in backing px (1240,740) = CSS (620,370). That's still the same point. So dpr doesn't matter.

Unless... the wheel event coordinates delivered by the harness are in the OUTER page coordinates but the iframe is offset within it. The iframe might be positioned below some toolbar, e.g., the iframe starts at y=100 in a 1200x900 outer window with height 800. Then a tool coordinate (620,370) in outer coords → in-page clientY = 270. Then the harness scrolls at outer (620,370) → my code receives clientY=270 → anchor at page (620,270) — above my assumed point. That would move content UP when zooming in, not down. Observed: content moved down/right (features below-right of cursor). That corresponds to an anchor BELOW/RIGHT of the cursor... i.e., page coords larger than assumed. So maybe the harness's outer window is bigger and the iframe is placed at an offset (e.g., iframe at (x=340,y=300) within a 2000x1300 window?). Then tool coords are outer → in-page coords = outer - offset → smaller. That moves anchor up-left. Content then moves down-right relative to cursor. YES — that matches the observed direction!

So: anchor in-page = tool coords minus offset. The features move away from the in-page anchor point, appearing to move down-right relative to the tool cursor position.

Let me estimate the offset from this zoom: effective in-page anchor P≈ (1560,1066)?? That's beyond1200x800 — impossible for in-page coords. So my measurement must be way off, or k isn't 0.625.

Hmm, k = homeScale/scale ratio change = 1.6 zoom in → new scale = old/1.6 = 0.625*old ✓.

Let me redo the measurement more carefully using the latest screenshot. Features visible: the "tail" (antenna) along the real axis extends left from the bulb; mini-brot at the tail tip at ~(445,645). The antenna lies on the real axis → real axis at y ≈ 645-650. ✓ symmetric: the bulb's filaments above/below are symmetric about y≈648.

Initial view: real axis y=400 (cy=0 at dpr=1... assuming). Cusp at (-0.75,0) at x=600.

After zoom-in k=0.625 anchored at P: real axis → P_y + 0.625(400-P_y) = 0.375 P_y + 250 = 648 → P_y = 1061.

Alternatively, what if dpr=2 and cy=0 maps to a different initial y? No: cy=0 is always at canvas center y=H/2 in backing px = CSS center = 400 CSS. So real axis initial y=400 CSS. OK.

So P_y ≈ 1061 CSS px — outside the 800px viewport. That means the in-page wheel clientY ≈ 1061?? Impossible... unless the page/iframe was actually *scrolled* by the wheel (my preventDefault should stop that) or the canvas rect.top is not 0.

OR the harness's scroll changed the iframe's scroll position: if the outer container scrolled... the page can't scroll.

Hmm, alternatively — maybe the wheel event triggered TWO of my handlers? No.

Wait... maybe the harness dispatches a wheel with a huge deltaY (like -1000) and my clamp to ±400 gives -400 → k=0.625 ✓ consistent with status 1.6×. Fine.

Let me consider: what if the harness's scroll action also moves the mouse/camera, no...

Let me test the hypothesis differently: perform a drag-pan test. If the drag coordinates map correctly (the drag is entirely internal to the canvas — panning by deltas, so offsets cancel!), panning will look correct regardless of coordinate offsets. That would confirm my code is fine and the wheel anchor discrepancy is a harness coordinate artifact.

But the task says to verify "zoom into a recognizable boundary point and check that it stays near the cursor". If the harness's wheel coordinates are off, I can still verify anchoring by choosing a distinctive boundary feature and computing where the harness thinks the cursor is... Simpler: verify anchoring mathematically via a different route — I can add temporary instrumentation that records the anchor point used and writes it into the status bar (DOM visible in screenshot). That's fully reliable!

Plan: add a temporary debug display: on each zoom, set a `lastAnchor = {re, im, px, py}` and render it in the status line. Then screenshot shows exact page coords of the anchor and the complex point. Then I can check visually whether that complex point stays at that screen position after the zoom. That's a rigorous verification independent of coordinate-mapping confusion.

Let me implement: in zoomAt, record `window.__anchor = {px, py, re, im}` before updating. And append to status: "anchor px=(x,y)". Since updateStatus builds the string, I'll include anchor info if present.

Let me do it.

I need to hurry. Let me reload, verify the anchor display, do a zoom test + pan + reset, then finalize quickly.

Important consideration: the "anchor" debug text is temporary; I should remove it before finishing (or keep it minimal). Given time constraints, I'll verify quickly and then strip the debug hook.

Let me reload and scroll once at a boundary point.

Now zoom at a clearly recognizable boundary point: the cusp/pinch between bulb and cardioid at real axis y=400, x=600 (complex -0.75). Let's scroll at (600,400) with delta -300. Then check the anchor debug text and whether the pinch stays at (600,400).

Wait for render to finish first — it's rendering. Scroll anyway (it cancels).

Confirmed: the harness delivers wheel events with clientX=0, clientY=0 (anchor css(0,0), complex -2.625+1.25i = top-left corner). So the tool's scroll coordinates are NOT passed through as clientX/clientY — they come as (0,0). My anchoring math is correct; the harness just doesn't provide cursor coordinates for wheel events.

So my earlier observations are fully explained: the anchor was always the top-left corner (0,0), consistent with the observed shift patterns (features moving away from top-left).

Verification of "zoom stays near cursor": I can verify the anchoring logic using double-click (which uses the dblclick event's clientX/clientY — the harness `click` action provides real coordinates) — dblclick zooms in ×2 anchored at the click point. Let me use the click action (clicks may not produce dblclick; but I could add a keyboard-free approach).

Better: verify via keyboard-free deterministic check. Options:
1. Use the harness `click` twice quickly at the same point to trigger dblclick → zoom anchored at that point. The click tool provides coordinates and dispatches proper mouse events with clientX/clientY. If a dblclick fires, my handler anchors at that point.
2. Also pan via drag (`drag` tool) — deltas are internal, so coordinates don't matter; pan should work.

Let me try click at a boundary point (e.g., the cusp at (600,400)) twice — the harness click may dispatch mousedown/up; a real double-click needs two clicks in quick succession, which the tool likely does separately (timing may exceed dblclick threshold... typically ~500ms; tool calls are ~1s apart). Risky.

Alternative: temporarily add a key handler? Keyboard works via `key` tool (the keydown handler I have is real). I could add a temporary "z" key that zooms in at the center of the screen, but that doesn't test cursor anchoring.

Better approach for rigorous verification without harness coordinates: temporarily instrument a self-test in the page — after load, programmatically call zoomAt at a known pixel (simulating a cursor at CSS620,370) with a synthetic dispatch: I can dispatch a synthetic WheelEvent with clientX/clientY via a temporary setTimeout in the page code... but I can't run JS. However, I CAN put the self-test directly in index.html temporarily: e.g., a temporary snippet that on load dispatches a synthetic wheel event at (620,370) via canvas.dispatchEvent(new WheelEvent('wheel', {clientX:620, clientY:370, deltaY:-300, cancelable:true})). Then screenshot shows the anchored result and the anchor debug text. That verifies my handler + math with real coordinates.

Given the 5-minute warning, plan:
1. Add temporary self-test: after resize(), dispatch synthetic wheel at (620,370) after ~600ms.
2. Reload, screenshot: verify the feature under (620,370) stays there and anchor text shows css(620,370).
3. Then test pan drag with the drag tool, then Reset view button click, screenshot compare with initial.
4. Remove debug/self-test code, final reload, done.

That's a lot for 5 minutes. Let me prioritize: the self-test is the key verification (anchoring). Pan/reset are quick with drag tool + click on the Reset button.

Actually I can combine: keep the self-test, and afterwards do drag + reset via tools. Then strip debug.

Let me write the temp self-test quickly.

The synthetic wheel uses deltaY=-300 → zoom in 1.6× anchored at (620,370). In the initial view, the point at (620,370) is the boundary filaments just right of the cusp (the "seahorse valley" area between bulb and cardioid, slightly above the real axis). After the zoom, that same detail should be at (620,370),1.6× bigger.

Reload and screenshot.

The screenshot was taken before the 800ms self-test fired (zoom still 1.0×, mid-render). Let me wait ~1.5s and screenshot again.

Anchoring verified: the view zoomed 1.6× with anchor at css(620,370) = complex (-0.6875, +0.09375i), which is the pinch/seahorse-valley region right at the cursor — and indeed the pinch region between bulb and cardioid remains at (620,370) in the screenshot (the gap between bulb and cardioid is at ~(590-600, 415)... hmm, let me check: the pinch (cusp -0.75,0) after this zoom: x = 600 + (-0.75 - cx)/scale. New scale = 0.003125/1.625? Let's compute: zoom 1.6 → scale 0.003125/1.6 = 0.0019531. cx = re - (620-600)*scale = -0.6875 - 20*0.0019531 = -0.7265625. cy = im + (370-400)*scale = 0.09375 - 30*0.0019531 = 0.0351563. Cusp (-0.75,0) → x = 600 + (-0.75+0.7265625)/0.0019531 = 600 - 12 = 588; y = 400 - (0-0.0351563)/0.0019531 = 400 + 18 = 418. In the screenshot, the pinch between bulb and cardioid is at ~(590, 418) ✓. And the anchor point (620,370) — just right/above the cusp, on the boundary filaments — visually, at (620,370) we're at the top edge of the valley region, matching the pre-zoom feature scaled about the anchor. The zoom clearly magnified about (620,370): the features at that point stayed put while everything expanded 1.6×.

Iterations rose110 → 181 ✓ (more detail). New detail visible ✓.

Now: pan test with drag tool, then Reset view click and compare with initial framing. Then remove debug code.

Let me drag from (800,400) to (600,300) — pan by (-200,-100) → content moves left/up... Let's do the drag.

Pan works: dragging from (800,400) to (600,300) moved content by (-200,-100) px: the cusp moved from (588,418) to (388,318) ✓ and the view was fully recomputed at the new center (crisp, iterations still 181).

Now click "Reset view" (at ~(75,115)) and compare with the initial framing.

Reset view works — back to zoom 1.0×, iterations 110, and the framing matches the initial screenshot (mid-render at this moment, bottom band still filling). Now remove the debug code (anchor display, __mb hook, self-test) and do a final reload + screenshot.

The debug hook + self-test block order: I added the self-test right after resize(); and the __mb hook was after resize() too. Let me read the tail of the file.

The first two edits in my previous call — did they apply? The tool reported failure for edits[2] and said "Could not find edits[2]" — the edit tool applies all-or-nothing? It said "Could not find edits[2] in file", so likely nothing was applied. Let me verify by grepping for lastAnchor.