Mandelbrot explorer · glm-4.7-flash

Let me build the Mandelbrot explorer. I'll write a single index.html with a canvas, progressive rendering (progressive refinement / tiled rendering in a worker-less async chunked approach), smooth coloring, pan/zoom.

Key design:
- Full-screen canvas.
- View state: center (cx, cy), scale (units per pixel).
- Progressive rendering: render at increasing resolutions / chunked rows using setTimeout/requestIdleCallback, so controls stay responsive. Also render low-res quick pass first (downsampled then upscale via drawImage).
- Smooth escape-time coloring: use continuous iteration count nu = n + 1 - log2(log|z|/log2)... standard: mu = n + 1 - log(log(|z|))/log(2). Color via palette with sine/cosine or piecewise gradient, plus black for interior.
- Wheel zoom centered at cursor: adjust center so complex point under cursor stays fixed.
- Drag pan: track pointer, translate center. While dragging, use CSS transform on a cached snapshot image? Simplest: draw cached ImageData via putImageData to an offscreen canvas and translate it via drawImage during pan — that gives smooth panning without recompute, then recompute after pointerup (or throttled during drag). Requirement: "Recompute the fractal after navigation rather than scaling a static image" — panning can show cached image translated then recompute; that's acceptable and standard. But "Recompute after navigation" fine.
- Reset view button.
- Prevent wheel page scroll: e.preventDefault() with passive:false, and body overflow hidden anyway.
- Iterations scale with zoom: maxIter = 100 + log2(1/scale)*... e.g. Math.floor(150 + 60*Math.log2(zoomFactor)).
- During pan/zoom, render progressively: first pass at coarse resolution (e.g., every 4th pixel), drawn scaled, then progressively refine resolution 2x each pass until full. Use row-chunked rendering with requestAnimationFrame budget.

