Mandelbrot explorer · mimo-v2.6-pro

Let me build the index.html file.

Key features:
- Full-screen canvas, Mandelbrot escape-time smooth coloring, distinct inside color.
- Initial view: main cardioid and lobes (e.g., x from -2.2 to 0.8, y from -1.35 to 1.35 roughly).
- Drag to pan, wheel zoom centered on cursor.
- Recompute after navigation (not scale static image). Progressive rendering with sufficient iterations increasing with zoom.
- Reset view button. preventDefault on wheel.
- Keep controls responsive during rendering: render in chunks using requestAnimationFrame, maybe Web Worker via Blob... but single file — workers via Blob URL are allowed (no network). But simpler: chunked rendering on main thread with rAF and a "rendering" status. Use device-pixel-scaled canvas maybe capped.

Let me write efficient JS: typed arrays, ImageData, chunked rows per frame with time budget.

Smooth coloring: mu = n + 1 - log(log|z|)/log(2). Color via palette function with cos gradients.

Iteration count: base 200, increase with zoom: maxIter = clamp(120 + 120 * log2(zoom)/... ) Let's do: iter = Math.min(4000, Math.floor(180 + 120 * Math.log2(initialWidth/viewWidth))) something. Actually standard: iterations scale with sqrt of zoom or log. Use maxIter = clamp(256 * pow(zoom, 0.15), 256, 5000)? Simpler: maxIter = Math.min(6000, Math.floor(200 + 110 * Math.log2(zoomFactor))). Zoom factor from initial.

Rendering resolution: cap at devicePixelRatio 1 or 2 for performance; chunked rendering with time slice ~12ms per frame.

Interaction: pointerdown/move/up on canvas. During drag, we can recompute on drag end (or continuously cheap preview). Requirement: "Recompute the fractal after navigation rather than scaling a static image." During drag, keep controls responsive — render after drag ends and also render preview during drag at low iterations? Simplest: during drag show a translated preview using the previous image? That would be scaling a static image... Actually requirement says recompute after navigation rather than scaling static image. During drag we can just render with reduced iterations quickly (e.g., every 150ms schedule a low-iter render). Let's do: during drag, don't render (or render low-iter on rAF with throttle). After drag end, render full quality. That's acceptable: "Recompute the fractal after navigation".

Better: during drag, render at half resolution with low iterations throttled to avoid jank. Keep it simple: on drag, mark dirty and schedule a low-quality render after 60ms of inactivity... Hmm, maybe just render on each rAF with a cheap quality (iterations ~ 1/4, scale 0.5) — that's recompute, keeps responsiveness.

I'll implement a render engine:
- state: centerX, centerY, scale (width in complex units)
- render(quality): quality {scaleFactor: 0.5 or 1, iterFactor}
- Chunked: process rows, time-budget 12ms per rAF frame; on completion, putImageData.
- Use a generation counter to cancel in-flight renders when a new one starts.

Also zoom wheel: wheel deltaY, factor = exp(-delta*0.0015) etc., keep complex point under cursor fixed.

Also add zoom buttons? Not required but nice: + / -, Reset. Also show coordinates and zoom level, iteration count. Keyboard maybe.

Let's write it.

Rendering pixel math:
```
const w = canvas.width, h = canvas.height;
const viewW = scale; // complex units across width
const viewH = viewW * h / w;
x0 = cx - viewW/2, y0 = cy - viewH/2 (y increases upward? typically image y down = decreasing imaginary)
```
For row j: im = cy + viewH/2 - (j+0.5)*viewH/h. Actually simpler: im = cy + ( (h/2 - (j+0.5)) * viewH/h ).

Coloring:
```
function colorize(t) // t = smooth iteration
```
Use palette: multi-stop cosine palette:
```
r = 255*(0.5+0.5*cos(a*t+b))
```
with a ~ 0.1, etc. Or a gradient over stops. Let's use a nice palette: classic blue-gold. t normalized: v = t / maxIter? Better absolute smooth value to keep colors consistent as iterations grow: use t directly with palette cycling frequency scaled slightly by log. I'll use hue mapping: h = (0.95 + 0.12*t) % 1 ... hmm.

I'll use cosine palette:
```
function palette(t) {
  const s = t * 0.045; // scale
  r = 0.5 + 0.5*cos(6.2832*(s + 0.00));
  g = 0.5 + 0.5*cos(6.2832*(s + 0.10));
  b = 0.5 + 0.5*cos(6.2832*(s + 0.20));
}
```
Plus brightness smoothing with sqrt to make interior banding. Fine.

Inside color: deep dark navy/black, e.g. rgb(5,8,20) — distinct from the gradient. Make sure palette at t=0 is not near-black... With cosine palette at s=0: r=1, g=0.65..., b≈0.35 — bright. Good, distinct from dark interior.

Actually to avoid interior looking identical to dark band values, use interior = near-black with maybe slight blue: (8,10,24). Palette min values are 0 for some channels... Let's use palette scaled 0.5..1 range so it never gets very dark: r = 0.35+0.35*cos(...)? Then interior black is distinct. Let's do amplitude 0.45, offset 0.55: range 0.1..1.0. Hmm min 0.1*255=26 vs interior 8. Distinct enough. I'll make interior (0,0,0) and palette min ~0.12. Hmm, maybe better interior = solid black is classic and clearly distinct. Let's use interior rgb(0,0,0)? The spec says "distinct color for points treated as inside the set" — black is distinct. But maybe more visually appealing: dark magenta? I'll use very dark blue-black (6,6,14) and palette bright.

Anti-aliasing: optional supersampling 2x2 for final quality? That's expensive. Skip, or offer in "high quality" pass at scale 1 with 2x sample... Keep it simple: no AA.

Iteration cap and bailout radius: 4 (bailout 256 for smoother log). Use bailout 1<<16? Use 256 for smooth coloring: mu = n + 1 - log(log|z|)/log(2).

Chunked rendering details:
```
let renderJob = null;
function requestRender(quality) { ... start if not running, else replace pending }
```
Implement:
```
let currentJob = null; // {gen, ...}
let pendingJob = null;
function scheduleRender(opts) {
  if (running) { pendingJob = opts; return; }
  startRender(opts);
}
```
In rAF loop: process rows until budget exceeded or done; if done → putImageData, then if pendingJob start it.

Also during drag use low quality (pixelStep 2, iterFactor 0.35), and full quality on release / after navigation.

Wheel: also debounce a full-quality render after zoom settles (e.g., 120ms timeout) — render low-quality immediately, full after idle. But requirement says recompute after navigation. Low quality render during zoom is a recompute too. Good.

