Mandelbrot explorer · deepseek-v4.1-flash

Let me build this. I'll create a self-contained index.html with a Mandelbrot explorer.

Key features:
- Full-screen canvas
- Smooth escape-time coloring
- Inside color distinct
- Drag to pan
- Wheel zoom centered on cursor
- Recompute with adaptive iterations
- Reset button
- Prevent page scroll on wheel
- Responsive rendering: render progressively (e.g., low-res preview then full res), use requestAnimationFrame / tiling to keep responsive.

Let me design carefully.

State: centerX, centerY (complex), scale (complex units per pixel) or zoom. Initial view showing main cardioid and surrounding lobes: center around -0.5, scale such that x range ~ [-2.2, 0.8]. Let's set view with width/height from canvas.

Let viewWidthComplex = 3.0 initially, so scale = 3.0 / canvas.width. Center = (-0.6, 0).

Iterations: base 256, increase with zoom: maxIter = clamp(200 + 100*log2(zoom), 200, 2000) or similar. Actually let's use maxIter = 200 * (1 + log10(zoom))... Let's just do maxIter = Math.min(2000, 150 + 200 * Math.log2(zoom+1)).

Rendering: To keep responsive, render in tiles across frames using a time budget per frame (e.g., 12ms). Also render at lower resolution during interaction (preview) then full resolution.

Approach: Use an offscreen ImageData at full canvas resolution, fill progressively. But if we compute at full resolution with tiles it can take a while. Better: render a preview at reduced resolution scaled up, then refine.

Simpler robust approach: 
- On navigation, immediately compute a low-resolution preview (e.g., 1/4 scale) synchronously or in a few chunks, draw scaled to canvas.
- Then progressively compute full-res in tiles with time budget per frame.

Let me implement a Renderer that has a queue of tiles. Each frame processes tiles within a time budget. Use two passes: preview pass at step = 4 (or dynamic), then full pass at step=1.

Actually let me do a simpler progressive: render at full resolution in tiles but process within time budget. During that time show previously rendered pixels? If we clear canvas, it looks bad. Instead keep the ImageData and putImageData incrementally after each tile batch. That gives a nice progressive fill. But panning would show stale content offset incorrectly. We could offset existing image as a quick preview (translate canvas) then recompute. That's nice.

Let me implement:
- Maintain an ImageData buffer at canvas resolution, plus a "rendered" flag per tile.
- On view change: cancel current job. Do a quick preview by scaling the current canvas image to approximate new view (optional). Then start progressive rendering of new view.

To keep it manageable and responsive, I'll do:

render() called on view change:
1. Set currentJob with params.
2. Immediately render a low-res version into a small offscreen canvas (step = computeStep based on canvas size, e.g., step 4 or 8), draw scaled onto main canvas. This is fast enough (canvas 1200x800 / 4 = 300x200 = 60k pixels * iterations). Could take some tens of ms. Acceptable. Actually at high zoom iterations 2000, 60k*2000 = 120M ops, too slow. Use dynamic step. Hmm.

Let me use time-budgeted tiling for everything, starting with coarse step. Approach: render passes with step sizes [8, 4, 2, 1] (powers of 2). For each pass, iterate over tiles. Each pass draws with fillRect blocks of size step. This progressively refines. Each frame budget ~14ms. This is clean.

Implementation:
- job = { centerX, centerY, scale, maxIter, passIndex, tiles queue... }
- Simpler: use a single loop over pixels with step. Keep an index pointer. Each rAF, process while time < budget.

Let me write a function that for a given step iterates all blocks row by row. For each block compute color at block center (or top-left) and fill a rect of step×step using ctx.fillStyle. fillRect per block is slower than ImageData but fine for larger steps. For step=1, that's per-pixel fillRect — too slow (960k calls). Better to use ImageData for step=1.

Alternative: use ImageData for all passes. For coarse passes, fill the ImageData pixels in the block. Then putImageData whole. Actually putImageData every frame is fine. For a block of step, we fill all pixels in block with same color. That's more pixel writes but avoids fillStyle overhead.

Let's just maintain a full ImageData buffer. For coarse passes we write blocks. Then putImageData. For step=1 write each pixel. Good.

But writing full buffer blocks each pass and putImageData full each frame is ~ 3MB copy, fine.