Implementation plan for rendering:
- offscreen canvas full resolution ImageData buffer.
- progressive: passes with step sizes 8,4,2,1 (based on which pixels computed). For each pass, compute pixels at that stride, writing into imageData at stride positions (only compute if not computed at finer resolution... simpler: compute all pixels at that stride each pass, fill gaps by copying neighbors? Actually simpler: for stride s, compute pixel (x,y) when x%s==0 && y%s==0 and set a 2x2-ish block? Hmm.

Simpler robust approach: maintain full ImageData. Pass with stride s computes every s-th pixel; after pass completes, putImageData to offscreen and drawImage scaled? putImageData with holes looks bad. Alternative: keep a separate coarse buffer for display.

Alternative simpler approach: for pass with stride s, fill a block of s×s pixels with the computed color (compute at pixel center of block). That covers all pixels; downsampled look. Each finer pass recomputes blocks at finer stride covering full image again. That's 8,4,2,1: total work = 1/64+1/16+1/4+1 = ~1.33x of full compute, acceptable, and each pass covers whole screen. Chunk by rows within a pass, budget ~16ms per frame using performance.now.

After zoom wheel event, cancel current render, restart passes. Wheel zoom with trackpad inertia can be rapid; use coalesce: on wheel, update view, and schedule render with a small debounce (e.g., restart immediately but passes restart; fine).

Also during render, if view changed (pan/zoom), abort.

For quick preview during interaction: when dragging, translate existing rendered image: drawImage(offscreen, dx, dy) onto canvas. Zoom wheel: transform cached image by scale factor around cursor for instant feedback, then recompute. Since ImageData on offscreen canvas already, drawImage with scale works.

Edge-of-image areas during pan: canvas cleared to background (dark) — fine.

Render loop: a scheduler function renderLoop that does chunks. Use requestAnimationFrame.

Let me write code.

State:
```js
const view = { cx: -0.75, cy: 0, scale: 0 /* set on resize */ };
```
Initial: fit [-2.1, 0.6] x [-1.2, 1.2] roughly. Choose scale = 3.0/height (i.e., 3 units tall) and center (-0.6, 0)? Classic: x range -2.5..1.5 is 4 wide. Let's set initial so that width spans 3.5 units: scale = 3.5/canvasWidth, center (-0.7, 0). Height then 3.5*h/w units; for typical 16:9, height ~2 units: -1..1. Good, full set visible with margin. Actually ensure entire set (radius 2 from origin, escape radius 2; cardioid extends to x=0.25... set spans x∈[-2,0.5], y∈[-1.15,1.15]). Center (-0.75,0) with scale = 3.2/width gives x∈[-2.35,0.85], y∈[-1.8,1.8] for 16:9. Good.

Zoom-dependent iterations: zoomLevel = initialScale / scale. maxIter = 120 + 30*ln? Use: maxIter = Math.min(2000, Math.floor(100 * (1 + Math.log2(1 + initialScale/scale)))). Let's do maxIter = Math.round(80 + 50 * Math.log2(initialScale/scale + 1) * ...). Simpler: maxIter = Math.min(1500, Math.floor(120 + 45 * Math.log2(zoom + 1) ** 1.4))? Keep simple: maxIter = Math.min(2000, Math.floor(100 + 60 * Math.log2(initialScale / view.scale + 1))). At zoom 1e6, log2 ≈ 20, →1300. Fine.

Smooth color: for escaped point with iteration count n and |z| final magnitude m: mu = n + 1 - Math.log2(Math.log(m)/Math.log(2))? Standard: nu = n + 1 - log(log|z|/log(2))/log(2)... The common formula: nsmooth = n + 1 - Math.log(Math.log(|z|))/Math.log(2). Escape radius 256 for smoother gradient.

Palette: cyclic gradient using cosine: 
r = 0.5+0.5*cos(2π(t*3 + 0.0)), etc. Or multi-stop gradient through nice colors: deep blue → cyan → yellow → white → orange → black cycle. I'll precompute palette array of 2048 entries from a cosine palette:
t in [0,1): 
r = 0.5 + 0.5*cos(TAU*(t + 0.0))  — classic Inigo Quilez palette a+b*cos(2π(c t + d)) with a=(.5,.5,.5) b=(.5,.5,.5) c=(1,1,1) d=(0,.33,.67) gives rainbow-ish. Maybe nicer: d=(0.0,0.10,0.20), c=(1.0,1.0,1.0)... I'll craft: use stops [dark blue, cyan, yellow, orange, dark red, black] repeating. Simpler to implement palette via piecewise interpolation over 1024 entries with stop colors:
stops: [ [0,[8,10,40]], [0.15,[30,80,180]], [0.35,[90,220,230]], [0.55,[250,250,120]], [0.75,[240,120,30]], [0.9,[100,20,60]], [1,[8,10,40]] ] cyclic. Interior color: pure black (5,5,10).

Map mu → t = (mu * 0.02) % 1 with slight log repeat? Use t = mu/64 mod 1.

Interior: dark near-black with slight blue (10,8,20).

Cardioid/period-2 bulb shortcut check for speed: main cardioid test: q = (x-0.25)^2 + y^2; if q*(q + (x-0.25)) <= y*y/4 → inside. Period-2 bulb: (x+1)^2 + y^2 <= 1/16 → inside. Good speedup.

Progressive passes: strides [16, 4, 1]? Pass1 stride16 fast preview, pass2 stride 4, pass3 stride 1. Fill blocks. Compute chunk rows: process while (performance.now()-start<14ms) computing rows.

Abort flag: renderToken increments; each pass loop checks token.

Interaction:
- pointerdown: start drag, capture pointer, record start pos and center.
- pointermove: update center = startCenter - delta*scale; draw cached image translated: ctx.drawImage(off, dx, dy). Mark dirty → restart render on pointerup? Better: restart render during drag but throttled; while dragging just show translated cache, and on pointerup start render. Also if user pauses drag... simple: on pointerup render. That satisfies "recompute after navigation."
- wheel: zoomAt(x,y,factor): 
  wx = cx + (x - w/2)*scale; wy = cy + (y - h/2)*scale;
  scale *= factor (factor<1 zoom in);
  new cx = wx - (x - w/2)*scale, similarly cy.
  Immediate feedback: transform cached image: draw offscreen scaled: destination rect: scale factor f around cursor point. dx = cursor - f*(cursor - oldOriginX)... Then debounce recompute (e.g., setTimeout 120ms after last wheel, or restart render each wheel with coarse-first which self-heals). I'll do: show transformed cache immediately, then schedule render with 100ms debounce.
- Also double-click zoom in? Optional. Add dblclick zoom in, and maybe shift+dblclick out. Not required; skip or include lightweight. Include dblclick zoom.
- Keyboard +/-? Not required. Skip.

Buttons overlay: "Reset view" button, plus iteration/maxIter display and coordinates display. Keep minimal: Reset view button required. Add small info line (center, scale/zoom, iterations).

Prevent page scroll: wheel listener {passive:false} preventDefault; body margin 0 overflow hidden; canvas touch-action: none.

Also touch: pointer events handle touch pan; pinch zoom via two pointers? Could add simple pinch. Add basic pinch: track two pointers distance → zoom. Keep it; moderate effort. I'll add simple pinch support.

Canvas resize: on resize, resize canvases, recompute initialScale, restart render (keeping center/scale? Keep center and scale, just recompute). devicePixelRatio: cap at 1.5 for perf? Use dpr min(devicePixelRatio, 2). Scale factor: handle in computation via canvas pixel dims. Let canvas pixels = css*dpr. Mouse coords multiply by dpr.

Code structure:

```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d');
const off = document.createElement('canvas');
const offctx = off.getContext('2d');
let W,H,dpr;
let img; // ImageData
let buf32; // Uint32Array view
```

Palette as Uint32? Use img.data with RGBA writes; buf32 with ABGR little-endian: 0xFF<<24 | b<<16 | g<<8 | r.

Palette precompute: pal[4096] of packed.

Render:
```js
let token = 0;
function render() {
  token++;
  const my = token;
  computeMaxIter();
  const strides = [16,4,1];
  runPasses(strides, my);
}
```
runPasses: async loop:
```js
async function runPasses(strides, my){
  for (const s of strides){
    // fill blocks
    for (let y=0; y<H; y+=s){
      chunk: compute rows for this block-row: for y..min(y+s,H)? Compute one row per block row at stride s and fill blocks vertically.
      if (time>14ms) await nextFrame; if(token!==my) return;
    }
    blit();
  }
}
```
Block fill: for block starting (bx,by) size s×s: color from sample at (bx+s/2, by+s/2) center. Fill buf32 region. On final pass s=1 exact.

But note pass s=4 must cover pixels not covered by... it covers everything (blocks of 4). Fine, just redundant.

Per-iteration loop per pixel: standard.

```js
function iterate(x0,y0,maxIter){
  // cardioid check
  ...
  let x=0,y=0,x2=0,y2=0,i=0;
  while (x2+y2 <= 65536 && i<maxIter){ y = 2*x*y + y0; x = x2 - y2 + x0; x2=x*x; y2=y*y; i++; }
  if (i>=maxIter) return -1;
  const log_zn = Math.log(x2+y2)/2; const nu = Math.log(log_zn/Math.LN2)/Math.LN2;
  return i + 1 - nu;
}
```
Then t = (mu*0.015) % 1 → pal index. Interior: pack interior color.

Blit: offctx.putImageData(img,0,0); ctx.drawImage(off,0,0,W,H) — but ctx canvas is same size W,H (device px), drawImage with CSS scaling. Since both are device-px sized, drawImage(off,0,0) fine.

Interaction transform feedback: for wheel zoom factor f around (px,py): ctx.drawImage(off, 0,0,W,H, px - f*px, py - f*py, W*f, H*f). Since origin shifts: new origin in old pixel coords = px - f*px. Yes.

For pan drag: ctx.drawImage(off, dx, dy).

Background fill each interaction frame: ctx.fillStyle = '#0a0a12'; fillRect.

Info overlay update on render complete.

Now write the file. Also handle window resize with debounce re-render.

Wheel handling:
```js
canvas.addEventListener('wheel', e=>{
  e.preventDefault();
  const rect = canvas.getBoundingClientRect();
  const px = (e.clientX-rect.left)*dpr, py=(e.clientY-rect.top)*dpr;
  const f = Math.exp(e.deltaY * 0.0015); // deltaY>0 → zoom out
  zoomAt(px,py,f);
},{passive:false});
```
Trackpad deltaY small; factor per event ~ e^(0.0015*delta). For delta 100 → e^0.15 ≈ 1.16. OK.

Debounce render after wheel: clear timer, schedule 120ms. During debounce, show transformed cache. Accumulating transforms on cache each event without re-render causes blurry but fine for short bursts. Alternative: on each wheel event, transform the *last rendered* snapshot by cumulative amount from render-start point. Simpler: transform current canvas: copy current canvas to off first? Trick: keep "snapshot" canvas updated at last completed render; each wheel event applies total accumulated transform since snapshot: maintain accum {sx, sy, sf} relative to snapshot; draw snapshot transformed. Implement: snap canvas = off (rendered). Keep accX, accY, accF. On wheel: update view; accF*=f; adjust acc so cursor point fixed: point in snap coords q = (px - accX)/accF; accX = px - q*accF... let's derive: displayed pixel d corresponds to snap pixel s: d = accF*s + acc. On zoom by f around cursor px: d' = f*(d-px)+px = f*accF*s + f*(acc-px)+px → accF'=f*accF, acc' = f*(acc-px)+px.
On pan (drag): d' = d+dx → acc += dx.
Render loop draw: clear, drawImage(snap, accX, accY, W*accF, H*accF).
Reset acc on new render.

Drag: accX += dx etc., no recompute until pointerup → render() resets acc.

Also on drag, if pointer moves beyond, edges show background — fine.

Let me also add pause/resume: when user interacts during rendering, token invalidated → render loop stops promptly (checks token each chunk). Good responsiveness.

Write code now.

One more: initial framing must show full set. On resize: keep view if user navigated? On first resize set default. Store `initialized`.

Reset: view = default (recompute based on current canvas size), render.

Info: show zoom relative to initial: zoom = initScale/scale.

Now write index.html.

Chunked pass function:

```js
async function renderView(){
  const my = ++token;
  accF=1; accX=0; accY=0;
  const maxIter = calcMaxIter();
  for (const stride of [16,4,1]){
    for (let by=0; by<H; by+=stride){
      const yEnd = Math.min(H, by+stride);
      // compute row of blocks
      for (let x=0; x<W; x+=stride){
        const cx = view.cx + (Math.min(x+stride/2, W-1) - W/2)*view.scale;
        const cy = view.cy + (Math.min(by+stride/2, H-1) - H/2)*view.scale;
        const mu = iterate(cx, cy, maxIter);
        const col = mu<0 ? interior : pal[Math.floor(((mu*0.02)%1)*PALN)&(PALN-1)];
        // fill block
        const xEnd = Math.min(W, x+stride), yE=Math.min(H,by+stride);
        for(let yy=by; yy<yE; yy++){
          const row = yy*W;
          buf32.fill(col, row+x, row+xEnd);
        }
      }
      if ((performance.now()-lastT)>12 || by % (stride*8)===0?...){
        await frame(); if (my!==token) return;
        lastT=performance.now();
      }
    }
    blit(my); if(my!==token) return;
  }
}
```
Hmm blit should also check token but still display partial progress — blit partial anyway (putImageData + draw). But if token changed, view changed; drawing stale is fine? It'd be overwritten by interaction feedback draw. Actually interaction feedback draws snapshot transform; partial stale blit could conflict. On token change, return before blit. Blit only when token matches: blit(); inside blit draw snap→main and update snap. Let me structure: blit copies buf to snap canvas and draws snap to main (with acc transform, acc=0 here). Fine.

Yield frequency: yield when elapsed >12ms per block-row; for stride 1 a row is cheap; yield check each row.

Note await frame() at minimum once per frame → animation pacing good.

Also during long final pass, per-row checks. Use rAF promise.

Time check: track lastYield = performance.now() before computing row of blocks; after row, if elapsed>12, await.

Let me now write the whole file.

Edge: mu*0.02 for palette cycling; ensure smooth: fine.

Interpolation for stride center uses view coords: complex coords from pixel: px center of block.

Interior color packed: little-endian: 0xFF000000 | (b<<16)|(g<<8)|r. Interior (8,6,16): r=8,g=6,b=16 → 0xFF100608.

Write it.

Note: wheel also schedules debounce while rendering — fine. One issue: scheduleRender during ongoing render: token++ aborts. Good.

Potential bug: in wheel handler when accF used for qpx: fine.

Check in browser.

Initial render completed, info shows iter 180 (final pass). Good. Now test wheel zoom at a point — pick a boundary point, e.g. seahorse valley near (-0.75, 0.1). Do wheel zoom via dispatching wheel events. Browser tool supports key, click, drag, scroll... there's no direct wheel event tool. I could use bash? No. Use browser "scroll" action? That likely dispatches wheel. Let me try scroll at a coordinate and then check info/center values via inspect.

Alternative: verify programmatically via console? The browser tool only gives console output. I can't run JS directly. But I can check behavior indirectly: use scroll action at x,y and then screenshot + read info. Let me try.

Info unchanged — maybe scroll didn't dispatch a wheel event, or the render debounce hasn't completed (110ms). Wait and screenshot again.

The scroll action did dispatch wheel (center changed, zoom 1.62×). Good. But I need to verify cursor-anchored zoom: the complex point under cursor should stay fixed. Let me do multiple wheel scrolls at same point and check. I'll do a few scrolls then screenshot. To verify anchoring numerically I can't read JS state directly, but I can compute expected: cursor at (560,400) in CSS px, dpr unknown (browser viewport 1200×800, dpr likely 1). wx initially = -0.75 + (560 - 600)*scale where scale = 3.2/W, W=1200 → scale=0.0026667. wx = -0.75 + (-40)*0.0026667 = -0.856667. wy = (400-400)*scale + 0 = 0... wait initial cy=0, py=400 = H/2, so wy=0. But after first zoom center became (-1.3599, -0.4066)?? That means cursor point wasn't 0,0... Hmm, the scroll tool may dispatch at a different position or with momentum (multiple wheel events). The delta -300 split into multiple events, each anchored at cursor — cumulative anchoring still holds for the same point. After zoom 1.62×: wx stays at complex point of cursor. Initial wx = -0.8567, wy = 0.0 (py=400=H/2? H=800 so yes). But new center = (-1.3599, -0.4066). Check: new cx = wx - (px - W/2)*newScale = -0.856667 - (-40)*0.0026667/1.62 = -0.856667 + 0.06584 = -0.79083. But reported center is -1.3599! That's way off.

Hmm, maybe the scroll tool coordinates aren't where I think, or dpr ≠ 1, or scroll dispatches multiple events with different coordinates/momentum, or the browser window inner size differs. Actually maybe the scroll action happened at a position and deltaY negative but the tool's coordinate origin differs. Let me test anchoring directly: do several scrolls at the same point, then screenshot, and check whether info center converges so that cursor's complex point equals initial -0.8567, 0.

Actually wait — maybe the issue: the scroll tool may scroll the page and coordinates relative to viewport; canvas is fixed inset 0 so fine. But momentum: multiple wheel events dispatched over time, all at (560,400)? If so anchoring should keep the same complex point fixed, and my math says center should end at cx = wx - (px-W/2)*scale_final = -0.8567 + 40*scale_final. With zoom 1.62, scale_final = 0.0026667/1.62 = 0.0016463 → cx = -0.8567+0.0659 = -0.7908. Reported -1.3599. Discrepancy.

Unless the scroll events have momentum and coordinates move? Or the tool dispatches deltaY per event larger... The anchor math is per-event regardless of f. Anchoring is independent of f — each event fixes cursor point. So after N events at same (px,py), point stays at (wx,wy) computed from initial state only if px,py constant and each event anchored. So final center should satisfy: complex point at cursor = initial complex point at cursor = (-0.8567, 0). But center y = -0.4066 ≠ 0 - (400-400)*scale = 0. So anchoring broken OR scroll position different.

Possibility: the tool's scroll dispatches at a different coordinate than (560,400) — maybe it uses window.scrollBy? Or it dispatched with deltaY and default position? The center changed to (-1.36,-0.41): if cursor were at (px,py), then cx_final = wx0 - (px-600)*s_final where wx0 = cx0 + (px-600)*s0. Solve: cx_f = cx0 + (px-600)(s0 - s_f). -1.3599 = -0.75 + (px-600)*(0.0026667 - 0.0016463) → (px-600) = -0.6099/0.00102 = -597.9 → px ≈ 2. Similarly cy_f = cy0 + (py-400)(s0-s_f) → -0.4066 = (py-400)*0.00102 → py = -0. Hmm py=0, px≈2. So the wheel events were dispatched near (0,0)!? That suggests the tool dispatched wheel at top-left or without coordinates.

Wait, but maybe dpr = 2? If dpr=2, W=2400, s0 = 3.2/2400=0.0013333. Then (px-1200)*(0.0013333-0.0013333/1.62) = -0.6099 → (px-1200) = -0.6099/0.0005124 = -1190 → px ≈ 10. Similar conclusion.

Hmm, so events effectively at ~(0..10, 0..-?). The browser tool's scroll may not support x,y properly or dispatched wheel at 0,0. Hard to verify cursor anchoring with this tool. Alternative verification: use dblclick? Also can't control precisely? Click actions take x,y and probably work. But dblclick → zoomTo centered on click. I could dblclick at a point, and check whether the complex point at that pixel stays. Let's do dblclick at (760, 400) and screenshot. Expected: zoom 4×, and the complex point at (760,400) preserved: wx0 = -0.75 + 160*0.0026667 = -0.3233; cx_f = wx0 - 160*s_f = -0.3233 - 160*0.0026667/4 = -0.3233-0.10667 = -0.43. If info shows -0.43,0 then anchoring works (dblclick uses same zoomTo path... well zoomTo logic equals wheel logic).

But first, wheel test itself: the info change shows wheel events fired and preventDefault (no page scroll — page has no scroll anyway). For cursor anchoring of wheel, the code path is identical math to zoomTo; I'll verify via dblclick then trust wheel.

Actually better: to test wheel anchoring precisely, dispatch synthetic wheel via ... no JS eval available. Use dblclick verification.

Also test drag pan then reset. Drag: browser drag from (600,400) to (800,400) pans image right by 200px → cx increases? dx=+200 → cx -= 200*scale → cx more negative? cx -= ddx*scale with ddx=+200 → cx = -0.75 - 0.533 = -1.283? Wait panning: user drags image right → view center moves left (view.cx decreases). Yes cx ≈ -1.2833. Then Reset → back to -0.75.

Let me run dblclick test first (but note dblclick also triggers pointerdown/up twice which triggers render on pointerup — pointerup after drag acc reset... acc reset happens at render; zoomTo sets acc. Sequence: two pointerdown/up pairs then dblclick. The first pointerup: acc==0 → no render. OK fine.)

Actually the earlier scroll left view at zoom 1.62. For a clean dblclick test, reset first.

Reset works: back to center (-0.75, 0), zoom 1.00×, iter 180. Now dblclick at (760, 400). Expected center after zoom 4×: wx0 = -0.75 + (760-600)*0.0026667 = -0.75 + 0.42667 = -0.32333. cx_f = -0.32333 - 160*(0.0026667/4) = -0.32333 - 0.106667 = -0.43, cy = 0.

No dblclick action available. Actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No dblclick. So test anchor zoom via two rapid clicks? No. Alternative: use wheel scroll at known coords — but earlier the events seemed to fire at (0,0)-ish. Wait, maybe the scroll tool's x,y ARE honored and my math for dpr was wrong. Let me recheck with dpr unknown but the browser tool viewport is 1200×800 CSS px presumably, and dpr in this headless env could be 1.

Earlier result: zoom 1.62×, center (-1.359947, -0.406631). If events fired at (560,400) with dpr=1: expected final cx = -0.856667 + 40*s_f. s_f = s0/1.62 (assuming total factor from exp sum of deltas: zoom reported = initScale/scale = 1.62). cx_expected = -0.856667 + 40*(0.0026667/1.62) = -0.856667 + 0.065844 = -0.790822. Reported -1.359947 — doesn't match.

Hmm wait — actually maybe scroll momentum events have varying coordinates? Or the "scroll" tool scrolls by moving mouse to (x,y) and then dispatching wheel with multiple deltas — anchored each time at same point; the final center is determined by last event's anchor which is the same (560,400). Still expected -0.79.

What if dpr=2 and the tool coordinates are CSS px: px=1120, py=800. s0 = 3.2/2400 = 0.00133333. wx0 = cx0 + (1120-1200)*s0 = -0.75 - 0.106667 = -0.856667. Same wx0! Interesting. cx_f = wx0 - (1120-1200)*s_f = -0.856667 + 80*(0.00133333/1.62) = -0.856667+0.0658 = -0.7908. Same. Still mismatch.

What if the tool dispatched events at different y for each? cy_f - 0 = (py-400)*(s0 - s_f)... if all events anchored at same point, final: wy0 = cy0 + (py-400)*s0; cy_f = wy0 - (py-400)*s_f = (py-400)*(s0-s_f). Reported -0.406631 = (py-400)*0.00102040 (for dpr1, s0-s_f = 0.0026667*(1-1/1.62)=0.0010204). → py-400 = -398.5 → py ≈ 1.5. So py≈0 → events at top-left.

OK so scroll tool ignores x/y (dispatches at 0,0 or window origin). Wheel anchoring logic itself: let me double check the math in the code.

view.cx = wx - (px - W/2)*view.scale where wx is complex point under cursor before zoom. After scaling by f (zoom out if f>1), the point under cursor becomes wx again. Correct.

Feedback transform: qpx = (px - accX)/accF — snap pixel under cursor; after scaling accF*=f, accX = px - qpx*accF. Then displayed pixel d = accF*s + accX; the snap pixel qpx maps to d = accF*qpx + accX = accF*qpx + px - qpx*accF = px. Fixed. Correct.

One subtle issue: in wheel handler, view.scale *= f with f = exp(deltaY*0.0016); deltaY negative → zoom in. OK.

So the anchor logic is fine; the tool limitation prevents precise wheel verification. I can verify anchoring via "drag"? No, that pans.

Alternative: use keyboard? key action — could add keyboard zoom but keys anchor at screen center, not cursor.

Hmm, another approach: temporarily verify by using scroll at multiple different coordinates and see if center changes consistently with events at (0,0): if I scroll at (900,300) and get the same center change as before, the tool ignores coords. Not needed — already concluded.

I could verify the anchor math another way: after the first scroll (at ~(0,0), zoom 1.62, center (-1.359947,-0.406631)), do another scroll at a different x,y. If tool ignores coords, identical second scroll would produce zoom 1.62² = 2.62× and center = wy0'... predictable: new events anchored at (0,0)-ish again → cursor complex point currently at (0,0): wx = cx + (0-600)*s = -1.359947 - 600*0.0026667/1.62 = -1.359947-0.987654 = -2.3476; wy = -0.406631 - 0.987654 = -1.39429. After zoom to 2.6244: cx_f = -2.3476 - (0-600)*(0.0026667/2.6244) = -2.3476 + 0.60915 = -1.73845; cy_f = -1.39429 + 0.60915 = -0.78514. If reported matches, that proves anchoring consistency across events at a fixed pixel (0,0). Actually that does verify anchor behavior of the wheel path! Because if anchoring were broken (e.g., centered zoom), the numbers would differ. Good test.

Also test page-scroll prevention: page has overflow hidden, nothing to scroll. Canvas fixed. Fine.

Let me do that second scroll.

Hmm — it says center -0.75, zoom 1.00! Did it reset? Oh wait — the scroll tool may have moved the mouse to (0,0) which is outside the canvas? Canvas covers the full viewport (fixed inset 0), so (0,0) is on canvas... but (0,0) is also where the hint/HUD are not... HUD is at top-left (12,12) with the Reset button at ~(20-90, 12-35)! The previous scroll at x=560/y=400 ignored coords and hit (0,0)? But the first scroll DID zoom. And this scroll... reset?? Did the scroll event land on the Reset button and click it? A wheel event wouldn't click.

Wait, maybe the second scroll actually dispatched at 0,0 over the reset button — no, wheel doesn't click. But center shows reset state with iter 180 (completed render). Possibly my previous screenshot... no, previous screenshot after reset showed -0.75. Then I did dblclick attempt (validation failed — no action). Then click at (80,20) = Reset button → screenshot showed -0.75 zoom 1.0 — that was after reset. Then scroll → zoom 1.62. Then screenshot... wait order:

1. reload → screenshot: -0.75, 1.00
2. scroll at 560,400 → info unchanged (immediate)
3. screenshot → 1.62×, center -1.36,-0.41 ✓
4. click at (80,20) → info unchanged shown
5. screenshot → -0.75, 1.00 ✓ (reset worked)
6. dblclick attempt → validation error (no action taken)
7. scroll → info shows -0.75, 1.00 (immediate, pre-debounce)
8. screenshot → -0.75, 1.00?? 

Hmm, step 8 shows un-zoomed. So the second scroll's debounced render... screenshot taken too early? No — screenshot shows iter 180 which means a render completed. If zoom had changed, scheduleRender(110) would fire and show higher iter. Unless the wheel events never fired this time! Maybe the tool's scroll scrolled... at (0,0)? First scroll fired; second didn't? Odd.

Or maybe the second scroll targeted (0,0) which is over the HUD/hint? The #hud has pointer-events:none except button; wheel listener is on canvas which is beneath. Wheel over button: button has pointer-events auto, wheel would hit button → no canvas listener → page scroll (none). So no zoom! That explains it: events at (0,0) land on the Reset button area (top-left). But then how did the FIRST scroll work? First scroll specified x=560,y=400 — maybe the tool DOES honor x,y... but then my math predicted center -0.79, not -1.36.

Hmm wait, maybe I made an arithmetic error. Let me recompute. Initial: cx0=-0.75, s0=3.2/W. W = 1200*dpr. If dpr=2, W=2400, s0=0.00133333.

Cursor at CSS (560,400) → device (1120, 800). wx0 = -0.75 + (1120-1200)*0.00133333 = -0.75 - 0.1066667 = -0.8566667. wy0 = 0 + (800-800)*s0 = 0.

After N anchored wheel events ending at zoom Z: wy stays 0 and cx_f = wx0 - (1120-1200)*s_f = -0.8566667 + 80*0.00133333/Z = -0.8566667 + 0.1066667/Z. With Z=1.62: -0.8567 + 0.0658 = -0.7908. Reported: -1.359947. Not matching. And cy_f should be 0 but was -0.4066.

So first scroll did NOT honor (560,400). It behaved like events at device pixel ≈ (2·?, ...). Solve with dpr=2: cx_f = cx0 + (px_dev-1200)*(s0 - s_f) = -0.75 + (px-1200)*0.00133333*(1-1/1.62) = -0.75 + (px-1200)*0.000511703 → (px-1200) = -0.609947/0.000511703 = -1192.2 → px ≈ 7.8. cy: (py_dev-800)*0.000511703 = -0.406631 → py_dev = 800 - 794.6 = 5.4. So events at device (~8, ~5) = CSS (~4, ~2.7): top-left corner. So yes, scroll ignores coords, dispatches at origin, over the Reset button.

Then why did the SECOND scroll not zoom? Because the events hit the Reset button (pointer-events auto) and canvas listener didn't receive them. First scroll also hit the button... but it zoomed. Hmm contradiction.

Unless first scroll's events at (8,5) device → CSS (4, 2.5)... button spans roughly x:12..~100, y:12..38 CSS. CSS (4,2.5) is above/left of button (button starts at 12). Hit-testing at (4,2.5): that's over #hud container? #hud has pointer-events:none, so events pass through to canvas. Zoom works. ✓.

Second scroll: same position should behave identically. But it didn't zoom. Weird. Maybe second scroll dispatched a real page scroll first... or the "scroll" tool actually performs window.scrollBy JS (not wheel events) when the page can't scroll? First time something else? 

Alternatively — maybe the second scroll DID fire wheel events on canvas, zoom happened, and then... debounced render(110ms) ran; screenshot taken after render complete shows -0.75?? No, render doesn't reset view.

OR: The scroll tool might first move the mouse... Actually wait, could the second scroll have hit the Reset button triggering a click? The click at (80,20) in step 4 was explicit. Scroll ≠ click.

Let me look again: step 8 screenshot shows "-0.75, 1.00×, iter 180". Step 7 (immediately after scroll) also showed that. So the wheel events in step 7 were swallowed. Then step 8 confirms nothing changed.

Possibility: the tool's scroll alternates or depends on prior mouse position/state. Whatever — the tool is unreliable for wheel testing. 

Alternative approach to verify wheel anchoring: temporarily modify index.html? No. Better: verify via math review (already done) and test what I can: pan drag + reset, and visual zoom behavior via... hmm.

Actually, maybe I can dispatch a wheel event using the "key" action? No.

Alternative: I can add a temporary query-param-triggered scripted zoom? E.g., support keyboard "+/-" zoom keys (useful anyway) and test via key action, verifying zoom-at-center anchoring (center point = screen center; anchor check trivial since center is fixed). That tests the zoom path partially (zoomTo vs wheel share math). Let me add keyboard zoom (also improves UX). Then test: press "+" a few times, check zoom multiplies by 1.5 and center unchanged. And also test wheel preventDefault indirectly (page can't scroll anyway; body overflow hidden; the only scrollable... none).

Also verify pan via drag then reset.

Let me add +/- keys.

Zoom 2.25× = 1.5² — two key presses worked, center unchanged (-0.75, 0) since anchor is screen center. Detail increases with zoom (iter 222). Now test panning: drag from (600,400) to (800,400). Expected cx = -0.75 - 200*view.scale... view.scale = s0/2.25. dpr? Unknown but W = 1200*dpr, s0 = 3.2/W. ddx = 200*dpr. cx -= 200*dpr * (3.2/(1200*dpr)/2.25) = 200*3.2/(1200*2.25) = 0.237037 → cx = -0.987037. cy unchanged = 0. Then reset → back to -0.75.

Pan worked: center moved to (-0.908025, 0) — cx decreased by ~0.158 (drag right → view moves left). 200 CSS px * dpr * scale... with dpr=1: 200*0.0026667/... wait scale = 3.2/1200/3.37 ≈ 0.0007916 → 200*0.0007916 = 0.1583 ✓ matches (-0.75-0.158=-0.908). Good, dpr=1 in this browser.

Now Reset view.

Reset restored initial framing exactly: center (-0.75, 0), zoom 1.00×, iter 180.

Remaining verification: wheel behavior itself — the scroll tool dispatches at origin which lands near the HUD (pointer-events none, so canvas gets it... first scroll DID zoom, so wheel path works and preventDefault kept page stable). The second scroll not registering is a tool quirk (maybe it hit the button edge). The wheel handler math was verified analytically and shares the identical anchor logic with zoomTo/keys which I verified numerically (center stayed exactly fixed through 2 zoom steps; scale changed precisely by factor).

One more check worth doing: zoom deep and confirm progressive detail renders and stays responsive — press + many times and screenshot to see structure. Let's do ~6 more presses quickly and one screenshot.

Zooming deep into seahorse valley at (-0.75, 0) works, iterations climb (507 at 86×), renders stay responsive (each keypress returned instantly with final-pass info). The point at screen center is anchored (center stays -0.75, 0 — trivially, since anchor = center; but for wheel/dblclick the same zoomTo math anchored at arbitrary px,py was verified analytically and panning verified numerically).

Reset once more and finish. Also confirm no console errors (only the sandbox iframe warning, unrelated to app). File is saved. Done — write final report.