Coordinate readout: mouse position → complex coords.

Canvas sizing: on resize, set canvas.width = innerWidth * dpr (cap dpr at 2 maybe, or use 1 for speed). Let's cap dpr at 1.5 or use min(dpr,2). For performance with chunked rendering, fine.

Let me also include a small HUD: title, buttons (Reset view, zoom in/out, quality toggle?), status "Rendering… / Ready", iteration count, zoom level, cursor complex coord.

preventDefault on wheel: add listener with {passive:false} on canvas and also on window? "Prevent wheel navigation from scrolling the surrounding page" — attach non-passive wheel listener on the canvas that calls preventDefault. Maybe also on document body to be safe. I'll attach to canvas with passive:false and preventDefault always.

Pointer events: use pointerdown/move/up with setPointerCapture. Also handle touch pinch? Not required; but pointer events handle single touch drag. Skip pinch (optional bonus — maybe implement simple two-pointer pinch zoom, nice but time). Keep it: simple pinch support would be nice but not required. Skip to save time; maybe add quickly if easy. I'll skip.

Now let's write the file.

Color mapping code per pixel loop with inner loop. Performance: typical 1200x800 = 960k pixels, maxIter maybe 400. Fine chunked.

Let me write the smooth color:
```
if (n >= maxIter) { inside }
else {
  const log_zn = Math.log(x*x+y*y)/2;
  const nu = Math.log(log_zn/Math.LN2)/Math.LN2;
  const smooth = n + 1 - nu;
  // color
  const s = Math.sqrt(smooth) * 0.09 ... 
}
```
Use t = smooth; palette argument = 0.035*smooth + offset? With sqrt scaling, colors change slowly at high iteration counts... Standard: use smooth directly with modest frequency; also add a slight log-based modulation so deep zooms don't just show uniform bands. I'll use: v = Math.log(smooth + 1) * 3.0 maybe. Hmm. Let's use combination: arg = 0.045 * Math.pow(smooth, 0.92). Eh.

I'll do: s = smooth; base = Math.sqrt(s) * 0.35; that gives nice progressive bands. Let's just test visually in browser and adjust.

Palette function (precompute 2048-entry LUT for speed):
```
const LUT = new Uint8Array(2048*3);
for i: u = i/2048; 
  r = 0.5+0.5*cos(TAU*(u*1.0 + 0.00));
  ...
```
And map t → index via fract of something.

Let me define: idx = ((Math.sqrt(smooth)*0.13) % 1) * 2048 → sqrt grows slowly so bands get wider at higher iterations — that's typical and pretty.

Hmm, at deep zoom smooth values become huge; sqrt(10000)=100, *0.13 = 13 → cycles fine.

OK. Let's write.

Structure of render function:

```
function render(quality) {
  const gen = ++renderGen;
  const canvas = ...
  const w = canvas.width, h = canvas.height;
  const step = quality.step; // 1 or 2
  const maxIter = quality.iter;
  const img = ctx.createImageData(w,h) — expensive each time? use persistent ImageData buffer sized to canvas.
  ...
}
```
Use a persistent ImageData created on resize.

For step=2 rendering, fill 2x2 blocks in the image data.

Row loop with `let row = 0;` and closure in rAF.

Implementation plan:

```
const jobs = [];
let activeJob = null;
function scheduleRender(job) {
  if (activeJob) { pendingJob = job; return; }
  startJob(job);
}
function startJob(job) {
  activeJob = job; job.row = 0; job.gen = ++gen;
  setStatus('Rendering…');
  requestAnimationFrame(stepJob);
}
function stepJob() {
  if (!activeJob) return;
  const t0 = performance.now();
  while (activeJob.row < h && performance.now() - t0 < 14) { renderRow(activeJob); activeJob.row += step; }
  if (activeJob.row >= h) {
    ctx.putImageData(imgData,0,0);
    activeJob = null;
    setStatus('Ready');
    if (pendingJob) { const j = pendingJob; pendingJob = null; startJob(j); }
    else maybeRunQualityUpgrade();
  } else requestAnimationFrame(stepJob);
}
```

Quality upgrade: after a low-quality render completes and no pending job and no interaction for some time, run full quality. Implement with a debounce: on any interaction, set `lastInteract = now`; in stepJob completion, if job was preview quality and quiet time > 150ms → schedule full render. Simplest: interaction handlers call `schedulePreview()` then set timeout 180ms to `scheduleFull()`. With generation-based cancel via pendingJob replacement, that works.

Let's write the code cleanly.

Wheel zoom:
```
canvas.addEventListener('wheel', e => {
  e.preventDefault();
  const rect = canvas.getBoundingClientRect();
  const px = e.clientX - rect.left, py = e.clientY - rect.top;
  const factor = Math.exp(-e.deltaY * (e.deltaMode === 1 ? 0.05 : 0.0015));
  zoomAt(px, py, factor);
}, {passive:false});
```
zoomAt: compute complex point under px,py before; change scale; then adjust center so that point maps to same pixel.

```
function screenToComplex(px, py) {
  const w = canvas.clientWidth, h = canvas.clientHeight;
  const vw = view.scale, vh = view.scale * h / w;
  return { re: view.cx + (px/w - 0.5)*vw, im: view.cy - (py/h - 0.5)*vh };
}
```
Then after zoom: view.scale /= factor (factor>1 zoom in). new complex coordinate of pixel should stay: c = cx' + (px/w-0.5)*vw' → cx' = c.re - (px/w-0.5)*vw'.

Also clamp scale between 1e-14 and 4.

Pan drag: on pointermove with drag: delta pixels → complex delta: dcx = -dx/w*vw, dcy = +dy/h*vh. Set center accordingly, schedule preview render.

For smooth dragging experience, preview render at step 2 and low iters.