Algorithm per pass:
```
function runPass(step) {
  // process rows
  for (let y=0; y<H; y+=step) {
    for (let x=0; x<W; x+=step) {
      compute color for pixel (x,y) [sample at center x+step/2? use x,y fine]
      fill block [x, x+step) × [y, y+step) with color in buf
    }
  }
  putImageData
}
```
Time budget: check every row (or every few blocks) and yield. Keep state {step, x, y}.

Let me structure a render job object:

```
job = {
  view: {cx, cy, scale},
  maxIter,
  step,
  x, y,
  passes: [8,4,2,1] but scale by devicePixelRatio? 
}
```

Actually the canvas should account for devicePixelRatio but that increases pixel count. For performance, render at CSS pixel resolution (dpr=1) to keep responsive. It's acceptable. Maybe use dpr capped at 1. Let's keep dpr=1 for speed and full-screen. Fine.

Full-screen: canvas.width = innerWidth, height = innerHeight.

Color: smooth escape-time. Use continuous iteration count: nu = n + 1 - log2(log2(|z|)). Then map through a palette using a cyclic gradient. Use HSL or a procedural palette function.

Let me define palette via cosine: 
```
function color(t) {
  // t in [0,1)
  r = 0.5 + 0.5*cos(2π*(t+0.0))
  ...
}
```
Smooth gradient. Use t = (nu * 0.02) % 1 maybe with scaling. Or use a sinusoidal palette:
r = 9*(1-t)*t^3*255 ... too specific.

I'll use:
```
function palette(t){
  const a = [0.5,0.5,0.5], b=[0.5,0.5,0.5], c=[1,1,1], d=[0.0,0.33,0.67];
  return [
    a[0]+b[0]*Math.cos(2π*(c[0]*t+d[0])),
    ...
  ]
}
```
Nice smooth. Inside set: black (distinct).

Actually "distinct color for points treated as inside" — black is good, distinct.

Map nu to t: t = nu / maxIter? That changes with zoom making colors shift. Better t = nu * frequency where frequency maybe 0.02-0.05. But at high iterations points near set have huge nu so many cycles — colorful. That's fine.

Maybe t = Math.sqrt(nu) * 0.1? Let's use t = nu * 0.025. Hmm, standard is t = nu / 256 with cycling. I'll use t = (nu * 0.015) and let palette wrap.

Let's just do t = nu / 64.0; palette handles wrapping via cos. Fine.

Now zoom centered on cursor: given mouse at screen (px, py), complex point under cursor: 
```
cx + (px - W/2)*scale, cy + (py - H/2)*scale
```
Note y axis: complex imaginary increases downward or upward? Typically Mandelbrot rendered with y increasing downward means flip. Let's define complex coordinate: re = cx + (px - W/2)*scale; im = cy + (py - H/2)*scale. It's just a vertical flip of the standard picture; fine either way. I'll keep im increasing downward (mirror image vertically). Not important, but for recognizable shape it's symmetric anyway (Mandelbrot symmetric about real axis). So fine.

Zoom: on wheel, factor = exp(-deltaY * 0.001) or use deltaY sign. New scale = scale * factor. To keep point under cursor fixed:
Let complex point P = screenToComplex(px,py) with old scale.
After zoom, we want screenToComplex(px,py) == P with new scale.
new_cx = P.re - (px - W/2)*newScale
new_cy = P.im - (py - H/2)*newScale
Good.

Clamp zoom range: scale min/max. Initial scale = 3.0 / W. Let maxZoom factor... min scale = 1e-13 maybe. Max scale (zoom out) = maybe 8/W.

Reset view: restore initial center and scale, recompute initial scale based on current canvas size.

Pan: pointerdown records start; pointermove delta; update center by -dx*scale, -dy*scale. Recompute. During drag, to be responsive, we can just recompute (progressive). Use pointer capture.

Actually to make drag feel smooth, we can translate the existing canvas immediately and schedule recompute. But progressive recompute starts coarse pass which quickly fills. Might be okay. Let's add: on pointermove during drag, immediately blit the canvas translated (drawImage of itself) so it feels responsive, then start render. Use an offscreen copy.

