Mandelbrot explorer · mimo-v2.6-flash

Let me build the app. Single file index.html, full-screen canvas, Mandelbrot renderer with smooth escape time, pan, wheel zoom centered on cursor, reset, iterative progressive rendering to keep controls responsive.

Plan: use Canvas 2D with ImageData rendering, progressive: render at low resolution / fewer iterations first, then refine in chunks via requestAnimationFrame or setTimeout, canceling on interaction. Use Web Worker? Can't easily inline worker without blob — actually blob workers work offline. But keep simpler: chunked rendering on main thread with row-by-row processing per frame with time budget (~12ms per frame). That keeps controls responsive.

Implementation details:
- View: center (cx, cy), scale (width in complex units per pixel or per canvas width). Initial: full Mandelbrot roughly x from -2.5 to 1.0, y from -1.25 to 1.25. Compute based on canvas aspect: fit width 3.5 complex units, centered at (-0.75, 0). Use scale = complexUnitsPerPixel.
- Pan: pointer drag, update center by delta * scale.
- Wheel: zoom factor exp(-deltaY*k), new scale, keep point under cursor fixed: complexPoint p = center + (mouse - canvasCenter)*scale (with y flipped). After zoom, center = p - (mouse - canvasCenter)*newScale.
- Iterations: base 128, increase with zoom: iter = clamp(128 + 100*log2(initialScale/scale), 128, 2000) maybe.
- Smooth coloring: nu = i + 1 - log2(log2(|z|))... standard: sn = i + 1 - log(log(|z|))/log(2). Use palette function with cosine gradient or custom hues.
- Inside: distinct color (e.g., dark/black or deep navy).
- Progressive render: render at full res but process in tiles/rows with time budget; first pass quickly at 1/4 resolution scaled up (imageSmoothing) to show something fast, then full res pass progressively top-to-bottom. Cancel any pending work on new interaction.

Also "Prevent wheel navigation from scrolling the surrounding page" — page has no scroll (full-screen fixed), but add wheel listener with passive:false preventDefault.

Controls: Reset view button, maybe iteration info, zoom level display. Keep responsive.

Let me write the code.

Rendering approach details:

State: view = {cx, cy, scale} scale = complex units per CSS pixel.

render pipeline:
- token counter; each interaction increments token, cancels pending jobs.
- job: {token, iter, width, height, imageData, y cursor}
- Fast preview: render at half or quarter resolution into an offscreen ImageData, draw scaled to canvas (with smoothing). Then full res progressive: draw rows into ImageData, putImageData progressively... putImageData full each chunk is costly but fine; better: keep full ImageData, fill rows, and after each chunk putImageData(rect) of the updated region only. putImageData with dirty rect works.

Actually drawing preview: create small canvas, putImageData, then drawImage scaled onto main. Then progressive full-res overwrites via putImageData rows.

Time budget per frame: process rows until 10ms elapsed.

Iteration count: adaptive.

Colors: palette — use a smooth function: 
color(t): hue based, e.g., base palette:
inside: rgb(8,8,16) or a distinct deep color.
For outside: t = smooth value normalized: use s = sqrt? Common: v = 0.5 + 0.5*cos( ... ). Let's do: m = Math.pow(Math.log(1+nu)/..., ...). Simpler: map s = (nu mod something). Use:

function palette(t) where t in [0,1): 
  use cosine palette: r = 0.5+0.5*cos(6.283*(t) + 0.0) etc. Let's craft nice: 
  r = 0.5 + 0.5*Math.cos(6.28318*(t*1.0 + 0.00))
  g = 0.5 + 0.5*Math.cos(6.28318*(t*1.0 + 0.10))
  b = 0.5 + 0.5*Math.cos(6.28318*(t*1.0 + 0.20))
Plus t computed as nu scaled: t = nu / 512 maybe with rotation so it cycles. Better classic: t = 0.5 + 0.5*cos(3.0 + nu*0.15) but we want smooth gradient across zoom levels. I'll use:

s = Math.sqrt(nu) * 0.09 or log-based: t = (Math.log(nu+1)/Math.log(maxIter+1)) gives bands compressed. Common approach: t = nu * 0.035 for a fixed cycle length in iterations — but as iterations grow with zoom it still cycles fine. Hmm, with smooth escape values up to maxIter, using fixed cycle (nu*c mod 1) gives repeating gradient bands — that's the classic look. I'll combine: t = frac(nu * 0.06 + phase) using cosine palette. That gives smooth repeating gradient, distinct inside color. Good.

Maybe better: also tie to maxIter so deep zooms don't become ultra-fine bands: fixed cycle is fine and recognizable.

Let's implement palette with a few stops for nicer look: use a hand-crafted cyclic gradient via cosine palette with coefficients:
r = 0.5 + 0.5*cos(2π(t) + 2.0)
g = 0.5 + 0.5*cos(2π(t) + 2.6)... I'll just pick pleasing ones and check screenshot.

Actually a classic nice one: 
r = 9*(1-t)*t^3 ... that's a fire gradient (t→0 black, peak red). Let's use cyclic: 

t01 = (0.5 + 0.5*Math.cos(TWO_PI * (nu*0.045 + 0.0)))... colors: use three phases.

I'll define palette as cosine with phases (0.0, 0.10, 0.20) plus a slight brightness weighting. Check visually later.

Also add a subtle "distance-based" nothing — keep simple.

Max iteration: iters = Math.min(1500, Math.round(120 + 80 * Math.max(0, Math.log2(initialScale/scale))))? At scale deep zoom, log2 grows e.g., 40 → 120+3200 too much; clamp 1500. Use base 150 for initial? Initial full view: 150 iterations is plenty but costs time on full res... chunked so fine.

Let's compute: initial scale = 3.5/width ≈ 0.003 for 1200px. log2(initial/initial)=0 → iter = 150. After zoom to 1e-6 (22 doublings... actually scale ratio 3.5/1e-6=3.5e6, log2≈21.7) → 150+40*21.7 ≈ 1018. Cap 2000. Good enough for recognizable detail at moderate zoom; deep zoom beyond that gets blurry but acceptable.

Progressive refinement also with iterations? Keep it simple: fixed iter per render job.

Also show status overlay: zoom level, iterations, rendering indicator.

Pointer: pointerdown/move/up with setPointerCapture, cursor grab.

Touch: pointer events handle touch pan; pinch zoom optional — add basic two-pointer pinch? Nice-to-have; add simple pinch with pointer map. Keep moderate — I'll add pinch since pointer events make it easy-ish. Maybe skip to save time; requirement is mouse pan and wheel. I'll add lightweight pinch support since cheap.

Let me write code.

Structure:

```html
<!doctype html>
<html>
<head><meta charset>... <style>...</style></head>
<body>
<canvas id="c"></canvas>
<div id="hud">... buttons ...</div>
<script>...</script>
</body>
```

CSS: full screen, no scroll (overflow hidden), canvas fixed inset 0, HUD top-left with reset button, bottom-left status.

JS key parts:

```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d');
let dpr = Math.min(window.devicePixelRatio||1, 2);
let W,H; // CSS px
function resize(){ ... set canvas.width = W*dpr ... recompute view to fit? On resize keep center+scale (complex scale per CSS px). Simpler: keep scale fixed; maybe re-fit? Keep same scale.
```

Initial view: fit: scale = Math.max(3.5/W, 2.6/H)?? Mandelbrot spans x [-2.5,1], y [-1.25,1.25]. To show complete: need width ≥3.5 and height≥2.5 complex units. scale = max(3.6/W, 2.6/H). center = (-0.75, 0).

render pipeline:

```js
let renderToken = 0, job = null;
function requestRender(){ renderToken++; job=null; schedule... }
```

Do: on each frame (rAF loop or setTimeout), if dirty → start new job (preview + full). Implementation:

```js
let pending = false;
function invalidate(){ pending = true; }
function frame(){
  if(pending){ pending=false; startJob(); }
  if(job) stepJob();
  requestAnimationFrame(frame);
}
```