Reset: set view to initial {cx:-0.6, cy:0, scale:3.2}? Initial must show complete main cardioid (x from -2 to 0.47) and surrounding lobes (period-2 bulb at x=-1.25 to -0.75... actually the main cardioid spans -0.75..0.375? Let's compute: main cardioid x range approx [-0.75, 0.4]? The cusp at 0.25, left at -0.75. The period-2 bulb is centered at -1 with radius 0.25, so extends to -1.25. The antenna goes to -2. So x range [-2.1, 0.6] shows everything. With scale=3.2 centered at cx=-0.7: x from -2.3 to 0.9. y range = scale*h/w; at 1200x800 → 3.2*0.667=2.13, y ±1.07. Mandelbrot y extent is ±1.25 approx? The set's imaginary extent is about ±1.0? Actually the top of the set is at i*1.0? The largest imaginary part of the set is about 1.0 (near -0.5+0.86i? hmm). The set lies within |im| <= 1.0? Known: the set is contained in |z| <= 2 and im range roughly [-1.12, 1.12]? Let me think: the point -0.5 + 0.866i is on the cardioid boundary (the cusp region), cardioid top at about... Parametrize cardioid: c = e^{it}/2 - e^{2it}/4. At t=π/2: c = i/2 - (-1)/4 = 0.25 + 0.5i. Max imag of cardioid: derivative... approx 0.65? Actually c(t)=0.5e^{it} - 0.25e^{2it}; imag = 0.5 sin t - 0.5 sin t cos t = 0.5 sin t (1 - cos t). Max over t: at cos t = 0.5, sin t = 0.866: 0.5*0.866*0.5 = 0.2165? That seems small. Hmm: 0.5 sin t (1-cos t), at t=2π/3: 0.5*(0.866)*(1.5)=0.6495. Yes ~0.65. So main cardioid max imag 0.65. But the whole set has bigger imag extent from the bulbs: max imag of set ≈ 1.0? The point where the "seahorse" valley... Known fact: the Mandelbrot set's imaginary range is about [-1.0, 1.0]? Hmm, actually the set's max |Im| is approximately 1.0 — hmm, let me think of the point -0.75 + 0.3i... The set is contained in |c| <= 2 and known the topmost point is around i (e.g., near c = -0.5+0.86i? no).

Let me just be safe: scale=3.4 centered cx=-0.75, cy=0 gives x∈[-2.45, 0.95], y∈[-1.13,1.13] at 3:2 aspect. That covers the whole set comfortably. Fine — "Initially show the complete main cardioid and surrounding lobes."

Actually for wide screens (16:9), vh = 3.4*9/16 = 1.9 → ±0.96. The set imag extent ~1.0? To be safe use scale = 4.0 with cx=-0.7 → x∈[-2.7,1.3], y ±1.12 at 16:9. Hmm the whole set fits then. Let's use cx=-0.7, scale=3.6. At 1200x800 (3:2): vh=2.4, y ±1.2 ✓. At 16:9: vh=2.03, y±1.0. Set imag extent: I recall the topmost point of the Mandelbrot set is at imaginary ≈ 1.0? Hmm. Let me just compute quickly? I could do a quick numeric check in node... Actually the max |Im| of the Mandelbrot set: The set's boundary includes points like -1.25 (period-2 bulb left). The imag extent is around ±1.0? Hmm let me think: c = i is not in the set? |i| = 1, orbit: 0 → i → -1+i → -i → -1+i... bounded! So i is in the set! Actually z→ z²+i: 0→i→i²+i = -1+i → (-1+i)²+i = (-2i)+i = -i → (-i)²+i = -1+i ... cycles. So c=i is in the set. So imag extent ≥ 1.0. Is c = 1.05i in the set? z: 0 → 1.05i → -1.1+1.05i → ...? Let's not; approx max Im ≈ 1.0 to 1.13? Actually known: the Mandelbrot set is contained in the disk |c| ≤ 2, and the max imaginary part is exactly... hmm.

Safe: use scale 4.2, cx = -0.7. At 16:9 vh = 2.36, ±1.18 ✓. At 3:2 vh=2.8, ±1.4. The set appears a bit smaller but complete. Fine — verify visually in the browser.

Hmm but "Initially show the complete main cardioid and surrounding lobes" — fine.

Now write the code. I'll include:

HTML:
```
<div id="app">
  <canvas id="fractal"></canvas>
  <div id="hud"> ... top bar with title and buttons ... </div>
  <div id="readout"> bottom-left: coords, zoom, iterations, status </div>
  <div id="hint">Scroll to zoom · Drag to pan</div>
</div>
```

CSS: full-screen fixed canvas, glassy buttons, monospace readout.

JS in an IIFE.

Let me write the whole thing now.

Details of the row render:

```
function renderRows(job, budgetMs) {
  const { w, h, step, maxIter, buf32 } = ...
  const vw = job.scale, vh = job.scale * h / w;
  const x0 = job.cx - vw/2, yTop = job.cy + vh/2;
  const pxScale = vw / w;
  const data = imgData.data;
  while (job.row < h && performance.now() - start < budget) {
    const im = yTop - (job.row + step*0.5) * (vh/h);  // careful
    for (let col = 0; col < w; col += step) {
      const re = x0 + (col + step*0.5)*pxScale;
      ... compute color int
      // write block
      for (let dy=0; dy<step && job.row+dy<h; dy++) {
        let idx = ((job.row+dy)*w + col)*4;
        for (let dx=0; dx<step && col+dx<w; dx++) { data[idx++]=r; ... }
      }
    }
    job.row += step;
  }
}
```

Use a Uint32Array view of imageData.data for fast writes with little-endian ABGR. Simpler to write bytes; but 32-bit view is faster. I'll use buf32 = new Uint32Array(imgData.data.buffer) and pack (255<<24)|(b<<16)|(g<<8)|r. Need to handle block writes similarly.

Color LUT: Uint32Array of packed colors.

Let me write final code.

```
const PALETTE_SIZE = 2048;
const lut = new Uint32Array(PALETTE_SIZE);
for (let i=0;i<PALETTE_SIZE;i++){
  const u = i/PALETTE_SIZE;
  let r = 0.5+0.5*Math.cos(TAU*(u+0.00));
  let g = 0.5+0.5*Math.cos(TAU*(u*1.0+0.10));
  let b = 0.5+0.5*Math.cos(TAU*(u*1.0+0.20));
  // slight contrast
  r = 0.06 + 0.94*Math.pow(r, 0.85);
  ...
}
```
Hmm, maybe simpler nicer palette. Let's use a custom multi-band gradient instead, e.g. deep blue → cyan → gold → dark red → purple, interpolated, plus cyclic. I'll do a stop-based palette:

stops: 
0.00 (12, 20, 60) dark navy
0.16 (20, 60, 140) blue
0.32 (60, 160, 220) cyan
0.48 (150, 220, 190) seafoam
0.62 (245, 230, 150) pale gold
0.76 (230, 140, 60) orange
0.88 (150, 50, 90) magenta-red
1.00 (12,20,60) wrap around

Interior black (0,0,0)? If palette starts dark navy at u=0 and interior is black, they'd be similar-ish but distinct. Let's make interior pure black (0,0,0) and start palette at navy with min brightness low... For distinctness, maybe interior = black and palette minimum brightness is a bit higher: navy (30,40,90). Good.

Actually "smooth escape-time color gradient" — cyclic gradient is fine.

Map: u = (Math.sqrt(smooth) * 0.085 + 0.05) % 1? Let's tune in browser. I'll go with u = fract(Math.sqrt(smooth)*0.12 + 0.15).

Hmm, let me instead use a non-cyclic mapping with an outer contour: since deep zoom shows many bands, cycling is needed. Fine.

Write the code now. Also include an optional "high quality supersample" — skip.

Also handle keyboard: '+'/'-' zoom at center, 'r' or '0' reset. Nice extras.

Status readout: zoom factor = INITIAL_SCALE / view.scale formatted as "×1,234".

Let me now write the file.

One more thing: chunked rendering keeps controls responsive — buttons work since we return to event loop each ~14ms.

Also cancel/restart: when new interaction happens mid-render, we want the render to reflect the new view. Approach: keep a single "desired" state; the active job captures a snapshot of view at start. If view changes during render, we set pendingJob = new snapshot and let current job finish? Wasteful. Better: abort current job immediately (activeJob = null) and start the new one. But then rapid dragging causes constant restarts and never completes — fine because preview is cheap and drag-end triggers full render. But there might be visible partial images... Since we putImageData only at completion, partial results aren't shown — during drag the canvas keeps old image until preview completes. Preview at step 2 should complete fast (~ maybe 30ms for 600x400 points at low iters). Acceptable.

Actually better: show partial render progressively? Could putImageData the whole buffer each frame — but the buffer contains stale pixels from the previous render in unrendered rows, causing a mixed image. Could clear buffer at start of job... then progressive reveal. Let's do progressive: clear the image data at job start (fill with background black), and call putImageData after each chunk when quality is preview? That gives progressive display which is nice. Hmm, putImageData of full 1200x800 each frame is ~4MB copy — a few ms. Acceptable at 60fps? Maybe. I'll do putImageData each chunk only if job.row advanced and it's the full-width buffer — cost fine.

Let me just do it: after each chunk, ctx.putImageData(imgData, 0, 0). And clear at job start with buf32.fill(0xFF000000... ) interior color.

But careful: with step=2, progressive display shows rendered blocks over black — fine.

Edge case: when aborted mid-job (new job replaces), the buffer is shared and cleared by the new job — fine.

Implementation of scheduling: 
```
function requestRender(opts) {
  const job = { ...view snapshot, ...opts, row:0 };
  if (activeJob) { activeJob.cancelled = true; }
  pendingJob = job;
  pump();
}
function pump() {
  if (activeJob || !pendingJob) return;
  activeJob = pendingJob; pendingJob = null;
  activeJob.row = 0; buf32.fill(INTERIOR);
  requestAnimationFrame(tick);
}
function tick() {
  const job = activeJob; if (!job) return;
  if (job.cancelled) { activeJob = null; pump(); return; }
  ... process ...
  if (done) { ctx.putImageData(...); activeJob=null; setStatus(...); onJobDone(job); pump(); }
  else { ctx.putImageData(...); requestAnimationFrame(tick); }
}
```
Hmm cancelled jobs: when requestRender called while activeJob running, set activeJob.cancelled = true and pendingJob = job; then in tick, it stops and pump starts new. But if tick is not scheduled... it is (rAF pending). OK but pump() from requestRender while activeJob exists does nothing; when tick sees cancelled → activeJob=null, pump() starts pending. Good.

Wait: onJobDone triggers quality upgrade scheduling. Let's do simpler: interaction handlers call `queuePreview()` and set a timer `queueFull()` after 200ms of no interaction. And wheel does the same. That covers everything, no need for onJobDone.

But if a full render is queued while a preview is active, requestRender replaces → fine.

Timers: `let idleTimer; function interact() { clearTimeout(idleTimer); idleTimer = setTimeout(() => requestRender(fullOpts()), 220); }` and each interaction also calls requestRender(previewOpts()) immediately? For wheel, calling requestRender on every wheel event restarts rendering constantly, so nothing ever completes until the user stops → image frozen while zooming (shows old image scaled? No—canvas is not transformed, so it shows the old image entirely, which looks wrong during zoom). Better to throttle preview renders: only start a preview render if none active and at most every ~50ms, using rAF-based dirty flag:

```
function markDirty(quality) { dirty = true; dirtyQuality = quality; if(!rafScheduled) rafScheduled = requestAnimationFrame(processDirty); }
function processDirty() { rafScheduled=0; if (dirty) { dirty=false; requestRender(...) } }
```
Hmm complexity. Simplest approach that performs well: during wheel zoom, immediately requestRender(preview) on each wheel event but with cancel-restart — restart means each render starts over; with wheel events at 60Hz and preview taking ~20ms, we'd restart before completion and never show anything... unless we don't cancel the active job and instead queue pending to run after. Let's do: if activeJob running and not cancelled, set pendingJob = job (replacing any earlier pending) but DON'T cancel active job. Then the active job (old view) completes and displays briefly, then the new job runs. That's a "stale frame shown" but it's a recomputed image of the previous state — visually during zoom it shows slightly stale frames at ~30fps-ish. Acceptable and simple.

But during drag with continuous updates, the queue length is 1 pending — fine, renders keep up at whatever rate.

Actually during a drag, previews take maybe 20-40ms; the pending job updates to latest mouse pos. Good responsiveness.

But there's an issue: a stale full-quality render of an old view could block previews for a long time. Solution: mark jobs with priority; if a new preview arrives and the active job is a full-quality stale job (its snapshot doesn't match current view), cancel it. Let's implement: `activeJob.cancelled = true` when a new job arrives AND activeJob.quality !== 'preview'... hmm.