Let me implement a quick "preview translate": on drag, before full render, do ctx.drawImage from a snapshot shifted. Hmm complexity. Given time budget, maybe just start render immediately; coarse pass step 8 is fast (W*H/64 pixels ~ 15k pixels), fills in a few ms. Good enough. At high iterations 2000, 15k*2000=30M ops ~ maybe 30ms. Acceptable-ish. Let's use coarse step 16 first if maxIter high. Passes: start step = 16 if zoom large else 8. Let's just always [16,8,4,2,1]? That's 5 passes, fine. Actually 16 pass is very fast.

Hmm but the first pass fills whole screen in blocks of 16 and gives immediate feedback. Good.

Let me set passes depending: base = [8,4,2,1]; if pixels large, fine.

Time budget per frame: 12ms. After finishing a pass, putImageData. Then continue.

Need to cancel job on new view. Use a job token.

Let me also handle window resize.

Adaptive iterations: 
```
function iterationsFor(scale) {
  // initial scale s0; zoom = s0/scale
  const zoom = initialScale / scale;
  return Math.min(3000, Math.floor(200 + 250 * Math.log2(zoom + 1)));
}
```
At zoom 1 -> 200+250*1=450. Hmm initial detail maybe 200 enough. Let's do base 150 + 200*log2(zoom+1). zoom1 -> 350. Fine. Cap 3000.

Actually let's make base depend: maxIter = 200 * Math.pow(zoom, 0.25)? At zoom 1 ->200, zoom 1e6 -> 200*10^1.5=6324 too high. Use log. I'll use:
maxIter = clamp(round(200 + 180*log2(zoom+1)), 200, 4000). Fine.

Performance: escape check with |z|^2 > 4.

Let me also add a coordinate/zoom HUD and iteration display maybe. Optional but nice. Keep minimal.

Reset button: fixed top-left.

Also "Prevent wheel navigation from scrolling the surrounding page": add wheel listener with {passive:false} and preventDefault.

Let me write the code.

Potential performance improvement: use typed arrays and avoid function call overhead. Compute directly in loop.

Let me write compute color into buffer with a helper for palette precomputed LUT. Precompute a palette lookup table of e.g. 2048 entries to avoid cos calls per pixel. t wraps. We can compute index = ((nu * scale) % 1) * (LUT-1). Use integer. Let's precompute LUT of RGB Uint8 arrays of size 2048.

Palette function:
```
const LUT_SIZE = 2048;
const lut = new Uint8Array(LUT_SIZE*3);
for i: t=i/LUT_SIZE; r=0.5+0.5*cos(2π*(t+0.0)); g=0.5+0.5*cos(2π*(t+0.33)); b=0.5+0.5*cos(2π*(t+0.67));
```
Multiply 255.

For smooth escape: nu = n + 1 - log2(log2(sqrt(mag2))) = n + 1 - log2(0.5*log2(mag2))... Let me compute: log2(|z|) = 0.5*log2(mag2). nu = n + 1 - log2(log2(|z|)) = n + 1 - log2(0.5*log2(mag2)). Need mag2>1. Since escape when mag2>4, log2(mag2)>2, log2(0.5*log2) = log2(log2(mag2)) - 1. Fine.

Then t = nu * freq. freq maybe 0.05 → 20 cycles per... hmm. Let's set colorScale such that one full palette cycle per ~64 iterations: index = (nu/64 mod 1). At high zoom nu can be large, giving many bands — fine.

Let me use index = (nu * 0.05) mod 1 → cycle every 20 iterations. Might be too busy. Use 0.02 (every 50). I'll go with 0.03.

Let me write it.

Now, the render loop with putImageData: we need to put image data each pass completion or more often. If we only put at pass end, coarse pass completes fast. Fine. For step=1 pass, that's the long one; we want to show progress. So put image data periodically (e.g., every row batch). putImageData full each time is costly (3MB). Maybe putImageData of dirty region. Simpler: put at end of each row? Let's put every ~16 rows via dirty rect. Use ctx.putImageData(imgData, 0,0, 0, yStart, W, yEnd-yStart) — dirty rect parameters: putImageData(imagedata, dx, dy, dirtyX, dirtyY, dirtyWidth, dirtyHeight). Yes. So put only updated rows. Good.

Let me implement job loop:

```
let job = null;
function startRender(view){
  const maxIter = iterationsFor(view.scale);
  job = {view, maxIter, step: 8, x:0, y:0, token: ++tokenCounter, running:false};
  ensureBuffer();
  requestAnimationFrame(tick);
}
```
But passes: after completing step, next step = step/2 while step>=1.