startJob: compute iter, create full ImageData (Uint8ClampedArray W*dpr? render at device pixels? To keep perf, render at CSS resolution? Better render at device pixels but for large screens costly. I'll render at min(dpr,2) device pixels? Full HD*dpr2 = 4M pixels × 1000 iters worst case... heavy but chunked. Cap render scale: renderScale = Math.min(dpr, 1.5) maybe. Let's use device pixels capped at dpr 2 but chunk with 10ms budget — fine, progressive anyway.

Preview: render at 1/4 scale (W/4 × H/4) fast (low iter? use same iter but few pixels — cheap), drawImage upscaled. Then full-res rows progressively.

Actually preview at quarter res with full iterations: W/4*H/4 = 1200*800/16=60k pixels × 150 iter avg... points outside escape fast, points inside cost full. 60k*150=9M ops, ~20-50ms — acceptable one-time. Could also chunk preview. I'll chunk preview too within same job structure: phase 1 preview rows, phase 2 full rows.

Job structure:
```js
job = { iter, w, h, rw, rh (render pixels), full: ImageData, preview: ImageData small, phase, y }
```
Where rw = canvas.width (device px). Render directly in device pixels.

Steps: 
- phase 0: fill preview rows y in [0,rh), after done, put preview scaled: ctx.drawImage(previewCanvas,0,0,W,H) — need previewCanvas with putImageData.
- phase 1: fill full rows; each step putImageData(fullCanvas?, ...) — we can't putImageData partial from ImageData directly? putImageData(imgData, dx,dy, dirtyX,dirtyY,dirtyW,dirtyH) — yes supports dirty rect. So ctx.putImageData(full, 0,0, 0, lastY, rw, dy).

But drawing preview first, then putImageData rows overwrites region — good.

putImageData ignores transforms — fine, ImageData is device px matching canvas.

Progress: track progress bar in HUD.

smooth iteration:

```js
function mandel(cx0, cy0, maxIter){
  let x=0,y=0,x2=0,y2=0,i=0;
  while(i<maxIter && x2+y2<=256... use 4? escape radius 2 → bailout 4 for squared. Use bailout 16 for smoother? standard escape |z|>2 → x2+y2>4. Smooth: nu = i + 1 - Math.log(Math.log(sqrt(x2+y2)))/Math.LN2.
```
With bailout 4 (|z|>2), smooth formula uses log2(log(|z|)). Slight artifacts if bailout too small; use bailout |z|²>256 (radius 16) for better smoothness: nu = i + 1 - log(log(|z|)/log(bailout))/log(2)? The general formula: nu = i + 1 - log2(log|z| / log R)?? Actually for escape radius R: nu = n + 1 - log(log|z|)/log(2)... Let's just use R=2 with the standard formula; it's fine visually (small banding possible). I'll use bailout 65536? Cost: extra iterations negligible (few). Let's use r2 bailout = 1<<12? With large bailout the smooth formula: mu = n + 1 - log2(log(|z|)) is valid asymptotically; for larger bailout it's actually more accurate. Use bailout |z|²> 2^16 (|z|>256): log2(log(256))=log2(5.545)=2.47 — fine, formula still works since the smooth iteration count formula: mu = n - log2(log|z|) + constant... The standard derivation: after escaping, treat continuous escape: mu = n + 1 - log(log|z|)/log 2. This assumes each iteration multiplies the magnitude by roughly... it's an approximation valid for any moderate bailout. Use bailout 4 for simplicity with the classic formula: nu = i + 1 - Math.log(Math.log(mod))/Math.LN2 where mod = sqrt(x2+y2). Works, standard in many demos.

Hmm banding: I'll use bailout 1024 and formula nu = i + 1 - Math.log(Math.log(r)/Math.LN2... let's not overthink; classic version is widely used and looks smooth.

I'll use: escape if x2+y2 > 4096 (r=64). smooth: nu = i + 1 - log(log(r)/log(64))/log(2)? Hmm incorrect derivation. Derivation: continuous escape count mu = n - log2(log(r)/log(R))? For the map, near escape z grows like doubly exponential: log log |z| grows linearly with n at rate log 2. So mu = n - (log log |z| - log log R)/log 2 = n + log2(log R) - log2(log |z|). With R=2: log2(log 2)= log2(0.693) = -0.531, so mu = n - 0.531 - log2(log|z|)... commonly written as n + 1 - log2(log|z|) which differs by const 1.53 — just a phase offset, irrelevant. So use mu = n + 1 - Math.log2(Math.log(r)) with any bailout, offset constant varies but fine. Use bailout 65536 for smoothness? Extra iterations: points escape past 4 to 65536 in maybe 2-4 extra iterations. Cheap. I'll set bailout r2 > 1e8? Let's use r2 > 1e6 (r=1000), smooth mu = n + 1 - log2(log r). Good smoothness.

Coloring: t = mu; use cyclic: 
```
const u = mu * 0.035 + 0.05;  // maybe scaled
r = 0.5 + 0.5*cos(TAU*(u))  ... 
```
Let's craft nicer palette with three cosine terms phases (0, 0.35, 0.65)? I'll test visually via screenshot.

Alternative palette: blend between deep blue → cyan → white → orange cyclic:
Use cosine: r = 0.5+0.5*cos(6.283*(u)+0.0); g = 0.5+0.5*cos(6.283*(u)+1.0); b = 0.5+0.5*cos(6.283*(u)+2.0)? That gives rainbow-ish.

Let's do a "inferno-ish" or "ocean" cyclic:
u in [0,1): 
r = Math.pow(0.5+0.5*Math.cos(TAU*(u+0.00)),1.4)... 

I'll define a 4-stop cyclic gradient with smooth interpolation (cosine interp between stops) — easier to control: stops at 0: #04070f (near black-blue), 0.3: #1b6ff0? Hmm cyclic with dark stop creates a dark band each cycle — actually classic Mandelbrot renders have that and look good (bands of dark separating bright).

Simpler: cosine palette tuned:
r = 0.5 + 0.5*cos(TAU*(u) + 0.5*TAU*0.0)... 

Decision: implement palette as sum of cosines with coefficients I choose:
```
function palette(u, out){
  const a=[0.35,0.35,0.45], b=[0.45,0.45,0.42], c=[1.0,1.0,1.0], d=[0.00,0.15,0.30];
  r = a0 + b0*cos(TAU*(c0*u+d0)) ...
}
```
That's the IQ cosine palette. With d phases 0, .10, .20 gives hue variation. Set u = 0.06*mu maybe plus darker. I'll pick a=[0.28,0.30,0.42], b=[0.42,0.42,0.40], c=[1,1,1], d=[0.00,0.08,0.20]. Colors cycle blue→magenta→teal etc. Fine; verify via screenshot.

Also add slight darkening with iteration for depth? Skip.

HUD: 
- top-left: title + buttons: Reset view, maybe +/- zoom buttons? Required only Reset. Add "Reset view" button and status: zoom factor, iterations, render progress. Maybe a toggle for showing coordinates under cursor. Keep: coordinates readout (nice), zoom %, iter.

Wheel handler: e.preventDefault(); deltaY: normalize (deltaMode). factor = Math.exp(e.deltaY * 0.0015) clamp; for deltaMode 1 (lines) multiply by 33.

Zoom around cursor:
```
const px = e.clientX, py = e.clientY; (CSS px, canvas at 0,0)
re = view.cx + (px - W/2)*view.scale;
im = view.cy + (py - H/2)*view.scale;  // y down = +im
newScale = view.scale * factor;
view.cx = re - (px - W/2)*newScale;
view.cy = im - (py - H/2)*newScale;
view.scale = newScale;
invalidate();
```
Wait factor >1 when deltaY>0 (scroll down) should zoom out: newScale = scale * factor where factor = exp(deltaY*k) >1 → scale increases → zoom out. Yes.

Pan: on pointermove while dragging: dx in CSS px: view.cx -= dx*scale; view.cy -= dy*scale; invalidate per move.

Reset: restore initial bounds (recompute fit for current size) and invalidate.

Also keyboard: R reset, +/- zoom? optional. Add.

Prevent page scroll on wheel: canvas is fixed and body overflow hidden anyway, but listener passive:false preventDefault.

Responsive controls during rendering: chunked with time budget; also pointer events processed since main thread chunked.

Max iterations readout.

Also add "adaptive preview": while dragging, render at lower quality (fewer iters + quarter res) then full when idle? Simpler: during drag, each invalidate starts new job with preview phase then full — preview appears quickly. Could set fast mode during interaction: during drag, jobs use iter = min(iter, 150) and only preview phase until interaction ends. Let's do: interactive flag set on pointerdown/wheel, cleared after 150ms idle; job computes useFast = interactive → phase 0 only (preview, maybe half-res) and lower iter. Then after idle, full job. Implement: after invalidate with interactive, schedule finalize on idle timeout which invalidates again with interactive=false.

Preview at 1/3 scale might look too blocky; use half scale for interactive preview. Cost: W/2*H/2 = 240k px * 150 iter... avg escape is quick for outside points, but full-black interior points cost maxIter each. Initial view interior ~ maybe 30% pixels. 240k*150 = 36M basic ops ≈ 40-80ms — slightly laggy during drag but chunked into 10ms steps so controls stay responsive; preview appears within a few frames. Could use quarter res for interactive. Use quarter during interaction (78k px → ~15ms) and preview phase for full res too. Fine.

Let me handle DPR: render canvas.width = round(W*dpr). During interaction, render scale factor 0.5 of device px? Preview = device px / 4 (during idle start) /4 also. Actually just preview always at rw/4.

Write the code now.

Progress display: percent = (phase0 complete ? 0.5*? ) compute overall = (fullY / rh) roughly, preview phase shown as 0-25%? Let's: totalWork preview rows + full rows. progress = (rowsDonePreview + rowsDoneFull) / (rh + rh) but preview rows count rh too (they're rh rows at small size). Just compute progress = (phase==0 ? y/rh*0.25 : 0.25 + y/rh*0.75).

Status text update throttled.

Let's also handle resize: recreate buffers, invalidate; keep view center & scale (scale is per CSS px so image stays same relative size — fine).

Now write file.

Edge: putImageData dirty rect requires imgData same size as canvas? putImageData(imageData, dx, dy, dirtyX, dirtyY, dirtyWidth, dirtyHeight) — dirty rect clipped to canvas. Full ImageData sized canvas.width×canvas.height, dx=0,dy=0, dirty from y.. y+rows. Good.

Preview: separate small canvas element (offscreen, document.createElement) sized rw/4 × rh/4, putImageData then ctx.drawImage(previewCanvas, 0,0, canvas.width, canvas.height) with imageSmoothingEnabled = true (default). Good.

Code for stepJob:

```js
function stepJob(){
  const t0 = performance.now();
  const budget = 12;
  while(performance.now() - t0 < budget){
    if(job.phase === 0){
      if(job.py >= job.ph){ job.phase=1; job.py=0; flushPreview(); break? continue; }
      renderRows(job.pimg, job.py, 1, job.pw, job.ph, job.iterSmall);
      job.pctx.putImageData(job.pimg,0,0, 0, job.py, job.pw, 1);
      job.py++;
    } else {
      if(job.y >= job.h){ finishJob(); return; }
      renderRows(job.img, job.y, 1, job.w, job.h, job.iter);
      job.ctx.putImageData(job.img,0,0,0,job.y,job.w,1);
      job.y++;
    }
  }
}
```
Wait preview should be drawn to main canvas after all preview rows: after phase 0 completes, ctx.drawImage(previewCanvas,...). But we put preview into its own canvas; main canvas gets preview only once complete. But main canvas may show stale content meanwhile — acceptable? Better: draw preview progressively scaled rows: drawImage(previewCanvas, sx=0,sy=py,sw=pw,sh=1, dx=0, dy=py*scaleF,...). That gives progressive top-down appearance. Do that: scaleF = canvas.width/pw.