Simpler: cancel active job if a new job arrives and the active job is "stale" (its view snapshot differs from current view) — meaning it's rendering something the user has moved away from. If the active job matches current view (e.g., a full-quality upgrade queued after a preview), just queue.

Define viewKey = cx,cy,scale,step,maxIter... Let's compare a simple signature string/number. Implement:

```
function sameView(a, b) { return a.cx===b.cx && a.cy===b.cy && a.scale===b.scale && a.w===b.w && a.h===b.h; }
function requestRender(opts) {
  const job = {...};
  if (activeJob && !sameView(activeJob, job)) activeJob.cancelled = true;
  pendingJob = job;  // latest wins
  pump();
}
```
If activeJob cancelled, its tick will stop and pump starts pending. If activeJob same view (e.g. full-quality same view as completed preview), we let it... wait, activeJob is running; if same view, we set pendingJob = job and let active finish first, then run pending (which may be higher quality). Fine.

Good. Also if activeJob is cancelled and pendingJob replaced, fine.

Now: preview opts: step=2 (or 3 on very large canvases), maxIter = base*0.45. Full opts: step=1, maxIter = full.

Let me now determine maxIter based on zoom:
```
const zoom = INITIAL_SCALE / view.scale;
const maxIter = Math.round(Math.min(5000, 160 + 110 * Math.log2(Math.max(1, zoom)) + 60*Math.sqrt(zoom)??));
```
Keep it: maxIter = clamp(Math.round(180 + 120*Math.log2(zoom)), 180, 4000). At zoom 1e6, log2 = 20 → 2580. OK.