In tick:
```
if(!job) return;
const start = performance.now();
const {W,H} = canvas;
while(true){
  // process one row block
  const step = job.step;
  ... process row job.y from job.x
}
```
Let me write processRow that processes a full row of blocks at current step and advances.

Pseudo:
```
function tick(){
  if(!job) return;
  const t0 = performance.now();
  const step = job.step;
  const W=canvas.width,H=canvas.height;
  const view=job.view, maxIter=job.maxIter;
  let dirtyTop = -1, dirtyBottom = -1;
  while(performance.now()-t0 < 12){
    if(job.y >= H){
      // pass done
      flush();
      job.step /= 2;
      if(job.step < 1){ job=null; return; }
      job.x=0; job.y=0;
      continue;
    }
    const y = job.y;
    for(let x=0; x<W; x+=step){
      ... compute at (x + (step>>1), y + (step>>1))? use x,y
      fill block
    }
    job.y += step;
    if(dirtyTop<0) dirtyTop=y;
    dirtyBottom=y+step;
    flush partial every row? do at end of budget.
  }
  // flush dirty region
  if(dirtyTop>=0) ctx.putImageData(imgData,0,0,0,dirtyTop,W,dirtyBottom-dirtyTop);
  requestAnimationFrame(tick);
}
```
Wait step changes across passes; when step=1, y increments by 1 and dirty rows accumulate. Flushing at end of budget covers region. But dirtyTop..dirtyBottom may span a pass change; handle by flushing before changing pass. In the pass-done branch, flush accumulated region first. Let me just flush inside loop at end and also when pass changes.

Let me restructure with a helper flush() that uses job.dirtyTop/dirtyBottom and resets them.

Actually simpler: after while loop, flush whatever. When pass completes (job.y>=H), flush then continue; the while condition time budget still holds.

Let me code carefully.

Block fill: for step>1, compute color once and write step×step pixels. For step=1 write 1 pixel.

Compute function inline:

```
// complex coords for pixel center
const re0 = view.cx + (px - W/2)*view.scale;
const im0 = view.cy + (py - H/2)*view.scale;
let zr=0, zi=0, zr2=0, zi2=0, n=0;
while(n<maxIter && zr2+zi2<=4){ zi = 2*zr*zi + im0; zr = zr2 - zi2 + re0; zr2=zr*zr; zi2=zi*zi; n++; }
```
Careful: standard iteration z = z^2 + c. With zr,zi. Update order: new_zr = zr2 - zi2 + re0; new_zi = 2*zr*zi + im0; then set. But I wrote zi update using zr before update - yes must compute both from old zr,zi. Let me do:
```
const nzr = zr2 - zi2 + re0;
const nzi = 2*zr*zi + im0;
zr=nzr; zi=nzi; zr2=zr*zr; zi2=zi*zi; n++;
```
Good.

After loop, if n>=maxIter (and mag2<=4) → inside color. Actually condition: if zr2+zi2<=4 at exit due to n==maxIter → inside. Use `if (n>=maxIter)` but edge case where it escaped exactly at last iteration. Use check mag2<=4.

Smooth:
```
if (mag2 > 4) {
  const logZn = Math.log(mag2)*0.5; // log|z|
  const nu = n + 1 - Math.log(logZn)/Math.LN2; // n + 1 - log2(log|z|)
  let idx = ((nu*0.03)%1+1)%1 * (LUT_SIZE-1) |0;
  ...
} else inside color.
```
Wait formula: nu = n + 1 - log2(log2(|z|)). log2(|z|) = logZn/LN2. log2(log2|z|) = Math.log2(logZn/Math.LN2). Let me just: `const nu = n + 1 - Math.log2(Math.log2(mag2)/2)`. Since log2(|z|)=0.5*log2(mag2). So log2(log2|z|) = log2(0.5*log2(mag2)). Good.

Now the inside color: black (0,0,0).

LUT index integer. For smoothness maybe add fractional interpolation—LUT of 2048 is smooth enough.

Let me set LUT size 1024 and index computed.

Now the buffer: create ImageData(W,H). Use a Uint32Array view? Writing 3 bytes each. Using Uint8ClampedArray data directly. For block fill, we can precompute r,g,b and write. That's 4 writes per pixel (r,g,b,a). Fine.