Careful: putImageData to previewCanvas each row, then drawImage that row scaled onto main. Cost small.

Actually simpler: each row after filling preview data, putImageData row into preview canvas and drawImage row to main. Fine.

But then full-res phase overwrites with putImageData rows — overwriting preview progressively. 

Also during interactive fast mode: after preview rows done, job complete (skip full phase) — set job.fast flag → finish after phase 0.

Hmm but then final full-res render after idle — yes invalidate on idle.

Rows-per-chunk: while loop with budget handles it; but renderRows per row could exceed budget for high iter row (W=2400 device px × 2000 iter = 4.8M inner ops ~5-10ms) fine.

Actually could do multiple rows per call but per-row granularity fine.

Smooth color per pixel: avoid computing palette per pixel with cos? Precompute palette LUT of 512 entries when iter changes. u = (mu * 0.06) mod 1 → index = (mu * k) & ... use LUT with 1024 entries, index = ((mu * 0.06) % 1) * 1024 | 0. Since mu up to maxIter, u cycles.

Wait: fixed cycle 0.06 means period ~16.7 iterations — bands get finer as maxIter increases? No, band width constant in iterations, but as you zoom, smooth values near boundary span large ranges → thin bands near boundary. Classic look, acceptable. Alternative: u = mu / maxIter scaled + cyclic... Let's use logarithmic-ish: u = (Math.sqrt(mu) * 0.11) % 1 — expands bands at high iteration values. sqrt spacing: at mu=100, d(u)/d(mu)=0.055/100... derivative of sqrt(mu)*0.11 = 0.055/sqrt(mu) → at mu=100 → 0.0055 per iteration → period 180 iters at mu=100, 110 iters at mu=300 (period = 1/(0.055/√mu) = 18.2√mu). Nice: bands widen with iteration. I'll use u = 0.11*sqrt(mu) with LUT index = (u % 1)*N.

Hmm but sqrt changes with... it's fine and looks good. Test visually.

Inside color: dark navy/black distinct: [6,8,14] or deep purple #0a0612. Maybe a subtle interior gradient? Keep flat distinct color: rgb(10, 10, 16). Or a deep teal. I'll use near-black with slight blue: (8,10,18). Distinct enough vs palette? Palette has dark regions too... make palette brighter: a=[0.45,0.45,0.55], b=[0.5,0.5,0.45] → values 0.0-1.0 mostly bright. Interior pure black #000 is most distinct. Use interior = rgb(0,0,0)? "distinct color" — black with white-ish boundary glow maybe. I'll do interior (12, 6, 24) deep violet-black and make palette range brighter so it contrasts. Let's make palette colors range 0.25–1.0.

Let's write and then screenshot to check colors.

Also HUD styling: translucent panel, monospace-ish font, reset button.

Let me write the file now.

```js
const TAU = Math.PI*2;
const PAL_N = 1024;
let pal = new Uint8Array(PAL_N*3);
function buildPal(){
  for(let i=0;i<PAL_N;i++){
    const u = i/PAL_N;
    const r = 0.42 + 0.44*Math.cos(TAU*(u + 0.00));
    ...
  }
}
```
IQ palette: f(t) = a + b*cos(c*t + d). Choose:
a = [0.46,0.44,0.52], b=[0.46,0.46,0.44], c=1, d=[0.00,0.10,0.25] → r,g,b range [0,0.92]. Hue: at u=0: r=0.92, g=0.44+0.46*cos(0.628)=0.44+0.374=0.81, b=0.52+0.44*cos(1.57)=0.52 → yellowish white. Fine — vibrant.

Actually maybe ocean-like: d = [0.55, 0.35, 0.10]? Whatever, check screenshot.

Interior color: [14, 10, 20].

Let's write it.

Also "zoom centered on complex point under cursor ... stays near cursor while detail renders" — our math is exact, good.

Initial "complete main cardioid and surrounding lobes": fit x span 3.5, y span 2.5.

Also include small "-" "+" buttons? Not required. Add zoom buttons maybe for accessibility — skip to save time? Cheap to add: two buttons zoom in/out at center. I'll add, low cost.

Write file.

HUD layout:
```html
<div id="hud">
  <div class="row"><span class="title">Mandelbrot</span><button id="reset">Reset view</button></div>
  <div class="row stats"><span id="zoom">…</span><span id="iter">…</span></div>
  <div class="bar"><div id="bar"></div></div>
</div>
<div id="coord">…</div> (bottom-left coords)
```

Let's write everything.

Render rows function:

```js
function renderRows(data, y0, nrows, w, h, maxIter, scale, cx, cy){
  const inv = 2... 
  for(let py=y0; py<min(y0+nrows,h); py++){
    const y0c = cy + (py - h/2)*scale; // device px scale: scaleDev = view.scale (per CSS px)? 
```
Careful: view.scale is complex units per CSS pixel. Device pixel position: re = cx + (px - w/2)*view.scale where px in device px but canvas.width = W*dpr... complex-per-device-pixel = view.scale (since device px coordinate maps: CSS x = px/dpr; re = cx + (px/dpr - W/2)*scale = cx + (px - w/2)*(scale/dpr). So for device buffer use scaleDev = view.scale/dpr... Wait view.scale defined per CSS px: re = cx + (cssX - W/2)*scale. cssX = devX/dpr. So re = cx + (devX - w/2)*scale/dpr. So when filling device buffer use scaleDev = view.scale / dpr — but careful: I compute view.scale as complex units per CSS pixel. Hmm, simpler: define view.scale as complex units per device pixel and convert for pointer math: pointer: re = cx + (clientX - W/2)*scaleCss where scaleCss = view.scale*dpr... Let's define view.scale = complex units per CSS pixel and use scaleDev = view.scale / dpr? No wait: scale per device pixel = scale per CSS pixel / dpr? If 1 CSS px = dpr device px, and scale is per CSS px, then per device px = scale/dpr. Yes.

Hmm wait: earlier: re = cx + (devX - w/2)*(scale/dpr). So scaleDev = scale/dpr where w = W*dpr. Check: devX=w/2 → cssX=W/2 ✓.

Simplify: define view.scale as complex units per device pixel directly? Then pointer math uses scale*dpr... whatever. I'll define per CSS pixel and compute scaleDev in job.

Actually cleaner: define view.scale = complex units per canvas device pixel; then pointer: re = cx + (clientX - W/2)*scale*dpr. Eh. I'll keep "per CSS pixel" naming clear: view.scale. In render use s = view.scale / dpr... but careful, when dpr = 2, canvas.width=W*2. Wait but render buffer rows are device rows; per device px = view.scale/dpr. Hmm no! Let me redo: cssX = devX / dpr. re = cx + (cssX - W/2)*scale = cx + (devX/dpr - W/2)*scale = cx + (devX - W*dpr)/dpr * scale = cx + (devX - w/2)*(scale/dpr). Yes scaleDev = scale/dpr. Hmm that seems off intuition: with dpr=2, device pixels are half the size, so complex per device px = half → scale/dpr = scale/2 ✓. Correct.

Simpler alternative: render at CSS resolution always (canvas.width = W, ignore dpr) — blurry on retina but simpler. I'd rather use dpr but cap at 1.5? Let's cap renderDpr = Math.min(devicePixelRatio, 2) and use CSS sizing so pointer math in CSS px with scaleCss = view.scale... but canvas backing store is W*renderDpr. Then "CSS px" for pointer = clientX directly; mapping re = cx + (clientX - W/2)*view.scale must match buffer: buffer pixel devX corresponds to CSS x = devX/renderDpr. So re = cx + (devX/renderDpr - W/2)*scale = cx + (devX - W*renderDpr)*(scale/renderDpr). So scaleDev = view.scale/renderDpr where buffer width = W*renderDpr. OK so I'll define renderDpr and use it consistently. (If renderDpr = devicePixelRatio, same as dpr.)

I'll set: dpr = Math.min(window.devicePixelRatio||1, 2). canvas.style.width=W px, canvas.width = round(W*dpr).

Fine.

Smooth iteration function inline for speed:

```js
function renderRows(buf, y0, nrows, w, h, maxIter, sDev, cx, cy){
  const ln2 = Math.LN2;
  for(let py=y0; py<y1; py++){
    const ci = cy + (py - h/2)*sDev;
    let o = py*w*4;
    for(let px=0; px<w; px++){
      const cr = cx + (px - w/2)*sDev;
      let zr=0, zi=0, zr2=0, zi2=0, n=0;
      while(n<maxIter){
        zi = 2*zr*zi + ci; zr = zr2 - zi2 + cr;
        zr2 = zr*zr; zi2 = zi*zi;
        if(zr2+zi2 > 1e6) break;
        n++;
      }
      ...
    }
  }
}
```
Careful with loop: standard: while(zr2+zi2<=4 && n<maxIter){ zi=2*zr*zi+ci; zr=zr2-zi2+cr; zr2=zr*zr; zi2=zi*zi; n++ }. With bailout 1e6 (r=1000).

Smooth: if n>=maxIter → inside. else r = Math.sqrt(zr2+zi2); mu = n + 1 - Math.log(Math.log(r))/ln2. Note log(r) with r>1000 → fine.

Then color: u = (0.11*Math.sqrt(Math.max(mu,0))) % 1... Actually apply maybe also add small constant. index = (u*PAL_N)|0.

LUT into pal array.

Performance: Math.sqrt and log per pixel — ok.

Let's write the full file now.

Also track coordinate readout on mousemove (throttled).

Idle finalize: 
```js
let idleTimer=null;
function invalidate(fast){ dirty=true; if(fast){ clearTimeout(idleTimer); idleTimer=setTimeout(()=>{interacting=false; invalidate(false);},140);} else ...}
```
Set interacting=true on pointerdown/wheel. Simpler:

```js
function poke(fast){ // fast=true while interacting
  interacting = fast;
  needsRender = true;
  if(fast){ clearTimeout(idleT); idleT=setTimeout(()=>{ interacting=false; needsRender=true; }, 150); }
}
```
Job fast flag: when job starts with interacting → iter = min(iter, 100) and after phase 0 finish (skip full). Actually maybe render full-res too but with low iter while interacting? Cost of full res low-iter while dragging could be heavy (2400×1600×100 iters). Preview-only (1/4) is fastest. Keep preview-only for interactive, full for idle. During pan, preview at 1/4 looks blurry but acceptable and re-renders crisp when released.

Maybe use 1/2 preview when idle start? Idle job: phase0 preview at 1/4 (fast crisp-ish appearance) then full. Fine.

Zoom button: click → animate? Just step scale by 0.5 at center, poke(false)... maybe animate smoothly over 200ms — skip, direct.

Progress bar width update per step (throttle to frames — it's per rAF step anyway).

HUD update: zoom factor = initialScale/view.scale (as "×N").

Reset: view = initialView(); poke(false).

Also initial render at load.

Also window resize handler: set canvas size, keep view (scale per CSS px stays → same complex framing? Width changes → span changes; fine).

Let's write it.

Keyboard: 'r' reset, '+'/'=' zoom in, '-' zoom out.

Now write the file.

Also prevent default touch scrolling: touch-action:none CSS on canvas.

Pointer pan: pointerdown on canvas → setPointerCapture, track last x/y; pointermove → dx = e.clientX-last; view.cx -= dx*view.scale; view.cy -= dy*view.scale; poke(true).

Pinch: maintain map of active pointers; if 2 pointers, compute distance ratio → zoom about midpoint. I'll implement basic version.

Now, write.

For the coordinate display: show re/im under cursor, scale: complex units per pixel.

Let me now write index.html.

After writing, run browser: reload, screenshot, check console, do zoom/pan/reset verification. Verification of "stays near cursor": hard to verify precisely visually; I can check by evaluating JS? The browser tool has "inspect" action which might dump DOM/console. I can add temporary instrumentation? Better: use browser inspect to read window state — I could expose `window.__view` and compute expected. Let's expose window.__mb = {view, initialView, screenToComplex}. Then in inspect I can run? inspect action likely returns DOM/console info, not arbitrary JS eval. Hmm — actions: reload, inspect, screenshot, motion, click, drag, key, scroll, type. No eval. But "inspect" might allow executing? Unknown; I'll try.

Alternative verification: take screenshot before/after zoom and visually confirm detail near cursor. I can do that via screenshots.

Let's build.

Code writing time. I'll be careful and complete.

For HUD: reset button click shouldn't trigger pan (it's over canvas; pointerdown on canvas only — HUD is above canvas with its own elements; pointer events on HUD elements don't hit canvas, but dragging from button onto canvas... fine).

Also wheel over HUD: add wheel listener on window with preventDefault passive false to prevent page scroll everywhere.

Now write.

Write index.html.

One issue: preview scaling in renderRows uses `job.scale / dpr / 4` as complex units per preview pixel — check: preview pixel = 4 device px = 4/dpr CSS px... complex per preview pixel = view.scale (per CSS px) * (CSS px per preview px). CSS px per preview px = 4/dpr. So sPrev = view.scale * 4 / dpr. But I wrote job.scale/dpr/4 — that's wrong by factor 16.

Wait, careful: sDev (per device px) = view.scale / dpr? Earlier derivation: re = cx + (devX - w/2)*(scale/dpr) where scale is per CSS px. Hmm: cssX = devX/dpr only if dpr = canvas.width / W. Yes canvas.width = W*dpr. So sDev = scale/dpr... wait no. Let's recheck: re = cx + (cssX - W/2)*scale. cssX = devX/dpr. → re = cx + (devX/dpr - W/2)*scale = cx + (devX - W*dpr)*scale/dpr = cx + (devX - w/2)*(scale/dpr). So sDev = scale/dpr. Hmm but intuition: scale per CSS px, per device px should be scale/dpr. With dpr=2, device pixel is half size → scale/2 ✓. So sDev = scale/dpr ✓ (I wrote job.sDev = view.scale/dpr ✓).

Preview pixel spans 4 device px = 4/dpr CSS px → sPrev = scale*4/dpr. I wrote job.scale/dpr/4 — wrong; should be job.scale*4/dpr. Fix.

Also preview offsets: in flushPreviewRow, drawImage scales preview canvas (pw × ph) region to full canvas; row py spans preview row (py-1..py) → dest y = (py-1)*sf where sf = canvas.width/pw ≈ 4 ✓ and height sf ✓. Good.

But the final preview row: the full canvas height may not be exactly ph*sf (ph = ceil(h/4)); sf = w/pw based on width ratio; using height ratio h/ph ≈ 4 also. Minor edge. Fine.

Also there's a subtlety: preview covers canvas fully once phase 0 done. Good.

Also flushPreviewRow is called after py++, and uses job.py-1 — but putImageData used job.py before increment ✓.

Another issue: `renderRows(job.pimg.data, ...)` — pimg.data is Uint8ClampedArray ✓.

Also `stateEl` "preview"/"rendering".

Also potential issue: while job.phase transitions 0→1, `continue` inside while loop → rechecks time. OK.

Another: startJob while old job exists — job replaced; fine.

Also `poke` in resize called with false.

Let me fix the preview scale bug.

Wait — sDev derivation: sDev = scale/dpr. Let's double-check with numbers: scale = 3.6/1200 = 0.003 complex per CSS px. dpr=1 → sDev=0.003 ✓. dpr=2 → canvas.width=2400, sDev=0.0015, and device pixel count doubles so total span 2400*0.0015=3.6 ✓. Good.

Preview: pw = ceil(w/4). Complex per preview px = span/pw = (w*sDev)/pw ≈ 4*sDev = 4*scale/dpr = scale*4/dpr ✓.

Now check syntax and run in browser.

Process substitution issue. Extract to temp file instead.

Now load in browser and inspect.

No curl but server likely started. The browser tool likely opens index.html directly (file path). Let's use browser action reload with the file. Probably the harness serves the cwd. Just reload.

Bug: zoom ×0.00 and coords re -600.75, im -400 — that means view.scale is huge/wrong: initial.scale computed but... zoom ×0.00 means initial.scale/view.scale < 0.01, so view.scale >> initial. re at center-left: re = -0.75 + (0 - 600)*scale = -600.75 → scale ≈ 1.0. So view.scale = 1 (the initial default!) — meaning resetView/updateHud never applied initial.scale... Actually zoom shows ×0.00: initial.scale ≈ 0.003, view.scale = 1 → ratio 0.003 → ×0.00 ✓.

Why view.scale stayed 1? resize() → fitInitial() sets `initial` but not `view`. I never copy initial into view on startup/reset... resetView does copy. But startup: view stays {cx:-0.75, cy:0, scale:1}. Need: on resize first time or after fitInitial, set view = initial? But resize should not reset user's view. Fix: initialize view after first fit — in resize, if not initialized, copy. Track `viewInit` flag.

Also colors: everything yellow-ish flat — because scale=1 renders huge area, most points escape at n small... actually the flat yellow suggests palette index nearly constant. With correct scale it should be fine; but there's also a concern: the image shows uniform color bands — that's because at scale 1 covering [-600,600], most points escape at n≈1-3. OK.

Fix: add viewInit flag; also on resize keep view but if not initialized, set from initial.

Also updateHud called after? resize calls poke but not updateHud; updateHud called initially after resize with view.scale=1 → ×0.00. After fix, update view then updateHud in initial flow (already called after resize()).

Edge: on window resize, keeping view.scale (per CSS px) means span changes with window size — acceptable.

Let's fix.

Wait — there's an ordering bug: `view` and `initial` are declared after? In my file, view/initial declared before fitInitial definition and before resize() is called at bottom. viewReady declared near W/H which is after view declaration — fine.

Also `resize()` is called at bottom; fitInitial defined before. Fine.

Reload and check.

Full Mandelbrot visible — cardioid and lobes, interior distinct near-black. Rendering still in progress (screenshot caught mid render; note render at full res ongoing). Colors: outside mostly orange with thin blue boundary. It works but palette bands are compressed near boundary — because sqrt spacing with 0.115 factor gives few cycles for low mu (mu up to ~30 outside far field → 0.115*sqrt(30)=0.63, less than one cycle). Far field nearly uniform orange. It'd be nicer to have more variation. Increase factor to ~0.25? Then at mu=10 → 0.79 cycles; near boundary mu=100 → 2.5 cycles; deep mu=1600 → 10 cycles. Hmm, could also add a log term: uu = 0.09*sqrt(mu) + 0.06*log(mu+1)... Let's use uu = 0.18*sqrt(mu). At mu=1: 0.18; mu=10: 0.57; mu=100: 1.8; mu=400: 3.6; mu=1600: 7.2. Reasonable.

Wait for render to finish and check final quality, then do zoom test. Let's screenshot after a moment.

Actually screenshot right after reload may be mid-render — fine.

Also note the pixelation: preview quarter-res visible in boundary (blocky). Full res should be smooth. Let's take another screenshot now (render likely done).

Also increase palette cycles. Let me first check final render state.

Full-res render finished, crisp. Whole set visible with cardioid + lobes ✓. Interior distinct dark navy ✓.

Color improvement: far field flat orange. Increase color cycling a bit: uu = 0.16*sqrt(mu) maybe plus small linear term to give far-field gradient: uu = 0.13*sqrt(mu) + 0.004*mu? At mu=20 far field: 0.58+0.08=0.66; mu=4: 0.26+0.016. Gives more variation far out without over-cycling near boundary (mu=400: 2.6+1.6=4.2 cycles). Hmm linear term compresses near boundary again. Let's use uu = 0.16*sqrt(mu) only. Far field: mu 1→0.16, 4→0.32, 10→0.5, 25→0.8, 50→1.13, 100→1.6. So far field spans a good range already... but screenshot shows mostly uniform orange at mu range maybe 1-8 → 0.16-0.45 spans orange→? Palette at u 0.16-0.45 — apparently both orange-ish? Palette phases: d=[0.02,0.14,0.31]. u=0.16: r=0.46+0.44cos(2π*0.18)=0.46+0.33=0.79; g=0.44+0.46cos(2π*0.30)=0.44-0.14=0.30; b=0.54+0.44cos(2π*0.47)=0.54-0.44=0.10 → orange. u=0.45: r=0.46+0.44cos(2π*0.47)=0.03; g=0.44+0.46cos(2π*0.59)=0.44-0.37=0.07; b=0.54+0.44cos(2π*0.76)=0.54+0.10=0.64 → dark blue/purple. So far field should vary orange→dark... The screenshot shows gradient orange near edge to reddish center region. Actually visible variation exists (red glow near set). It's fine.

Maybe just bump factor slightly from 0.115 to 0.15 for a bit more variety. Minor. Let's leave 0.115? At mu=100 (near boundary) → 1.15 cycles vs 0.115→ sqrt(100)=10*0.115=1.15, already 1 cycle. Fine. Current look is decent: blue filaments, orange field, distinct black interior. I'll keep as-is but slightly raise to 0.13 for a touch more variety. Eh — don't fiddle; it looks good.

Now test zoom at a boundary point. Verification: zoom into recognizable boundary point and check it stays near cursor. I'll use browser wheel scroll at a boundary location. Wheel action: browser action "scroll"? There's a "scroll" action with delta. Does scroll dispatch wheel events on element at x,y? Likely. Let's scroll at a boundary point, e.g., around (430,400) — the left mini-bulb boundary at approximately (430,400)? Actually boundary point: the cusp between bulbs near (600,400)... Let's pick the junction on left of cardioid around x=605,y=400 (cusp at -0.25?). Hmm: cusp at re=1? Center -0.75 at x=600. scale = 3.6/1200=0.003. re = -0.75+(x-600)*0.003. x=430 → -1.26. That's boundary of the period-2 bulb (bulb centered -1, radius 0.25 → spans -1.25..-0.75 at y=0). So (430,400) ≈ re -1.26, im 0 — on/near boundary of the bulb. 

Let's scroll there with several wheel events and observe: after zoom, the feature under cursor should stay at same screen point.

Browser "scroll" action has delta param — dispatches wheel? I'll try scroll at x,y with negative delta (zoom in).

Do a few scrolls, then screenshot. Then also pan with drag, then reset and compare with initial.

Also I need to verify coordinates readout updates and console clean.

Let's perform zoom: scroll at (430,400) delta -400? Multiple times.

Zoom worked (×1.47). The point that was at (430,400) — in the new image, the boundary near re -1.26, im 0: where is it? re -1.26: screen x = 600 + (re - cx)/scale... need new cx. But visually: the small bulb junction that was at x≈430,y=400 should stay at 430,400. In new image at (430,400)... nothing there — hmm. Wait, the feature at (430,400) originally: boundary of period-2 bulb at re=-1.26, im=0 → y=400 is im 0 ✓. In new image around (430,400) is orange field. That's suspicious!

Hold on — did the zoom center correctly? The screenshot appears zoomed around... center of zoom should keep (430,400) fixed. The rendered image looks like zoom was centered around maybe (750,550)? Let's compute precisely instead of eyeballing.

Wait — also note iterations dropped to 140: interacting flag still true at the time job started (poke(true) sets 140ms timer; scroll → poke(true) → job started with fast=true → preview only at 140 iters). But the screenshot shows full-res crisp? Status "ready" and bar gone. Hmm, if fast, after phase 0 we finish — image would be quarter-res upscaled (blurry). The image looks decent but maybe it is the upscaled preview (looks slightly soft). Then after 140ms, needsRender=true → full job. By screenshot time (Frame 1, +0ms after scroll) maybe still preview. Status shows "ready"?? finishJob sets ready. Then idle timer fires at 140ms and sets needsRender → new job starts "rendering". Screenshot happened after that? Status says ready, so full render completed... but wait screenshot may be taken later than the inspect frame.

Hmm, but zoom centering: let me verify numerically. I can't eval JS directly... Actually maybe inspect allows more? The inspect output only shows DOM/console.

Let's compute expected: initial view: cx=-0.75, scale=0.003 (3.6/1200). Wait H=800: 2.6/800=0.00325; W: 3.6/1200=0.003 → scale=max=0.00325. So scale=0.00325, cx=-0.75.

Point p at (430,400): re = -0.75 + (430-600)*0.00325 = -0.75 - 0.5525 = -1.3025; im = 0.

factor = exp(-240*0.0016)=exp(-0.384)=0.681 → zoom in by 1.47 ✓. newScale = 0.00325*0.681=0.002214.

newCx = p.re - (430-600)*newScale = -1.3025 + 170*0.002214 = -1.3025+0.3764 = -0.9261.

Check where re=-1.3025 maps now: x = 600 + (re - cx)/scale = 600 + (-1.3025+0.9261)/0.002214 = 600 - 170 = 430 ✓. So math keeps it fixed.

So the feature at (430,400): re -1.3025, im 0. Is that on a boundary? The period-2 bulb spans re ∈ [-1.25, -0.75] centered -1 radius 0.25. re=-1.3025 is slightly outside the bulb, in the field beyond its left edge (in the halo region, left of the bulb at x<-1.25, i.e., near the antenna/minibrot region at re≈-1.3-1.4? The antenna runs left along im=0 with mini-bulbs: there's a period-3 structure around -1.35?). At the initial view, screen x=430 was at the left edge of the small bulb around -1.3? In initial screenshot at (430,400) there's a small dark blob (a mini bulb at ~re -1.3?). Actually initial screenshot shows small bulbs along the antenna at x≈430 (a dark dot with blue ring) and x≈390, etc.

In the zoomed screenshot, at (430,400) I see orange... but wait, look at image: there is a small dark/blue feature at around (430, 590)? and the antenna line runs at y≈590, not 400! The antenna in the zoomed image is at y≈590. That means im=0 moved from y=400 to y=590?! That would mean vertical centering shifted — a bug!

Hmm. Why? Zoom keeps point under cursor fixed in both axes... unless the preview scaling misaligns rows (drawImage row mapping) — but that affects rendering not geometry.

Wait, maybe the zoomed image is stale/mid-render showing a mismatched frame? Or my assumption about where the antenna is: In zoomed image, y for im=0: y = 400 + (im - cy)/scale. cy: initial 0; new cy = p.im - (400-400)*newScale = 0. So im=0 at y=400 still. But the antenna appears at y≈590 in the screenshot!

Unless... the dark region on the right: main set occupies right side. Let's check re mapping for visible features: cusp of cardioid at re = 0.25? In zoomed screenshot, the big set occupies from x≈600 rightwards at y=400. re at x=600: -0.9261+0=... x=600 → re = cx = -0.9261. Is -0.9261 inside the set? No! re=-0.9261, im=0 is inside the period-2 bulb (bulb spans -1.25..-0.75) ✓ — yes it IS inside the set (the bulb). So at y=400, x from 600 rightward should be inside bulb until re=-0.75 boundary, then cardioid region... Actually between -0.75 and cardioid, at im=0 the whole real axis segment [-0.75, 0.25] is inside cardioid. So along y=400, everything from x=600 (re=-0.926) rightwards is INSIDE the set until re=0.25 → x = 600 + (0.25+0.9261)/0.002214 = 600+531 = 1131. So at y=400 the dark region should extend from x=600 to x≈1131. In the screenshot at y=400, dark region spans roughly x≈890 to beyond 1200. Hmm, that doesn't match either. And blue boundary around x≈890 at y=400: re = -0.9261+(890-600)*0.002214 = -0.9261+0.642= -0.284. Hmm, at im=0, re=-0.284 is inside the cardioid (inside), not boundary.

So the image seems shifted. Let me reconsider: maybe the screenshot is mid-render with a mismatch: preview drawn at quarter scale but full-res putImageData rows overwriting... A geometry mismatch of the whole image suggests preview rows drawn at wrong vertical positions? If preview row mapping used sf based on width but height mismatch... no, uniform.

Alternative: the screenshot was taken while a NEW full-res job rendered rows from the top while preview underneath? Then top would be full res and bottom preview — but geometry identical.

Hmm wait, maybe I'm misreading the image. Let me re-examine: the zoomed screenshot shows the period-2 bulb (big black circle with "eye"?) centered around (775,555) radius ~110. Boundary features... and the antenna extends left at y≈590 to x≈320. And main cardioid on the right from x≈890.

If im=0 is at y=400, but the bulb center (im=0) appears at y≈555 → shift of 155 px. And the bulb center re=-1 should be at x = 600+(-1+0.9261)/0.002214 = 600-33 = 567, but appears at x≈775.

So the whole image appears shifted down-right by roughly (210, 155). Hmm, that's like the image was rendered with a different view than the current view — e.g., stale geometry from a previous zoom or... Wait: could the shift be because the pointer coords used are not client coords relative to viewport? scroll action at (430,400) in a 1200x800 viewport → clientX=430 ✓.

Alternatively — the shift could be caused by preview drawImage accumulating offset errors? Let's compute where the image content implies center: bulb center (-1, 0) at screen (775,555): cx = -1 - (775-600)*s ; cy = 0 - (555-400)*s → with s such that... Need another point: cardioid boundary along im=0 at re=0.25 → screen x where dark ends at y=400... can't tell precisely.

Use two: bulb center re=-1 at x=775; antenna? Also bulb radius 0.25 → in pixels = 110? → s = 0.25/110 = 0.00227 ≈ expected 0.002214 (close, given my rough pixel readings). With s=0.00227: cx = -1 - 175*0.00227 = -1-0.397 = -1.397. Expected cx=-0.926. Difference 0.47 units ≈ 207 px. cy = -155*0.00227 = -0.352 vs expected 0 → 155px shift.

So the rendered image corresponds to a view centered at (-1.397, -0.352) with same scale. Interesting: (-1.397, -0.352)... What center would produce that? If zoom had been applied about the cursor but the "complexAt" used stale scale... Let's test hypothesis: zoom about cursor applied twice? or applied about wrong point?

Alternative hypothesis: the scroll action dispatched wheel at (430,400) but zoom used a different location, e.g., centered at screen center? If zoom about center (600,400): cx stays -0.75... no, scale changes: newCx = -0.75 (unchanged since dx=0). Not matching.

What if factor applied but anchor computed with the NEW scale (i.e., bug order)? newCx = p.re - dx*newScale — that's correct order. If instead anchored incorrectly: cx = p.re - dx*oldScale? = -1.3025 + 170*0.00325 = -1.3025+0.5525 = -0.75 → cx stays -0.75. Not matching.

Hmm what if it's not a geometry problem but a rendering problem: rows written into the ImageData at wrong y offsets? E.g., full-res job image drawn with putImageData rows but preview drawn scaled differently... no, both same geometry.

Wait — maybe the discrepancy: the screenshot might be showing a *stale* preview from an earlier state? Let's think: after scroll, job started fast (preview 140 iters). Preview rendered with job.scale, sDev/4 etc. If preview geometry was wrong (e.g., sPrev wrong), the preview would be misaligned! I set sPrev = job.scale*4/dpr. Let's check: preview buffer pw = ceil(w/4). Complex span should equal full span: span = w * sDev where sDev = scale/dpr... wait sDev: full buffer w = W*dpr; span = w * (scale/dpr)?? Hold on: earlier I derived sDev = scale/dpr... let's verify: span in complex units across width = W * scale (CSS). w = W*dpr device px → per device px = W*scale/(W*dpr) = scale/dpr ✓. So sDev = scale/dpr ✓ (job.sDev = view.scale/dpr ✓).

Preview: pw ≈ w/4 → per preview px = span/pw = (W*scale)/(W*dpr/4) = 4*scale/dpr ✓ = job.scale*4/dpr ✓ (after my fix).

Hmm so preview geometry fine.

But wait: is it possible that dpr ≠ actual? canvas.width = round(W*dpr), if W*dpr not integer rounding → tiny error, not 155px.

Let's reconsider: maybe the shift is because `interacting` was true when job started, fast preview at 140 iters... but geometry independent of iters.

Alternatively, maybe my pixel readings of the screenshot are off because the screenshot might not be 1200x800 scaled? The image is 1200x800 ✓.

Hmm, let me reconsider the initial screenshot: bulb center (-1,0) initial: x = 600 + (-1+0.75)/0.00325 = 600 - 77 = 523; y=400. In initial screenshot, the period-2 bulb (left black circle) is centered around (525, 400) ✓ radius 0.25/0.00325 = 77 px → observed ~77 ✓. Good, initial render geometry correct.

Now zoomed: expected bulb center (567,400) but observed (775,555). Difference (+208,+155).

Hmm! What if the wheel event fired multiple times (scroll fired wheel + something)? Even so, zoom about fixed anchor keeps that anchor.

What if `poke(true)` timer set interacting=false at 140ms, then a full job started but with... geometry from view — view unchanged between. So no.

Could the offset arise from flushPreviewRow's drawImage destination y using sf = canvas.width/pw (≈4) — dest rows: (py-1)*4 ✓ matches preview rows at 4x. ✓.

Unless... the full-res putImageData over preview: both same geometry ✓.

Hmm, so where does a shift come from? Maybe my reading of the zoomed screenshot is wrong: perhaps the big black circle at (775,555) is NOT the period-2 bulb but a different feature (e.g., a satellite bulb on the boundary), and the real period-2 bulb is off-screen right. Let's check: with expected center cx=-0.926, the period-2 bulb center (-1,0) at x=567,y=400, radius 113px. In screenshot at (567,400) region: there's orange/dark? At (567,400) I see orange field. Hmm.

But wait — the observed big black circle centered (775,555): under expected geometry, that point is re = -0.926+(775-600)*0.002214 = -0.538, im = (555-400)*0.002214 = +0.343. Is (-0.538, 0.343) in the set? |that| — it's likely outside (the set's interior near there: cardioid interior includes points near -0.5+0.3i? The main cardioid: center ~ -0.1? no. Cardioid: c = e^{iθ}/2 - e^{2iθ}/4. Points inside cardioid have modulus... For θ=π/2: 0.5i - (-1)/4 = 0.25+0.5i. So cardioid spans roughly |c+?|. The point -0.538+0.343i: cardioid boundary near left is at -0.75 (cusp is at 0.25? no). Cardioid: leftmost point is -0.75 at θ=π: e^{iπ}/2 - e^{2iπ}/4 = -0.5-0.25 = -0.75 ✓. Top: θ=π/2 → 0.25+0.5i. So the point -0.538+0.343i: is it inside cardioid? Cardioid interior test: the map w = ... let's just check numerically: cardioid boundary points: θ=2.4: cos2.4=-0.737,sin=0.675 → e^{iθ}/2 = -0.368+0.338i; e^{2iθ}: cos4.8=0.087, sin4.8=-0.996 → /4 = 0.0218-0.249i; c = (-0.368-0.0218) + (0.338+0.249)i = -0.390+0.587i. Hmm. θ=2.8: e^{iθ}/2 = -0.468+0.169i... wait cos2.8=-0.942, sin2.8=0.335 → /2 = -0.471+0.1675i; 2θ=5.6: cos=-0.776,sin=-0.631 → /4 = -0.194-0.158i; c = -0.665+0.009i. So along the boundary between θ=2.4 and 2.8, boundary goes from -0.39+0.587i to -0.665+0.009i. Point -0.538+0.343i is roughly on that chord → it's near the cardioid boundary! Interesting — so the "big black circle" I saw might be the cardioid edge region... but it looked circular.

OK this eyeball analysis is unreliable. Better: do a rigorous numeric verification. I can't eval JS in page... but maybe the browser "inspect" runs in page and can execute? Let's test: I could add a debug element to the page that displays computed info (e.g., render a marker). Better approach: instrument the page to draw a test overlay? That's hacky.

Alternative rigorous check: use the coords readout! It shows complex coords under cursor. I can hover (mouse move via "type"? no — there's click which moves mouse?) Actions: click(x,y) presumably moves+clicks. Hover triggers pointermove → coords update → inspect shows coords element.

Verification plan:
1. Move pointer to (430,400) before zooming → read coords (should be re -1.3025, im 0).
2. Zoom.
3. Move pointer back to (430,400) → read coords: should be exactly the same complex value if zoom is cursor-anchored.

That's a solid check! Let's do it. Use click (which does pointerdown/up? clicking pans by 0 — harmless, but it also sets dragging class briefly; fine) or is there a hover action? "click" is what we have; also "type" types text. Clicking on canvas with no movement = zero pan ✓.

But careful: click may trigger pointerdown → poke(true) etc. Fine.

Also note: a click could count as pan of 0 dx ✓.

Let's test: click at (430,400) and inspect coords. But the click handler for zoomIn button etc — not there. Canvas click has no click handler ✓.

Let's do it.

Coords at (430,400) after zoom: re -1.7481, im -0.4145.

Expected from correct anchor: should equal pre-zoom value p = (-1.3025, 0). It's not — but wait, I clicked at (430,400) BEFORE zoom? No: initial screenshot was pre-zoom, then I scrolled at (430,400), so anchor p should be pre-zoom coords of (430,400) = (-1.3025, 0). But now the readout says (-1.748, -0.4145).

Hmm! But wait: the click itself panned? No.

Let's compute what center the current view implies: re = cx + (430-600)*scale; -1.748 = cx -170*s. im: -0.4145 = cy + 0*s → cy = -0.4145?? im at y=400 = cy + 0 = cy → cy = -0.4145. But expected cy = 0 (anchor im 0 at y=400, cursor y=400).

So cy shifted by -0.4145. And scale: unknown from one point. Zoom readout ×1.47 → scale = initial.scale/1.47... wait zoom = initial.scale/view.scale = 1.47 → view.scale = 0.00325/1.47 = 0.002211 ✓ matches expected 0.002214. So scale correct, but center wrong: cx = -1.748 + 170*0.002211 = -1.748+0.376 = -1.372; cy = -0.4145.

Expected cx = -0.926, cy = 0.

Hmm! What anchor would give cx=-1.372, cy=-0.4145? Solve: anchor point a with screen coords (ax, ay):
cx = a.re - (ax-600)*s, cy = a.im - (ay-400)*s.
If the anchor used was complexAt of the scroll position but computed with... let's test hypothesis: the scroll event's clientX/clientY might not be (430,400)?? Maybe the browser tool's scroll uses x,y differently. Suppose the wheel happened at some other screen point q, with anchor = complexAt(q) using OLD view, and then cx = a.re - (430-600)*s?? No, same coords used.

Alternatively: maybe TWO events happened: the click I did at (430,400) triggered... clicks don't change view.

Let's solve for anchor: from final view, complex at final cursor (430,400) = (-1.748,-0.4145). The anchor point must satisfy: a = complexAt_old(q) and final cx = a.re - (qx-600)*s_new.

Try q = (430,400): a = (-1.3025,0) → cx = -1.3025 +170*0.002211 = -0.927 ✗ (actual -1.372).

Try q = (600,400) (center): a = (-0.75, 0) → cx = -0.75 ✗.

Hmm what about factor applied twice with anchor at 430: after first zoom s=0.002211, cx=-0.927,cy=0. Second zoom about same screen point: a2 = complexAt(430,400) with new view = same p ✓ → cx unchanged -0.927. Still ✗.

So cy = -0.4145 means anchor im ≠ 0 → anchor screen y ≠ 400, OR anchor complexAt used different scale.

Solve assuming anchor complex = old complexAt(q) with old view, and q is the anchor:
cx = a.re - (qx-600)*s → -1.372 = [-0.75 + (qx-600)*0.00325] - (qx-600)*0.002211 → -1.372 +0.75 = (qx-600)*(0.00325-0.002211)= (qx-600)*0.001039 → -0.622 = (qx-600)*0.001039 → qx-600 = -599 → qx = 1?? 
Similarly cy: -0.4145 = (qy-400)*0.00325 - (qy-400)*0.002211 = (qy-400)*0.001039 → qy-400 = -399 → qy = 1.

So the anchor was (1,1)! Interesting — as if clientX/clientY were 0 (or the wheel at (0,0) offset by 1?). With q=(0,0): qx-600 = -600 → cx = -0.75 -600*0.00325 + 600*0.002211 = -0.75 -1.95+1.327 = -1.373 ✓ matches! cy: -400*0.00325+400*0.002211 = -1.3+0.884 = -0.416 ✓ matches -0.4145.

So the wheel event had clientX=0, clientY=0 (or the scroll tool dispatched wheel with coords 0,0 / or pageX 0). So my zoom-about-cursor math is CORRECT; the test harness's scroll event lacks position (probably dispatched as window scroll with no coords, or a wheel event at 0,0).

Hmm — but the scroll DID trigger wheel and zoomed by factor exp(-240*0.0016)=0.681 ✓ factor matches, so it's a wheel event with deltaY=-240 and clientX/Y = 0.

So verification via scroll-at-point isn't reliable in this harness. Alternative: dispatch wheel myself? I can't eval. Options:

1. Add my own verification affordance in the app? Not needed for the product; but I could add a temporary test harness... Better: verify zoom anchoring math via a Node simulation of the same code (pure math) — I already did the math by hand. But requirement: "check that it stays near the cursor while additional detail is rendered."

2. Use the zoomIn button (centers) — not cursor-based.

3. Simulate wheel with correct coordinates: maybe the scroll tool passes x,y correctly but dispatches on window with clientX=0? The evidence says coords were (1,1)-ish ≈ (0,0). So harness limitation.

Alternative: I can verify visually: after a scroll, the point that should stay at cursor... but cursor coords unknown (0,0). Hmm.

Could I use keyboard-based zoom anchored at screen center? A feature: press keys +/-, zoom about viewport center — that's center-anchored and verifiable: point at center (600,400) must stay at (600,400). Combined with hover coords readout: record re at center before/after zoom via click at (600,400). That verifies anchoring logic (same code path as wheel minus coordinate source).

Even better: I could make the wheel test work by having the harness dispatch wheel events... Not controllable.

Wait — maybe "scroll" action dispatches wheel at x,y but my listener is on window and the harness dispatches with screenX/screenY only? Doesn't matter — clientX missing means real browsers... Real browsers set clientX correctly. This is a harness quirk.

Alternative approach for genuine cursor-anchored visual check: zoom with wheel (anchored at 0,0 i.e. top-left), then check that the complex point at top-left corner (0,0) stayed fixed: hover (1,1)... Actually verify: coords at (0,0) after zoom should equal coords at (0,0) before zoom. I know before-zoom coords at (0,0): re = -0.75 + (0-600)*0.00325 = -2.70, im = 0 + (0-400)*0.00325 = -1.30 (that's exactly the readout from initial screenshot corner values -2.7/-1.3 ✓ consistent!).

After zoom: complexAt(0,0) with final view: cx=-1.373, cy=-0.416, s=0.002211 → re = -1.373 - 600*0.002211 = -1.373-1.327 = -2.70 ✓ ; im = -0.416 - 400*0.002211 = -0.416-0.884 = -1.30 ✓. 

So the anchor point (0,0) complex coords are exactly preserved → cursor-anchored zoom math verified exactly (to 14 digits). And since in a real browser clientX/Y are the cursor position, the "stays under cursor" property holds by the same algebra.

To also demonstrate with a real cursor position, I can do a hover-based check with keyboard zoom centered: click at (600,400) to read center coords, press "+" (zoom about center), click at (600,400) again, compare — should match exactly. That exercises zoomAbout with real cursor coords.

Let's do:
1. Hover (600,400): but wait, current view is the weird top-left-anchored one. Fine, values just need to match across zoom.

Actually simpler and more meaningful: first Reset view (press R or click button), then hover at a boundary point (e.g., (430,400)), record coords; press "+"? that zooms about center not cursor. Hmm, keyboard zoom uses W/2,H/2. I could record coords at CENTER, keyboard-zoom, record center again → verifies anchor logic with center. Then separately verify wheel gave exact preservation at (0,0) as computed above.

Additionally: visual test that detail renders near a point: after several wheel zooms (anchored at top-left corner (0,0)), the corner point stays fixed and new detail appears. Screenshot comparison: the feature at corner... corner is at edge, meh.

Alternative: I can make zoom anchored where I want by... the harness wheel always at (0,0). What if I move the interesting boundary point to the top-left corner? Pan the view so that the target boundary feature is at screen (0,0)... can't drag precisely? Actually I can: use drag with known delta: view shifts by dx*scale. Dragging from (600,400) to (0,0) shifts cx by +600*scale etc. Then the feature I want at corner... too convoluted.

Better idea: zoom anchored at (0,0) repeatedly → the complex point at corner stays fixed while detail grows around the corner. That literally tests "point stays near cursor" with cursor at (0,0)... but the harness's cursor during wheel isn't visible.

Alternatively, since drag works with real coordinates (do drag positions work correctly? drag action presumably provides coords properly), I can verify PAN numerically: hover point, drag by (dx,dy), hover at moved location, check complex coords unchanged (pan keeps world point under the dragging finger... after panning by dx, the point previously at x+dx is now at x). Let's verify: complexAt should show that world coords shift correspond exactly.

Plan of checks:
A. Reset → screenshot vs initial (framing compare).
B. Hover (430,400) → coords A. Wheel zoom (anchored 0,0 per harness) → hover (0,0)... can I hover exactly (0,0)? click(0,0) might be interpreted oddly but ok. Instead hover (1,1) approximately; precision to ~0.003*1 px fine.
   Check: coords at (1,1) before vs after. Need before coords: I can compute prediction and compare after. Actually do: click(1,1) BEFORE zoom to read coords; zoom; click(1,1) after → compare.
C. Pan test: drag, verify coords mapping.
D. Reset → click(430,400) → coords should equal original (-1.3025, 0) and screenshot equals initial framing.

Also verify iterations increase with zoom (HUD shows 140 during fast preview; final full render uses higher count as zoom grows — HUD iterVal updates on startJob).

Also check console errors throughout (none so far).

One concern from screenshot: during/after wheel, status showed "ready" quickly, then "preview" when I clicked (because click → pointerdown → poke(true)). Notice: after click at (430,400), status "preview" and image still shows... the last screenshot shows a crisp image? It looks crisp (fine filaments). But status "preview" means fast job running → image would be quarter-res upscaled. The screenshot after click shows... it's hard to tell; it looks fairly crisp but might be upscaled preview. After idle 140ms, full render starts. The inspect result came right at click, screenshot maybe taken a bit later.

Hmm, but there's a real issue: clicking (a tap) triggers fast preview and then full render — fine.

Wait, but there's a bug: after the wheel, the full-res render should run after idle. Status at click time was "ready" → full render had completed ✓.

Another issue: during fast preview jobs, iterVal shows 140 while actual full job uses 160/zoom-dependent; HUD updates on each job start ✓.

Also noticed iterations 140 shown at ×1.47 zoom after full render? The inspect before click showed "iterations 140" and status "ready" — that suggests the last completed job was a FAST job (140 iter) and no full job ran afterwards! Why? poke(true) at wheel → interacting=true; timer 140ms sets interacting=false and needsRender=true → next frame startJob with fast=false → full job → iterVal would show full iter (160+) and status "rendering"→"ready". But readout showed 140 & ready.

Unless the timer's needsRender got consumed... order: wheel → poke(true) → timer set. Frame loop: needsRender → startJob (fast). At 140ms: interacting=false, needsRender=true. Frame → startJob(fast=false) → status "rendering", iterVal=160. Then renders ~1-2s → "ready". The inspect right after scroll showed status "ready" and iter 140 — that's the fast job finished, and idle timer maybe not yet fired? Screenshot timing... The screenshot might be taken immediately after inspect, likely within 140ms? Possible: fast preview at quarter-res finished in <140ms, status ready, iter 140, screenshot at ~100ms → looks crisp-ish because upscaled with smoothing (it looked pretty crisp though...).

Then my click at (430,400) → status "preview" (fast job) — and the image in that screenshot looks crisp with fine filaments: quarter-res upscaled wouldn't show such fine detail... Actually it might: smoothing preserves coarse structure. Hmm, but the boundary shows tiny satellite bulbs — could be full-res.

Wait, the click's inspect showed status "preview" — meaning a fast job was in progress at inspect time. Screenshot afterwards presumably right after → would show partial preview. The image looks complete though. Since after click, timer → full job → completes → screenshot? Screenshots may take longer (rendering the page). Unclear.

Potential real bug: if `interacting` is true and needsRender triggers a fast job, but then idle timer fires needsRender=true → full job. That chain works. But what if a fast job is started and idle timer fires BEFORE the fast job starts (needsRender already true)? Then interacting=false when startJob runs → full job directly ✓ fine.

Let's test actual full render at zoom: currently at ×1.47. Let's do the checks.

Also potential issue: barfill "100%" then reset to 0 after 250ms only if !job — ok.

Let's run check B: click (1,1) to read coords.

Hmm, click at (1,1) → pointerdown sets panning, pointerup → poke(true) → triggers fast re-render each interaction (unnecessary re-render on click since view unchanged... poke just re-renders same view; slight waste but harmless).

Actually — clicking shouldn't re-trigger a render if the view didn't change. Minor optimization: only poke on actual pan movement. endPointer panning poke(true) unconditionally — I'll leave it; it's cheap-ish. Actually it causes full re-render after every click (2s of CPU). Better: track whether movement happened. I'll refine: set a `moved` flag in pointermove; only poke in endPointer if moved. And pointerdown shouldn't poke at all (it doesn't). The click then causes no re-render (but the coords update happens via pointermove... does click fire pointermove? The harness click likely moves the mouse → pointermove fires → updateCoords ✓ but panning is true at that point? pointermove updates coords regardless of panning ✓ and if not dragging, no poke ✓).

Wait: in pointermove, if panning and dx,dy = 0 → no poke ✓. So only endPointer's poke(true) causes the render. Fix that.

Let me make that edit, then continue verification.

Now verification. Step 1: record coords at a boundary point (430,400) in current view? Better plan: press R to reset first, then record coords at (430,400).

Actually let's do pan test first from current view (more interesting to pan then reset and compare to initial).

Sequence:
1. Drag: from (600,400) to (450,300) — pan.
2. Check coords readout consistent: after pan, the complex point at (450,300) should equal complex point that was at (600,400) before drag. I can pre-read center coords by clicking (600,400) before drag... but click causes pointer capture etc. Let's:
   a. click (600,400) → read coords C0 (current center).
   b. drag from (600,400) to (450,300).
   c. click (450,300) → read coords C1. Expect C1 ≈ C0 (within rounding of click position exactness).
3. Then press R (key) → click (430,400) → expect -1.3025/0.0 and screenshot compare to initial.
4. Also zoom check: click (1,1) record, wheel, click (1,1) record — expect identical.

Do them one at a time (dependent). Start with step a.

Center coords: (-1.37179371699988, -0.41452914466659). Confirms my computed cx=-1.373,cy=-0.416 ✓ (cx = re at center).

Hmm interesting: the image hasn't changed geometry vs the previous screenshot — matches.

Also status shows "preview" — the click started a fast job again (click → pointerdown/up with moved=false → no poke now... but this run is the OLD file? I edited the file but haven't reloaded! The browser still runs the previous version. Need to reload before further checks. Reload now (that resets view to initial anyway).

Let's reload → initial view → then run tests on the new code.

Initial framing: complete cardioid + period-2 bulb + antenna + satellite bulbs, all visible ✓ (this is the mid-render/preview frame; full-res follows).

Now do pan test: click center (600,400) → C0; drag (600,400)→(450,300); click (450,300) → C1; expect C1 ≈ C0.

First, let full render finish — not strictly needed since coords don't depend on render. Do click now.

Center = (-0.75, 0) exactly ✓, full render "ready", click did NOT re-trigger render (status stayed ready) ✓ — the moved-flag fix works.

Now drag from (600,400) to (450,300).

The image panned: dragged from (600,400) to (450,300) means content moves with the pointer by (-150,-100)... wait, in the screenshot the set moved LEFT and UP? The cardioid center was at ~(775,400), now at ~(625,300) → moved (-150,-100) ✓ exactly matching the drag delta ✓ (content follows the pointer).

Hmm, but pan semantics: view.cx -= dx*scale with dx = -150 → cx increases by 150*scale → content shifts left by 150 px ✓ (feature moved left/up by drag delta ✓ correct drag behavior).

Screenshot shows preview still pixelated (fast job at 140 iter), status "ready"?? Status says ready and bar at ~30%... bar shows partial fill (cyan to 30%). Hmm — status "ready" but bar not reset? finishJob sets 100% then resets to 0 after 250ms if no job. The bar looks ~30% filled — maybe mid preview job while screenshot taken... but status "ready"?? Actually status element might show "preview" during job; it shows "ready" — maybe the fast job finished (ready) but full job hasn't started? idle timer 140ms → then full job. Timing: screenshot taken right at drag end. Bar could be from the fast job at 30%? Inconsistent but timing artifacts.

Wait: bar shows fill up to ~90px of 248px width ≈ 36%... finishJob sets 100% (full width). So the screenshot caught the fast job mid-way with status "ready"? Status is set to 'preview' on startJob. Odd. Unless status shows 'ready' because finishJob ran and bar transition (.12s linear) hadn't... no, bar would go to 100%.

Hmm: Actually maybe screenshot order: the DOM output was captured at inspect time (status ready, iter 140 = fast job finished), then screenshot slightly later during... no, iter 140 with status ready means last job was fast. Then the idle timer should start a full job (iter 160, status rendering). Screenshot shows iter 140 + status ready + bar ~36%.

Possibility: the fast job finished → finishJob → bar 100% → after 250ms bar → 0% (if !job). Screenshot shows 36% — mid-transition of bar shrinking from 100%→0%? A width transition from 100% to 0 over .12s... then it'd be small. 36% plausible during shrink. And status ready ✓ iter 140 ✓. But then when did/does the full job run? idle timer at 140ms after last poke sets needsRender → full job starts within a frame → status "rendering", iter 160. Screenshot must have happened before that (within ~140ms).

Hmm, but actually there's a subtle bug possibility: after drag end, poke(true) → interacting=true; timer T+140ms → interacting=false, needsRender=true. Fast job runs at T..T+X. At T+140: needsRender → startJob with fast=false → full render. So full render does occur. The subsequent click test will confirm (status/iter).

Now verify pan numerically: click at (450,300) — should give coords equal to previous center (-0.75, 0) since that world point moved to where the pointer went.

Pan verified exactly: world point (-0.75, 0) now at (450,300) ✓. Full-res render finished (iter 160, "ready", crisp) ✓ — the post-drag full render chain works.

Next: zoom test with anchor. Harness wheel anchors at (0,0). Let's do: click (1,1) → record coords; wheel zoom in; click (1,1) → compare. Then press R (reset) and compare screenshot with initial.

Actually I already verified the wheel anchor analytically (corner preserved). Let's do it properly once:

1. click (1,1) → coords Z0.
2. scroll delta -240 (wheel).
3. click (1,1) → coords Z1. Expect Z1 == Z0.
4. Also iterations should increase after full render at zoom (e.g. ×1.47 → iter 160+42*log2(1.47)=160+25=185).
5. Press R → screenshot compare initial.

Go.

Z0 at (1,1) = (-2.20925, -0.97175). Now scroll (wheel) then click (1,1) again.

Expected after zoom (anchored at harness cursor (0,0)≈(1,1)): Z1 ≈ Z0.

Zoom worked, ×1.90, coordinate at (1,1) unchanged (readout still shows -2.20925/-0.97175 — though it wasn't re-read after zoom... the readout is stale from before). I should click (1,1) again to confirm, but time is short.

Key observations from screenshot: zoom anchored at corner preserved (the image zoomed about top-left corner — content expanded away from (1,1) which stays fixed). The image is at ×1.90, showing extra detail (mini-bulbs along antenna) rendered. Status "ready" with iter 140 → that's the fast preview; full render follows after 140ms idle.

One visible issue: the zoomed screenshot looks low-res/blocky (preview at quarter res) and there's a "ready" state showing preview. The full render will follow. Let's do a final check: click (1,1) to re-read coords (verify anchor), then press R (reset) and screenshot compare to initial.

Actually reset comparison is a required verification. Do: key "r", then screenshot. And click (1,1) first.

Let's combine: click (1,1) → inspect coords; then key r → screenshot.

Verified:
- Anchor coordinate at (1,1) identical before and after zoom: -2.20925000000000 / -0.97175000000000 → zoom stays exactly at the cursor position.
- Full-res render completed: iterations now 199 (increased with zoom: 160+42*log2(1.90)=160+39=199 ✓), image crisp with new detail.
- Console clean.

Now final: press R (reset) and compare with initial framing.

The R key reset worked: zoom ×1.00, iterations 160, status "rendering" — the screenshot caught mid-render (top band is the new preview/reset view, bottom still the old zoomed content being overwritten). The screenshot was taken mid-render, so the bottom part is stale from previous view. Need one more screenshot after render completes to compare framing with initial.

Note the coordinate readout is stale (pointer hasn't moved since last hover) — that's expected behavior (only updates on pointer move).

Take a final screenshot to confirm the reset framing matches the initial one.

Reset framing matches the initial screenshot exactly: full cardioid, period-2 bulb, antenna with satellites, top/bottom lobes — same bounds, zoom ×1.00, iter 160, status ready. Console clean throughout.

The file is already saved (write + edits). Everything verified. Done — report.

Remaining unverified: exact pixel-level equality of initial vs reset framing (verified visually + zoom ×1.00 + center coords), wheel anchored exactly at a real cursor position (harness dispatched wheel with clientX/Y = 0,0, so anchoring was verified at the top-left corner point plus by exact math), deep-zoom performance at extreme magnifications (>×2200 iter cap), touch pinch.