Also display maxIter in readout.

Now writing the actual file.

Also: "keep controls responsive during rendering" — chunked rAF rendering with 12ms budget ✓.

Resize handling: update canvas size and re-render.

Let me write it.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<title>Mandelbrot Explorer</title>
<style> ... </style>
</head>
<body>
<canvas id="fractal"></canvas>
<div id="topbar">
  <div id="title">Mandelbrot Explorer</div>
  <div class="controls">
    <button id="zoomIn" title="Zoom in">＋</button>
    <button id="zoomOut" title="Zoom out">－</button>
    <button id="reset">Reset view</button>
    <button id="toggleHud">?</button>  (maybe skip)
  </div>
</div>
<div id="readout">...</div>
<div id="hint">Drag to pan · Scroll to zoom · R to reset</div>
<script>...</script>
</body>
</html>
```

Careful with the "＋" fullwidth chars — use simple text "+", "−", "Reset view".

Now the JS in detail. Let me write it out in the write call.

For the LUT-based palette with stops:

```js
const STOPS = [
  [0.00, [25, 32, 78]],
  [0.14, [28, 92, 170]],
  [0.30, [56, 168, 214]],
  [0.45, [138, 222, 205]],
  [0.58, [232, 232, 168]],
  [0.70, [238, 166, 76]],
  [0.82, [176, 66, 96]],
  [0.92, [70, 28, 96]],
  [1.00, [25, 32, 78]],
];
```
Build LUT of 2048 packed.

Interior packed: (255<<24)|(0<<16)|(0<<8)|0 = 0xFF000000 → black. Maybe interior = very dark distinct color like (5,5,12) — just black is fine and clearly distinct from palette min (25,32,78). Use 0xFF0D0A1F? I'll use near-black blue-black rgb(8,10,26)? Then it might be confused with navy stop. Black it is. Hmm "distinct color for points treated as inside the set" — pure black is the classic. OK.

Write the file now.

smooth → u mapping: 
```
const t = n + 1 - Math.log(Math.log(mag)/2)/Math.LN2; // mag = x*x+y*y
const u = (Math.sqrt(t) * 0.115 + 0.02) % 1;
```
Hmm need to check banding aesthetics in browser. Also add subtle shading? Keep simple.

Wait, careful with log: mu = n + 1 - log2(log2(|z|)) where |z| = sqrt(x²+y²). log_zn = Math.log(x*x+y*y)*0.5; nu = Math.log(log_zn/Math.LN2)/Math.LN2.

Bailout radius squared: 256 (so log_zn is stable).

Inner loop escape check: `if (x2 + y2 > 256) break;` compute with x2,y2 variables.

Code:
```
let zx = 0, zy = 0, x2 = 0, y2 = 0, n = 0;
while (n < maxIter && x2 + y2 <= 256) {
  zy = 2*zx*zy + ci; zx = x2 - y2 + cr; x2 = zx*zx; y2 = zy*zy; n++;
}
```

Now the whole render loop.

Let me write the file with `write`.

I'll also add pointer capture and prevent default on drag to avoid text selection.

Time to write. I'll keep code tight but complete.

Regarding canvas sizing and coordinate mapping between client pixels and canvas pixels: use clientWidth/clientHeight for mapping in screenToComplex; canvas.width = clientWidth*dpr. Rendering fills whole canvas. Fine.

Write now.

const INITIAL = { cx: -0.7, cy: 0, scale: 4.0 };

Hmm, at 1200x800 the set will look small-ish but complete. Let me use scale 3.6, cx -0.65. x∈[-2.45,1.15], y ±1.2 at 3:2. Good.

But for ultrawide/short windows, vh = scale*h/w may be small; e.g. 1200x400 → vh=1.2, ±0.6 → set clipped vertically. To guarantee "initially show complete set", compute initial scale so that both x and y fit: required width 3.2 (from -2.2 to 1.0) and required height 2.4 (±1.2). So scale = max(3.2, 2.4*w/h). Hmm at 1200x800: max(3.2, 2.4*1.5=3.6) = 3.6. At 1920x1080: max(3.2, 2.4*1.78=4.27)=4.27 → set appears smaller but complete. That's the safe approach; and Reset restores exactly this framing computed for the current window. Good, do that.

So `initialView()` returns {cx:-0.65, cy:0, scale: Math.max(3.3, 2.5*aspect)}.

Now code writing.

For the readout, update on pointermove and after renders.

Let me write it.

Empty dir. Write index.html.

I left some junk in pointermove pan math (a messy no-op line) and duplicated render loop functions (drawJob unused). Let me clean up: pointermove should call panByPixels, remove the weird lines and the unused drawJob function.

Wait — in pointermove, `const w` and `const h` were used by the removed code... I removed that declaration in edit 3, good. But `panByPixels` is declared after use — function declaration hoisting handles it (it's a function declaration inside the IIFE). Fine.

Now run in browser.

Now run in the browser tool. Let me reload / inspect. The browser tool runs index.html in cwd presumably. Let's start with screenshot and inspect console.

The image is partially rendered (progressive: top half rendered, bottom half is black = cleared/interior fill). Rendering is in progress. Also issues:

1. The palette looks mostly one blue — the gradient cycling seems off. Actually this is likely mid-render, but the color mapping: u = (sqrt(smooth)*0.115 + 0.02) % 1. Smooth values near the set are large... hmm. The exterior is dominated by one hue — near the set smooth values are large and sqrt grows... Anyway it appears as gradient from light blue near the boundary to darker blue away. It's kind of monotone because sqrt scaling compresses. It looks decent but only blue. Palette cycles from navy→blue→cyan→green→gold→red→purple→navy; since u = sqrt(t)*0.115, over t=1..170, sqrt = 1..13, u spans 0.13..1.5 → about 1.4 cycles. But the image shows mostly blues. Hmm because far from the set, escape is quick (smooth values small → u near 0.02-0.2 = navy/blue). Near the set, smooth values up to 170 → sqrt=13*0.115 = 1.5 → cycles. But the visible picture seems mostly uniform blue for large regions. Maybe fine — the render was incomplete so the visible top portion was done and I see gradient near boundary (whitish, then yellow-ish fringe). Actually I see whitish/cream near the boundary — that's the palette cycling.

Wait — the top-left region is plain blue with little variation. That's a bit boring but the smooth gradient is working.

2. Big problem: the render is slow — the initial full render of 1200x800 at 170 iterations seems to be taking long (still rendering after reload). Actually it's progressive: the top rows rendered, bottom black. That's fine but I should check the render time. Let me wait and take a screenshot again to see the finished state.

Also the y-mapping: the image is upside down? The set appears with lobes... The main cardioid appears large at right with a bulb left — but the antenna (leftmost, x=-2) region appears at the far left as a black horizontal band at y≈0. Hmm the picture: black region at bottom half — that's unrendered. The set is at top. Wait the y mapping: im = yTop - (row + step*0.5)*dyPix. Correct: top of image = max imaginary. The set is drawn in the upper part? The set is centered at cy=0, so it should be centered vertically. The rendering only completed the top ~half. OK, consistent with progressive rendering.

But wait, the set is rendered upside-down? Main cardioid with period-3 bulbs — the cardioid is roughly symmetric about the real axis, and I see a symmetric shape at top... Looks fine.

Let me wait and screenshot again.

Also there's a horizontal black band across the middle at y≈395 — that's the boundary between rendered and unrendered. Fine.

Let me check the timing. I'll re-screenshot after a second or so.

Hmm, I can't easily "wait then screenshot" — the browser tool screenshots current state. Let me just take a screenshot now (time passed during my bash call).

Actually better: instrument via console. But simplest: screenshot now.

The full set renders nicely: complete main cardioid + bulbs + antenna visible. 

Issues to improve:
1. Color gradient: mostly blue with a thin gold fringe near the boundary. The smooth escape gradient is present but the cycling is too slow — most of the plane is one hue. It's acceptable ("smooth escape-time color gradient") but I'd like more varied bands. The u = sqrt(smooth)*0.115 mapping: far away smooth is small (~2-10) → u in 0.16-0.39 which spans navy→blue→cyan. But the picture shows blue dominating... Fine. To get more color variety across the image, use a higher frequency or use log-based mapping. Let me increase to 0.16 or use a mix: u = (sqrt(smooth)*0.09 + 0.02). Hmm.

Actually a more classic look uses bands that follow level sets. Since we see a smooth gradient blue→cyan→cream→gold near boundary, it is a smooth escape-time color gradient. But it's quite monochrome over large areas. Let me tune: use u = (Math.pow(smooth, 0.42) * 0.22 + 0.02) % 1 — that expands variation at low smooth values, giving more bands. Let's test visually.

Alternatively add more hue cycling frequency: multiply sqrt by 0.2. Let's experiment with pow 0.42 * 0.2.

2. Render time — initial render took maybe a few seconds? The first screenshot after reload showed partial. I don't know how long it took. Should measure. Let me add a performance log via console temporarily... or just run a quick node benchmark of the same loop for 1200x800 at 170 iterations. Actually the browser environment may be slower. Better: measure in-page via console.log of render duration. But the browser tool shows console output — I could add a temporary debug. Alternatively I can check via the "inspect" action for console messages. Simpler: do a quick node benchmark to gauge algorithmic cost.

Also potential inefficiency: putImageData every frame for full-size canvas each ~12ms slice. That's 1200*800*4 = 3.8MB copy per frame — maybe 2-4ms. That's significant overhead but OK-ish. Could reduce by only putting image data every other frame or using a dirty rect. Better: use ctx.putImageData with dirty rect of rows processed! putImageData(imgData, 0, 0, dirtyX, dirtyY, dirtyW, dirtyH). Let's do that — cheap.

Also the progressive display with `buf32.fill(INSIDE)` makes unrendered areas black (interior color) — visually reads as "inside" which is confusing during progressive render. Better to fill with a dark background color distinct from interior, or just don't clear (leave previous image). Leaving the previous image creates a mixed picture. Hmm. Actually progressive reveal from black is a common look. But black = interior color, misleading. Let me fill with a very dark slate (e.g. #05070f background = 0xFF0F0705?) and interior is pure black. That distinguishes them subtly. I'll use background (5,7,15) and interior (0,0,0). Hmm, they'd be quite similar... Let me make interior pure black and progress background a dark navy-purple (20,16,40)? That could be visibly different from black. Fine: progress fill = 0xFF241A2E (a dark plum). Actually simpler: make interior a distinct color that's not black — e.g. deep midnight blue (10, 14, 40)? But then far-field navy (22,30,74) is similar...

Keep it simple: interior = pure black (classic, clearly distinct from palette), progress fill = dark slate #12142a-ish (18,20,42). During the brief progressive render you'd see dark slate for unrendered rows. Good enough.

3. Zoom-at-cursor accuracy — I'll verify with a browser interaction: zoom at a point and check readout/visual.

4. Also the wheel handler on window with preventDefault might block scrolling of nothing (page doesn't scroll anyway). Fine.

5. Potential issue: `pointerleave` sets cursor readout to "-" while dragging... only when !dragging. Fine.

6. When dragging, `navigate()` triggers a preview render immediately on every mousemove → constant restarts? No — requestRender only cancels active job if view differs; during drag, view always differs → active job cancelled each move and new one starts. So renders essentially never complete during a fast drag; each tick restarts. Hmm: activeJob.cancelled = true, pendingJob = job, pump() does nothing since activeJob exists. Then tick sees cancelled → activeJob = null → pump starts pending. So each move event results in one chunk-ish of the previous job then restart. Actually the cancelled job does no work before being replaced (tick runs the slice? No — tick checks cancelled first and returns). So effectively during a drag we render a fresh preview starting from row 0 each time the previous job's tick fires. That means the canvas never updates during drag until the mouse stops... because no job ever completes. But progress is drawn via putImageData each tick — wait, the cancelled job does zero rows and puts nothing; then the new job starts and does 12ms of rows, puts image data (partial). So the canvas progressively shows partial renders of near-current state. Each new mouse move restarts. So visually during a fast drag you'd see partial images from the latest position — a "wipe" effect. Not great.

Better approach: when a new job arrives while one is running, don't cancel if the running one is a preview — just replace pendingJob and let the running one finish? That shows stale frames. Alternative: keep the active job but update its view parameters mid-flight (since view snapshot is read per row)! That's elegant: if activeJob is a preview with same step/maxIter, just update its cx/cy/scale and reset row to 0 — that's the same as restart.

Hmm. The cleanest for dragging: allow the render to show progressive rows from the current view, restarting each time but keeping already-drawn rows... no, that mixes.

Alternative: during drag, keep the display simple: don't restart rendering on every move; instead mark dirty and only start a new render when the current one completes (pendingJob = latest). Then during a drag, the canvas shows images that lag slightly behind (each render takes ~20-40ms at preview quality) but completes and updates. That's smooth-ish and always shows a complete recomputed image. The lag means the drawn fractal trails the pointer position slightly during a fast drag, then catches up. That's typical and acceptable.

So: never cancel active job; just replace pendingJob. But then a full-quality job that's stale could block for seconds. Mitigation: cancel active job only if it's a full-quality job (preview:false) and the new job is a navigation. Let's implement:

```
if (activeJob && (!job.preview || activeJob.preview === false) && !sameView(activeJob, job)) activeJob.cancelled = true;
```
Hmm, rule: cancel active if active is full-quality and new job is a navigation (i.e., view changed). If active is preview, let it finish (it's fast).

Let me write: 
```
if (activeJob && !sameView(activeJob, job) && (!activeJob.preview || job.preview === false && ...))
```
Getting confusing. Simpler rule: cancel active job only when the active job's view differs from the new job's view AND the active job is not a preview (i.e., it's expensive). Previews are cheap, so let them finish to keep the display live.

Wait but if active is a preview of an old view and a new preview comes in, letting it finish means ~20ms of stale image then new one. Fine.

Full-quality job active + user navigates → cancel immediately, run preview. Good.

So:
```
if (activeJob && !sameView(activeJob, job) && !activeJob.preview) activeJob.cancelled = true;
pendingJob = job;
```
Hmm but this loses the "latest wins" for preview-to-preview: pendingJob = job always replaces, so latest pending wins. Good.

Also if a preview job is pending and a full-quality job for the same view comes later (idle timer), pendingJob gets replaced by the full job — good, and queueFullQuality logic handles it.

But careful: idle timer sets queueFullQuality=true and only starts the full render if nothing active/pending; otherwise tick starts it at completion. But tick's completion branch: `if (pendingJob || activeJob) return;` then queueFullQuality → full render. Good.

Also preview quality during drag may take longer than 20ms; measure.

Let me also reduce preview cost: step 2 and 45% iterations.

7. Another improvement: render time for full quality. Let me benchmark in node quickly.

Let me do a node benchmark of the loop cost at 1200x800 (dpr 1) with 170 iterations.

Fast enough (in the browser sandbox it may be ~2-3x slower, still fine with chunking). Let me make the essential fixes quickly:

1. Better drag behavior (don't cancel previews, only cancel full-quality jobs when view changes).
2. Distinct progress fill vs interior color.
3. Slightly richer color cycling.

Then verify quickly with the browser and finish.

The smooth color line appears in drawRowsSlice only now (drawJob was removed). Let me check the exact text in file.

Only one occurrence of 0.115 line now. My edit 3's oldText included surrounding context with `for (let dy = 0; dy < step && row + dy < h; dy++) {` — let me verify the exact indentation. Line 380 region: let me read around 370-390.

The earlier failure was because edits[3] had the `for (let dy...` with 8 spaces indent in my oldText but file has 6 spaces. Fine. Note the earlier failed call means NO edits were applied (all-or-nothing?). The error said "Could not find edits[3]" — likely nothing applied. Let me verify: grep showed `buf32.fill(INSIDE)` still present at 312 and `ctx.putImageData(imgData, 0, 0)` at 330 → yes nothing applied. Re-apply with corrected oldText for edit 3 (just the single line).

Note: the smooth-color line appears only once now (drawJob removed), good.

Also the `tick()` uses `drawRowsSlice` which advances job.row one row-group per call; the progressive putImageData uses lastDrawnRow → fine.

Now reload and test: initial render, wheel zoom at a boundary point (e.g., near -0.75+0.1i or the "seahorse" valley), pan via drag, then Reset view. Use browser drag and key presses. Wheel: the browser tool has no wheel action... I can use `click` and `key` and `drag`. For wheel zoom I can simulate by dispatching wheel events via... no eval tool. Hmm — the browser tool actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. `scroll` with delta probably performs a mouse wheel scroll at x,y! That would trigger my wheel handler. Let's use scroll at a coordinate on the canvas with a delta.

Also test buttons: click +, −, Reset view.

Let me reload first.

Note the pointermove handler still references `const w = canvas.clientWidth...`? I removed that declaration in edit 3 of the earlier successful call — but wait, that earlier call succeeded ("Successfully replaced 3 block(s)"). Then panByPixels uses w,h locally. Let me double-check pointermove block quickly.

Good. Now reload and test in browser: 
1. Initial framing.
2. Scroll (wheel) zoom near a boundary point, e.g. (700, 400) center-ish near the cardioid boundary... Let's pick the cusp region or the seahorse valley near (-0.75, 0.1) in complex → screen coords? Initial view cx=-0.65, cy=0, scale=max(3.3, 2.55*aspect). Viewport 1200x800 → aspect 1.5 → scale = max(3.3, 3.825) = 3.825. vw=3.825, vh=2.55. Screen x for re=-0.75: px = (re - cx)/vw*w + w/2 = (-0.1/3.825)*1200+600 = 568.6. im=0.1 → py = h/2 - (im-cy)/vh*h = 400 - (0.1/2.55)*800 = 368.6. So click/scroll around (569, 369) = the seahorse valley between cardioid and the period-2 bulb. Good zoom target.

Let's scroll there several times with negative delta to zoom in, then screenshot and check that the point stays near the cursor and detail appears.

Then drag to pan, then click Reset view and compare with initial screenshot.

Let's go.

Colors are richer now. The bottom shows black — but PROGRESS_BG should be dark plum (20,18,42)... it looks black-ish in the screenshot. Hard to tell at this brightness. Fine.

Hmm, the bottom unrendered region appears black, not plum. Wait — maybe this is the completed image with the interior... no, the set is up top. The bottom half is unrendered rows still showing PROGRESS_BG (20,18,42) which is quite dark. OK.

Wait, actually the color mapping change made it cycle faster — but the earlier frame showed mid-render too. Note the image shows the set's top half rendered. Progressive rendering is working.

Now wait for it to complete, then test wheel zoom. I'll take screenshot later. Actually let me do a scroll (wheel zoom) at the valley point now — it will interact. But better to first see the completed image. Let me just proceed: scroll at (569, 369) with negative delta several times, then screenshot. The render is progressive so screenshots may catch partials.

The `scroll` tool action signature: x, y, delta. It probably scrolls at position. Let's do delta -400 at (569,369).

Something is wrong! The center jumped to (-1.554, 0.603) after a single wheel event at (569,369) — expected center would be near (-0.75, 0.1) region... Let's compute: before c at (569,369): re = -0.65 + (569/1200-0.5)*3.825 = -0.65 + (-0.0258)*3.825 = -0.7487; im = 0 - (369/800-0.5)*2.55 = -( -0.03875)*2.55 = 0.0988. So target ≈ -0.7487+0.0988i.

After zoom: scale = 3.825/1.9 = 2.013. New center = c - (px/w - 0.5)*vw, ... = -0.7487 - (-0.0258*2.013) = -0.6967; im = 0.0988 + (369/800-0.5)*vh = 0.0988 + (-0.03875*1.342) = 0.0468. So expected center ≈ -0.697 + 0.047i. But readout shows -1.554 + 0.603i! And the image shows the antenna region at left... 

Wait — the scroll action may not be a wheel event at that position; maybe the tool scrolls the page by some amount and my window-level wheel handler... Hmm. But the zoom factor changed (×1.90 = 3.825/2.013 ✓ consistent with exp(400*0.0016)=1.9). So a wheel event with deltaY = -400 occurred and zoom factor 1.9 applied. But the center moved way more than expected — it looks like the clientX/clientY used were not (569,369) but something else... Or the zoom was applied multiple times? Let's check: if the point under cursor was fixed at screen (569,369), the complex point -0.7487+0.0988i should stay at that pixel. In the rendered image, at pixel (569,369) we see... the top-left region is plain cyan/blue (exterior). Let's verify with the readout center: -1.554+0.603i with scale 2.013 → complex at pixel 569,369: re = -1.554 + (-0.0258)*2.013 = -1.606; im = 0.603 + 0.03875*1.342 = 0.655. That's not the original -0.749+0.099.

So the anchor point wasn't preserved. What happened? Possibly multiple wheel events fired (e.g., 2 events), or clientX/clientY are 0 in the synthesized event (mouse at 0,0?). If px=0,py=0 (top-left corner): before c = -0.65 + (-0.5)*3.825 = -2.5625, im = 0 + 0.5*2.55 = 1.275 — that's exactly the "cursor" readout value showing -2.5625 + 1.275i (which is the stale cursor readout from the initial pointerleave default... actually that's exactly screenToComplex(0,0)). So the synthesized wheel event has clientX=0, clientY=0! The tool's scroll action likely dispatches a wheel event without proper coordinates, or with coordinates but at page level... The cursor readout never updated, meaning pointermove never fired with (569,369) either.

Hmm, but the anchor math with (0,0): after zoom, center = c - (px/w-0.5)*vw = -2.5625 - (-0.5*2.013) = -2.5625+1.0065 = -1.556 ✓ matches -1.554! And im = 1.275 + (-0.5)*1.342 = 0.604 ✓ matches 0.603.

So the wheel event's clientX/clientY are 0 — the browser tool's scroll action doesn't pass coordinates to the wheel event (or it moves the mouse without firing pointermove... but then clientX/Y would still be set in the event... apparently not).

So I can't verify cursor-anchored zoom via the scroll tool with coordinates. But the math is correct given the event coords — I verified the anchor formula keeps the point under (0,0) fixed: the complex point that was at screen (0,0) i.e. -2.5625+1.275i remains at screen (0,0) after zoom. Indeed after zoom, screenToComplex(0,0) = center + (-0.5)*vw + i... = -1.554 - 1.0065 = -2.5605 ✓ and im = 0.603+0.671 = 1.274 ✓. So cursor-anchored zoom works correctly — verified numerically.

However, I should double check that the zoom is actually anchored on the real mouse position when a real mouse is used. The formula uses e.clientX/e.clientY which is correct for real wheel events.

To test more realistically, I could use the `drag` action which presumably fires pointer events with real coordinates. Let's test pan with drag and see if the readout updates (that would confirm pointermove coords work). Then test Reset view.

Also possible: the tool's scroll doesn't move the mouse at all. Fine.

Another way to verify cursor anchoring: use drag to move the mouse to (569,369) then... wheel still comes with 0,0. I can at least verify the anchor formula numerically as done.

Alternative: make the wheel handler fall back to the last known pointer position if e.clientX/e.clientY are 0 (some synthetic events). That's a nice robustness improvement: track lastPointer {x,y} from pointermove, and use e.clientX if it's non-zero else lastPointer. Hmm, but a legit wheel at (0,0)... rare. Actually a cleaner approach: track last mouse position via pointermove (also fires on hover) and use it when the wheel event has coordinates 0,0. I'll implement: `const px = (e.clientX || e.clientY) ? e.clientX : lastPointerX` — careful. Use: if (e.clientX === 0 && e.clientY === 0) use last known. Good.

Then with the tool I can move the pointer via drag/hover to (569,369) and then scroll → anchored zoom at that point. Wait, but does the drag action fire pointermove with coords? Let's test.

Let me first test drag pan and reset. Then implement the fallback and verify zoom anchoring visually at the valley.

Plan:
1. Implement lastPointer fallback in wheel handler.
2. Reload, drag from (600,400) to (700,300) — pan.
3. Screenshot, check center changed.
4. Click Reset view → compare to initial framing.
5. Then zoom test: drag/pointer to (569,369) (a small drag that cancels out? drag from 569,369 to 571,371 would pan slightly) then scroll zoom → screenshot: the valley point should stay near (569,369) and detail appears.

Time is short (5 min). Let's be efficient: do the edit, reload, then drag, screenshot, reset, screenshot, then pointer+scroll, screenshot.

Note: pointermove handler declares `const pt = screenToComplex(...)` and lastPointerX is declared later with `let` in the interaction section — TDZ! `let lastPointerX` declared at "let dragging" section which comes AFTER the canvas.addEventListener("pointermove"...) registration? Let me check order: In the file, the interaction section defines `let dragging...` then adds pointerdown listener, then pointermove listener. The `let lastPointerX` is in the same block before pointerdown. And the pointermove callback runs later at runtime — fine (no TDZ at runtime since declarations execute at load).

Now reload and test pan + reset.