Actually faster: use Uint32Array over the buffer and pack color into 0xAABBGGRR (little-endian). Then one write per pixel. Let's do that. ImageData.data.buffer -> Uint32Array. Endianness: most systems little-endian, so value = (255<<24)|(b<<16)|(g<<8)|r. Good.

Let me precompute LUT as Uint32Array packed.

Inside color = 0xFF000000 (opaque black).

For block fill loop:
```
const rowOffset = y*W;
for(let yy=0; yy<step && y+yy<H; yy++){
  let o = rowOffset + yy*W + x;
  for(let xx=0; xx<step && x+xx<W; xx++){ buf32[o+xx]=color; }
}
```
For step=1 this is fine.

Now sample coordinate: use pixel at (x, y) or center. Use x and y directly. Fine.

Initial view: center (-0.6, 0), width complex = 3.2 maybe. scale = 3.2/W. Need full main cardioid and lobes: cardioid spans re in [-2, 0.5] roughly, plus. With center -0.6 and width 3.2 → re range [-2.2, 1.0]. Good. Height depends on aspect; for wide screen height complex smaller. To ensure vertical extent shows set (im ±1.2), need height complex >= 2.6. scale = 3.2/W; height complex = H*scale = 3.2*H/W. For 1200x800, =2.13 → im ±1.07, a bit tight but the set max |im| ~1.1. Let's set initial width complex = 3.4 and center y maybe -0.1? Let's set scale = 3.4/W and also ensure height complex >= 2.6 by taking scale = max(3.4/W, 2.6/H). Good. Center (-0.6, 0).

Reset uses same formula.

Let me now write the file.

Also add HUD showing center, zoom, iterations. And instructions. Keep minimal styling.

Touch support: pointer events cover mouse and touch. Pinch zoom not required. Wheel.

Let me code.

I'll write the full index.html.

One concern: during dragging, pointermove fires rapidly and we restart render each time, cancelling. That's fine; coarse pass gives feedback. But the canvas may show stale pixels from previous view. When starting a new render, the coarse pass overwrites whole screen with step 8, so within ~one frame it's mostly updated. Good. But if pointermove fires every few ms, each frame restarts and never gets past coarse. That's okay—it looks blocky while dragging, sharpens when you stop. Good behavior.

But we should avoid rendering if job is already for same view. Fine.

Also, we should throttle pointermove with requestAnimationFrame: store pending pointer position and process in rAF. Let's just call startRender directly; it cancels previous and starts. But each startRender calls requestAnimationFrame(tick) possibly multiple ticks queued. Guard: only one rAF pending. Use a flag `scheduled`. Let me implement tick scheduling with a single flag.

Simplify: startRender sets job and if not scheduled, schedule. In tick, at end if job, schedule next; else clear scheduled.

Let me write:
```
let scheduled=false;
function schedule(){ if(!scheduled){ scheduled=true; requestAnimationFrame(tick); } }
function tick(){ scheduled=false; if(!job) return; ...work...; if(job) schedule(); }
```
startRender: job = {...}; schedule().

Good.

Now flush dirty region each tick. Track job.dirtyTop/dirtyBottom.

Edge: putImageData with dirty rect width/height ints.

Let me write the code now.

Also `image-rendering: pixelated`? Not needed.

Let me handle high-DPI optionally: set canvas.width = Math.floor(innerWidth * dpr) but cap dpr to 1.5? For performance, use 1. I'll use dpr but cap at 1.25? Keep simple: dpr = 1. Actually crisp text on HUD is DOM, fine.

Let me use devicePixelRatio capped at 1.5 and if the pixel count huge, reduce. Hmm, time. Just use 1 for performance and full-screen. But on retina it may look soft; acceptable.

Actually let's use Math.min(window.devicePixelRatio||1, 1.5). Pixel count at 1200x800*1.5^2 = 2.16M. Rendering step 1 with 3000 iters worst case is heavy but progressive. Fine. But block fills in 32-bit buffer. Should be okay. I'll cap at 1.5.

Hmm but the browser tool viewport is 1200x800, dpr likely 1. Fine.

Now, compute `W/2` etc per pixel; precompute reFactor = view.scale, and offsetX = view.cx - (W/2)*scale. Then re = offsetX + px*scale. Similarly im = offsetY + py*scale. Precompute per pass or per row. Good optimization.

For a row y: im = offsetY + y*scale. Then loop x: re = offsetX + x*scale. Increment re by scale each x.

Let me implement inside tick:
```
const scale=view.scale;
const offX = view.cx - (W*0.5)*scale;
const offY = view.cy - (H*0.5)*scale;
```
For each row y: cIm = offY + y*scale. For each x: cRe = offX + x*scale.

If step>1, sampling at x,y (top-left). Could sample center x+step/2. Minor. Use x,y.

Write the pixel loop.

Let me write it all.

For performance, hoist buf32, maxIter, etc.

I'll now create the file.

Let me also include a small crosshair? Not needed.

Reset view button: id resetBtn, click -> resetView().

Let me write.

Also to "keep controls responsive during rendering" — time budget and rAF handles it.

Now about the HUD: show "Zoom: X" computed as initialScale/scale.

Let me write final.

I'll also add a "render complete" indicator maybe not.

Let me write the HTML.

One more: prevent context menu on drag? Not needed.

Also cursor: grab/grabbing.

Let me code the palette LUT with more variety. Use three frequencies:
r = 0.5+0.5*cos(2π*(t+0.0))
g = 0.5+0.5*cos(2π*(t+0.33))
b = 0.5+0.5*cos(2π*(t+0.67))
This gives rainbow-ish smooth.

Actually to make it prettier, maybe darken edges. Fine.

Write file.

After writing, run browser to check console and screenshot.

Let me produce the code.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
<title>Mandelbrot Explorer</title>
<style>
  html,body{margin:0;padding:0;height:100%;overflow:hidden;background:#000;font-family:system-ui,sans-serif;}
  #c{display:block;width:100vw;height:100vh;cursor:grab;touch-action:none;}
  #c.dragging{cursor:grabbing;}
  #ui{position:fixed;top:12px;left:12px;display:flex;gap:8px;align-items:center;z-index:10;}
  button{...}
  #hud{position:fixed;bottom:12px;left:12px;color:#cfd8e3;font-size:12px;...}
</style>
```

Let me write it out fully.

For the zoom factor: wheel deltaY. factor = Math.exp(deltaY * 0.0015)? Typical wheel deltaY ~100 → exp(0.15)=1.16 per notch. Maybe too small. Use 0.002 → 1.22. For zoom in deltaY negative. factor = Math.exp(-deltaY*0.002)? Let's define: deltaY<0 (scroll up) => zoom in => scale decreases. factor = Math.exp(deltaY * 0.002). If deltaY negative, factor<1 → scale decreases → zoom in. Good. Clamp factor to [0.2,5] to handle trackpads.

Scale clamps: minScale = 1e-15, maxScale = initialScale * 20 (zoom out limited). Actually allow zoom out to maybe initialScale*4.

Let me write.

Now code the render job.

I'll write everything now.

Let me write the index.html.

Let me run the browser to inspect.

The initial view renders correctly. The two screenshots show progressive refinement. Good.

Now test zoom centered on cursor. Let me zoom into a boundary point, e.g., the seahorse valley around (-0.75, 0.1) or the point on the left of the cardioid. Let me place cursor at a boundary point and scroll. 

Let me pick a boundary point at screen coordinates. The cardioid left cusp is around x=... center -0.6 maps to screen x=600. Scale: initial scale = max(3.4/1200, 2.7/800)=max(0.002833,0.003375)=0.003375. So complex x range = W*scale = 4.05, centered -0.6 → re from -2.625 to 1.425. Hmm that's wider than intended because height constraint dominates on 1200x800. That's fine.

Boundary point: the cusp between cardioid and bulb at re=-0.75. screen x = 600 + (re - (-0.6))/scale = 600 + (-0.15)/0.003375 = 600 - 44.4 = 555.6. At y=400 (im=0). Let's scroll zoom at (556, 400). Actually let's zoom into a more interesting boundary, e.g. the point (-0.75, 0.1)? But verify cursor stays. Let me use (556, 400).

I'll use browser click? The browser tool has actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. Scroll action probably scrolls at x,y with delta. Let me check parameters: action scroll with x,y,delta maybe. Let me try scroll at x=556,y=400 delta=-500 (zoom in). Actually sign: scroll delta negative likely zoom in given exp(deltaY*0.002). Let me do multiple scrolls.

But first I need to know the behavior of the scroll tool. Let me try.

Actually, let me place cursor on a boundary feature and zoom several notches, then screenshot and check that feature is centered at cursor and detail rendered.

Let me pick the "seahorse valley" at (-0.743, 0.131)? screen x = 600 + (-0.743+0.6)/0.003375 = 600 - 42.4 = 557.6; y = 400 + (0.131)/0.003375 = 400+38.8=438.8. Hmm that's on boundary near the top-left of cardioid. Let's use (558, 439).

Let me scroll there. I'll call scroll with x=558,y=439, delta=-400 several times. Let's see how tool works.

Hmm, the scroll delta -600 gave zoom 3.32x. But the resulting view center is -2.015, -0.943. That seems wrong! I expected zooming at (558,439) near re=-0.743, im=+0.131 to keep that point near cursor. Instead the center moved to -2.0, -0.94. That's a huge shift, and the point under cursor should have stayed at (-0.743, 0.131). Let me check: after zoom 3.32x centered at -2.015 - 0.943i, the point at screen (558,439): re = cx + (558-600)*newScale. newScale = initialScale/3.32 = 0.003375/3.32=0.0010166. re = -2.015 + (-42)*0.0010166 = -2.015-0.0427=-2.058. That's not -0.743. So the cursor didn't stay fixed!

Wait, why? Let me reconsider. Oh! The issue: `scroll` tool may not pass coordinates to the wheel event. It might scroll at default position (0,0) or center. Actually the delta -600 gave factor = exp(-600*0.002)=exp(-1.2)=0.301 → newScale = 0.003375*0.301=0.001016 → zoom 3.32x. Correct factor. But the anchor point: if px,py were (0,0) or something else, then it shifts. Let me check: If anchor at (0,0): p = complexFromScreen(0,0) = cx + (0-600)*scale = -0.6 -600*0.003375 = -0.6-2.025 = -2.625; im = 0 + (0-400)*0.003375 = -1.35. After: cx = p.re - (0-600)*newScale = -2.625 + 600*0.001016= -2.625+0.61=-2.015. Yes! matches -2.015. im = -1.35 - (0-400)*0.001016 = -1.35+0.406=-0.944. Matches! So the wheel event used clientX=0, clientY=0 — the scroll tool ignored x,y and dispatched at (0,0).

So the app's zoom centering is correct; the test tool just scrolled at origin. To test centering under cursor, I should use a real wheel event with coordinates. The browser tool's scroll doesn't set coordinates apparently. Maybe I can dispatch a synthetic wheel event via... I don't have an eval tool. Hmm. I could add a temporary test harness? Or use the click/drag tools. 

Alternatively, maybe scroll action supports x,y but the harness dispatches at 0,0. Let me try scroll again with different x,y to see if center changes. Actually the formula matched (0,0) exactly, so yes.

I can still verify zoom centering mathematically. But better to verify in-browser. I could inject a script by adding a query param? No eval tool. I could temporarily add code to index.html that runs a self-test on load and logs to console, then remove. But that changes file. Alternatively, I can add a permanent, harmless feature? No.

Better: use the browser's own capabilities — maybe the scroll action respects x,y only for scrolling the page, not wheel events. Let me test by doing a drag and zoom at center, or use "motion".

Actually, I can verify cursor-centered zoom by a different approach: use the scroll at origin is fine to test zoom; the math for cursor anchoring is standard and I can reason. But the task says verify. Let me try to dispatch a real wheel with coordinates by using the "click" at a location then "key"? No.

Let me check if there's a way to run JS. The tools listed: browser with actions. No eval. But maybe I can create a second HTML file that includes index.html in an iframe and dispatches events? But then it's a different file, not the artifact. Still for testing. But cross-origin? Same origin file. I could write test.html that loads index.html in an iframe and dispatches a wheel event at coordinates, then reads the HUD. That's a good verification. However the browser tool loads index.html specifically? It says "Run index.html". Maybe I can't navigate to test.html. Hmm.

Alternative: temporarily append a test script to index.html that dispatches a synthetic wheel event at a chosen coordinate after load, logs results, then remove it. Since the browser tool reloads index.html, the test runs. Let me do that.

Plan: Add temporary script that after 500ms dispatches a WheelEvent at clientX=558, clientY=439 with deltaY=-600, and also logs before/after center and the complex point under cursor. Then reload, inspect console, then remove the test code.

But wait, synthetic WheelEvent with clientX set — our handler reads e.clientX. Good. Let's do it.

Actually simpler: I can compute expected. But let's verify properly.

Let me add temporary test code. I'll append before closing of the IIFE or after. I'll add at end of script a test block guarded by a flag, and remove later.

Let me edit.

Now I need to trigger window.__test. But I have no eval tool. I can add a script that calls it on load automatically. Let me modify the test to run on load with setTimeout, but the test needs to happen after resetView. Let me add a setTimeout that runs the test a few times.

Actually I'll just call window.__test directly in the boot. Let me edit.

The reload returned before the 400ms timeout probably. I need to wait and re-inspect console. Let me do another inspect after a delay. But inspect doesn't wait. Let me use motion or screenshot after some time. Maybe issue a command that takes time. Let me just call inspect again — it might be a new frame later. Actually the tool returned frame at +0ms. Let me call screenshot to advance time.

The test confirms the point under the cursor (-0.741750000, 0.131625000) stayed exactly fixed across three zoom steps (drift ~0 or 1e-16). Great — cursor-centered zoom works. Zoom reached 36.6x with max iter 1266 and detail rendered. 

The image shows the boundary area with detail (black region on right, colorful filaments). Wait, the point (-0.74175, 0.1316) — is it a boundary point? It shows the view centered around there. The right half is black (inside set). Actually (-0.743, 0.131) is a known point in seahorse valley. Looks plausible.

Now test drag pan and Reset. The test left zoom at 36.6x. Let me remove the temp test code first, then reload, then use drag to pan, then click Reset and compare to initial.

Actually let me test drag and reset while test code present? The temp test auto-runs on load and zooms, which interferes. Let me remove temp test code now.

Let me remove the temp test block.

Now reload and test drag. Use drag from (600,400) to (750,480) maybe. Then screenshot, then click Reset, then screenshot and compare with initial.

Let me reload first.

Now test drag. Use drag from (600,400) to (400,300). This should move center. Then inspect.

Drag panned correctly: center moved from (-0.6,0) to (0.075, 0.3375). Dragging left by 200 and up by 100 moved the image content right/down; center increased in both. Correct (drag direction: moving pointer left moves view center right). Actually with drag, you're grabbing the image and moving it, so center moves opposite to drag: drag left → center increases re. Yes. And drag up (dy=-100) → center increases im (since im increases downward). Consistent.

Now click Reset and compare with initial.

Reset restored center (-0.6,0), zoom 1.00x, matching the initial framing exactly.

Now, let me double-check the final file has no temp test code. Let me grep.

No temp test code, no external http references. Good.

Let me also verify the file is self-contained and there are no issues with the `pointerdown` on the canvas capturing drag. Already tested via drag action.

One more consideration: the browser tool's scroll at (0,0) earlier caused a huge pan because clientX=0. In a real browser, the wheel event's clientX/clientY are the cursor position, so it's fine. The earlier test was an artifact of the test harness. Our synthetic coordinate test confirmed correct behavior.

Potential issue: On touch devices, `touch-action: none` set on canvas. Good. Wheel preventDefault passive false. Good.

Another potential issue: resize handler rescales view incorrectly. It preserves zoom (ratio) and sets scale = computeInitialScale()/zoom. But computeInitialScale depends on new W/H. Center preserved. That's reasonable.

Edge: When zoomed in very far, maxIter 5000, step=8 pass has W*H/64 pixels ~ 15k, each up to 5000 iters = 75M ops, ~75ms. That could exceed one frame and block. The while loop checks time only per row, so a single row at step 8 is W/8=150 pixels *5000 = 750k ops, fine. So budget respected per row. Good.

But wait: at step 8, one "row" loop processes 150 blocks. At 5000 iter worst case ~ 750k*... each iter ~ few ops, maybe 5M ops ~ 5ms. Acceptable per row granularity. Fine.

The render loop calls updateHud each tick, throttled to 100ms. Good.

Also, the initial buffer fill uses INSIDE_COLOR black; reset startRender doesn't clear, but coarse pass overwrites all. Good.

One thing: on wheel we call startRender each event. With trackpad many events, each cancels and restarts; coarse pass shows. Fine.

I think it's complete. Let me do a final quick check that the console has no errors — only the sandbox warning. Confirmed.

Let me take a final screenshot maybe of a nice zoom to ensure detail. Already did at 36x. Good.

I'm done. Report.