Mandelbrot explorer · hy4

We need build single index.html. Need carefully implement responsive rendering, smooth escape time, zoom centered cursor, pan drag, reset, iterations adapt zoom, progressive/async rendering to keep controls responsive. Need use browser inspect initial and console, interactions. Need perhaps browser tool screenshot and DOM. Need understand tools browser actions. Let's inspect directory first maybe. We'll write robust app.

Need think design.

Full screen canvas maybe canvas covering viewport, UI overlay panel top left / bottom. Need adaptive devicePixelRatio perhaps render at resolution capped for responsiveness. Need progressive tile/chunk rendering via requestAnimationFrame or time-sliced rows, cancel generation when navigation changes, use low-res preview quickly then high-res detail; controls responsive. Use Web Workers? Inline worker via Blob URL technically no external resources/network; could create worker from string. But maybe simpler to compute in chunks on main thread with rAF and low complexity. Requirement keep controls responsive during rendering. Time-sliced rendering per row/blocks (e.g. 6ms) yields event responsiveness. Use offscreen ImageData, progressively render from low resolution pass then full res. Could draw in rows via putImageData with dirty rectangle; ensure low res preview remains until overwritten. Need avoid visual weirdness. Could implement progressive passes at increasing resolutions (e.g. quarter resolution stretched, then half, then full) in chunks, all into corresponding offscreen canvases. But needed recompute after navigation rather than static scaling — any view change triggers new calculations. Low-res first is fresh calculation of same bounds, then higher res. We can use one display canvas and one render canvas perhaps. For each generation:
- compute at display pixel dimensions maybe cap DPR / perhaps use CSS pixels * min(dpr, 1.5) and cap total pixels ~2 million for responsive.
- draw low-resolution preview at e.g. scale 1/4 into small offscreen canvas; stretch to main canvas.
- then render full resolution row-by-row into ImageData? Need show progressive full-res while preserving lower-res preview. Could use low-res offscreen and a full-res ImageData, initialize full-res ImageData from scaled low-res pixel values initially? Then fill rows with exact calc and putImageData dirty rows. But all view calculations launched after nav, so fine. We can initialize full-res image with upscaled low-res (static preview derived from fresh computation) and progressively replace with full-res values. That's "recompute after navigation rather than scaling static image": yes low-res is computed anew and then full res recomputed. Up

scaled preview transient is okay, but to be strict each navigation recomputes. Might be a tester checking calls/behavior? likely manual visual. Need ensure zoom into recognizable boundary point stays near cursor while more detail rendered. Math correct.

Architecture:
- canvas #fractal absolute full viewport. CSS body margin 0 overflow hidden, background black, touch-action none.
- overlay UI: title/instructions, buttons Reset view, maybe zoom out? Requirement Reset view. Add status text with center, zoom, iterations, render progress; maybe coordinates readout optional. Need not obscure.
- Maybe crosshair? point under cursor? Could add marker for last zoom focus? Might make verification easier but potentially visual clutter. We can implement a subtle ring at recent zoom anchor that fades; no need.
- Controls: pointerdown set dragging, pointer capture, track start and initial center / bounds. Panning by pixel delta to complex delta: center = initial center - (dx / width)*spanX; y: complex imaginary coordinate mapping needs choose orientation. Standard canvas y down; complex imaginary coord usually y up. Let map pixel (px,py) to re = centerX + (px - width/2)*scale, im = centerY - (py-height/2)*scale where scale = complex units per CSS pixel = span/width (span horizontal); vertical span = height*scale. Panning: dragging image with pointer means when move pointer right, fractal should shift right, centerX decreases by dx*scale; dragging down fractal shifts down, centerY increases by dy*scale (since screen y down maps to negative im). So centerX = initialCenterX - dx*scale, centerY = initialCenterY + dy*scale. Alternatively interactive "live pan" could recalc on each drag move? Requirement dragging pans image; recompute fractal after navigation. We can implement during drag with an immediate transform of existing offscreen canvas for feedback, then recompute on pointermove throttled and final. But simplistic: during drag, draw cached current canvas shifted by dx,dy; when pointerup, update center and recompute. That "pans image with pointer" and recomputes after navigation. But if gap edges, maybe wouldn't be ideal. Better update bounds on each pointermove and recompute at low res/full progressive; but heavy operations can start/cancel on each pointer move. Could use live fresh low-res preview and final high-res after drag. Need ensure visual. We can cancel current renderer and call schedule render with debounced

~40ms on drag; need still compute. Also preview shift can place scaled cached canvas for immediate movement, then low-res calculation takes over. But fresh recompute after each drag motion more proper.

Could implement dynamic transform during drag: on pointermove, update center based on delta and call `startRender(view, {quick:true})` that does low-res pass chunks then maybe full only when settled. Need avoid too many full renders. The renderer can always compute a low-res pass quickly then full; every pointer move cancels previous. Because low-res pass at quarter resolution ~120k ops and maybe 250 iterations worst case, could still be costly but chunked with cancellation. On a 1200x800 canvas, quarter-resolution ~300x200 = 60k pixels * average maybe 50 iter = 3M, okay ~10-20ms. Full res 960k * maybe 100+ = expensive, but chunked at 6ms per frame. Each pointermove cancels. Could use a lower "interactive" pass at 1/6 during drag and full-quality after pointerup or 100ms idle. Also transform cached frame for immediate feedback. Let's design sophisticated but manageable.

Need smooth escape-time gradient:
For each pixel:
```
let zr=0, zi=0, zr2=0, zi2=0, n=0;
while (zr2+zi2 <= 4 && n < maxIter) { zi = 2*zr*zi + ci; zr = zr2 - zi2 + cr; zr2=zr*zr; zi2=zi*zi; n++; }
if n>=maxIter -> inside color (near black perhaps deep navy) distinct.
else smooth = n + 1 - Math.log2(Math.log(sqrt(zr2+zi2))) maybe:
nu = Math.log2(Math.log2(zr2+zi2)/2?) Need correct.
Standard: `mu = n + 1 - Math.log(Math.log(Math.sqrt(zr2+zi2))) / Math.log(2)` for z->z^2+c and bailout radius 2. Since log(sqrt(mag2)) = .5 log(mag2). Then smooth. Need clamp. Use high bailout radius maybe 256 to improve smoothing; but then cardioid membership check can optimize. With bailout `ESCAPE_R2=1e6?` Need color. Use smooth `mu = n + 1 - Math.log2

(Math.log(Math.sqrt(mag2)))`. For classic bailout 4, sqrt(mag2) just >2, log(sqrt)=~0.69, log2 ~ -0.53, so mu n+1.53 potentially. Fine; smooth interpolation works. Use high bailout 256^2 = 65536, extra iterations but more accurate and smooth. At deep zoom perhaps okay.

Color gradient procedural. Could use cyclical palette via cosine or stops. Need "smooth escape-time color gradient, with a distinct color for points treated as inside set." Implement multi-stop color interpolation using log-scaled smooth iteration to avoid bands. A pleasant palette: near black at low μ? Actually outside near set should dark blue/purple then cyan, gold, etc. Use palette stops:
0: [8,10,30] deep navy
0.08: [25,45,105]
0.18: [10,115,170]
0.32: [35,210,205]
0.48: [240,220,120]
0.64: [235,110,55]
0.78: [100,30,95]
0.9: [25,20,75]
1: [8,10,30]
Then map `t = (Math.log(mu+1)*something + something) % 1`. To maintain a continuous cyclic gradient across iterations, `t = (mu * 0.025 + 0.02) % 1` perhaps cycle every 40 iterations. At initial view with maxIter ~300, most exterior points escape quickly; large regions have near uniform dark. Could use log scaling to spread low values: `t = (Math.log2(mu+1)*0.12) % 1`, cycle every 8 doublings; or use palette from 0 to 1 based on log(mu)/log(maxIter), then add bands? Requirement gradient; smooth. We can use `t = fract(0.035 * mu + 0.72)` for cycle. Maybe vivid. Color palette with cosine functions produces smooth:
```
const a=[0.5,0.5,0.5], b=[0.5,...], c=[1,1,1], d=[0,0.1,0.2];
rgb = a + b*cos(2π*(c*t + d))
```
But inside distinct black; use a palette known:
```
r = 0.5+0.

5*cos(6.283*(t+0.0))
g = ...
```
Need sufficiently distinct inside color e.g. `#05070c` deep charcoal with faint blue. Outside can have bright colors. Apply slight distance-based shading? smooth enough.

Could use palette stops with interpolation and map `t = Math.sqrt(mu / maxIter)`? At high max iterations, all low escapes map near 0, huge dark region. Need log. Use `t = Math.log(1 + mu) / Math.log(1 + maxIter)` and then maybe multiply by 3.5 and fract to create repeating bands; palette continuous at wrap if stops start/end same. This reveals zoom detail because maxIter grows with zoom, but if maxIter increases, map changes colors drastically upon zoom. Could be acceptable but zoom anchored test maybe image detail changes. Better fixed absolute iteration based palette (`t = fract(mu*0.027 + 0.62)`) so colors stable across zoom until higher iteration values reveal cycles. That's typical. High iteration points near boundary get cycling gradient. Add subtle shading based on smooth iteration. Let's use a palette ramp from dark blue to purple to orange to cream to cyan etc repeated:
```
const PALETTE = [
[5,8,24],
[15,30,90],
[50,80,170],
[20,170,205],
[250,225,145],
[235,105,55],
[110,35,110],
[15,20,70],
[5,8,24]
]
```
`colorPos = (Math.log2(1+smooth)*0.11) % 1` cycle every ~9 doublings, not iteration count; at low iterations t evolves quickly, at high slowly. Could instead `t = (smooth*0.025) % 1` cycle every 40 iterations; high detail has bands. Combine perhaps `t = (0.03*smooth + 0.08*Math.log2(1+smooth)) % 1`. At initial view t for n 1: .03+.08=.11; n 5: .15+.2=.35; n 50:1.5+.45=1.95 -> 0.95; nice. Need continuous. Use palette interpolation. Precompute LUT of 2048 RGB values for speed. Map `t = (smooth * 0.027 + 0.055 * Math

.log2(smooth+1) + 0.72) % 1`. Use `paletteLut[Math.floor(t*LUTN)]`. For inside set, [4,5,8] perhaps. Maybe add interior color distinct dark (almost black) while outside is colorful; at boundaries interior remains black. Could make inside deep midnight blue #060711 with a slight radial based on derivative? Not needed.

Optimization:
- periodicity/cardioid/bulb checks to quickly mark inside:
```
const q=(cr-0.25)^2+ci^2;
if (q*(q+(cr-0.25)) <= 0.25*ci^2 || (cr+1)^2+ci^2 <= 1/16) inside
```
- maybe periodicity checking to speed deep interior; could implement Brent cycle detection, but complexity. Main interior detected cardioid/bulb; other interior components require maxIter, expensive but okay with time slicing and cap.
- maxIter adaptive based zoom: `base 260 + Math.floor(Math.log2(zoom)*55)` maybe zoom relative initial `initialScale/scale`. At deep zoom e.g. 1e6 (~2^20): 260+1100=1360. Need sufficient detail. Could use `Math.round(180 + 90*Math.log2(zoom))`, cap maybe 3000. At 1e5 = 1670, good. At 1e10 = 3160. Need responsiveness chunked. Add zoom limit maybe 1e13 due float precision. Double precision can support ~1e13 before pixel precision issues; set maxZoom 1e12 or 5e12. Initial span 3.5 units over 1200 px scale .0029. At 1e12, pixel ~3e-15 near double precision. Good max ~1e12. Could perhaps use perturbation or BigFloat but not needed. We can cap zoom at 1e12 and show status "precision limit". Ensure wheel zoom factor maybe 1.2 per delta; normalize deltaMode. Zoom around pointer:
```
const p = screenToComplex(clientX, clientY)
const factor = Math.exp(-deltaY*0.0015) maybe if wheel down positive zoom out factor<1. Limit.
scale *= 1/factor; 
center = p - (p - center)/factor? Derive.
```
Let `newScale = oldScale / factor`

where factor >1 zoom in. Complex coordinate under cursor before: p = center + offset*scale (with im sign). To keep p fixed: newCenter = p - offset*newScale, offset in pixel units. More generally `newCenter = p + (center - p) * (newScale / oldScale)` = p + (center-p)/factor. For scale ratio r = newScale/oldScale, center' = p + (center-p)*r. For both x and y because linear.
Use screen coordinates from CSS pixel dimensions; note canvas buffer may have DPR scaling. Keep W,H = CSS dimensions and use high-res buffer perhaps. Define map based on CSS pixel coordinates, scale complex per CSS pixel. Render buffer dims = round(W*resolution). For render pixel coords need scale per render pixel = view.scale / resolution. Use center mapping:
```
re = center.x + (x + .5 - rw/2) * scale/resolution;
im = center.y - (y + .5 - rh/2) * scale/resolution;
```
where horizontal span = W*scale. Need initial view with complete main cardioid and surrounding lobes. Standard initial bounds x [-2.5,1], y [-1.25,1.25] (3.5 wide, 2.5 tall); for typical 16:9 viewport, using width-based scale 3.5/W gives vertical span 3.5*H/W ~1.97 for 16:9, which may crop top/bottom bulbs around y±1? Need view initial should show complete main cardioid and surrounding lobes. Cardioid extends roughly x[-0.75,0.25], y±0.65; period-2 bulb x[-1.25,-0.75], y±0.25; satellite bulbs around x maybe -1.75 and y ±? Mandelbrot extends y ±1.1 around x~-0.1? Actually set is within |im|<=1.2. Need vertical span at least 2.5 to show full. For widescreen 16:9, if horizontal span 3.5, vertical span 1.97 -> crops top/bottom. Need set initial bounds to include full set based on viewport aspect ratio: desired complex box x [-2.25, 0.85]? width 3.2? y [-1.3,1.3], height 2.6. Common

initial [-2.5,1.0] × [-1.25,1.25] gives 3.5x2.5. For 1200x800 (3:2), vertical span 2.333 if width 3.5, slight crop. Need adapt scale = max(3.5/W, 2.6/H), so horizontal span can be >3.5 on wide screens, and contains both. Then center x maybe -0.7? bounds x center ± spanX/2: initial center -0.75, span 3.5 => [-2.5,1.0]. centerY=0, vertical required 2.6; scale=max(3.5/W,2.6/H). On 1200x800: 3.5/1200=.0029167, 2.6/800=.00325 -> use .00325 => horizontal span 3.9 -> [-2.7,1.2], vertical ±1.3. good. On 16:9 1200x675: 3.5/1200=.002917, 2.6/675=.003852 -> horizontal span 4.62 -> [-3.06,1.56] set smaller but complete. On portrait, horizontal span maybe 3.5, vertical huge, fine. Maybe use initialCenterX=-0.75, centerY=0. Maybe shift -0.6 to balance? Main cardioid and lobes nicely centered around -0.5. Common bounds [-2.2,1.2], center -0.5. Need complete main cardioid and surrounding lobes: set extends x [-2,0.47], y ±1.12. Use centerX=-0.7 and initial required box [-2.5,1.1], [-1.3,1.3]. Good.

Can compute initial scale from `INITIAL_HALF_HEIGHT=1.35`, `INITIAL_HALF_WIDTH=1.9`, center x=-0.7 maybe left=-2.6 right=1.2. Let scale = max(3.8/W,2.7/H). At 1200x800 -> .003375 -> horizontal span 4.05, bounds [-2.725,1.325], vertical ±1.35. Set appears somewhat small but fine. Maybe exact common: center (-0.7,0), scale = max(3.4

/W,2.6/H). x bounds at 1200x800 using .00325: [-2.65,1.25]. Good. At initial we can set scale based on fitting x half-range 1.8 and y half-range 1.3: `scale=Math.max(3.6/W,2.6/H)`. This yields horizontal span 3.9; center -0.7 => [-2.65,1.25]. Nice. y ±1.3. Use `INITIAL_VIEW = {cx:-0.7, cy:0, scale: computed}`. Define `zoom = initialScale/scale`; status shows e.g. 1.00×.

Rendering system details:
Canvas display full screen. Need set canvas.width/height perhaps dpr-limited. We can use a render buffer at some resolution `RES = Math.min(devicePixelRatio || 1, 1.5)` and cap total pixels to e.g. 2.2M. At 1200x800, dpr 1 likely 960k. At high DPR 2, 1200*800*1.5^2=2.16M, okay. At larger 1920x1080, 1.5^2=4.67M too much; cap scale to sqrt(2.2M/(W*H)) ~1.03. So resolution factor dynamic. Use CSS scaling to viewport. Need perhaps test browser tool viewport 1200x800. Could choose 1.0 always to keep responsive; devicePixelRatio likely 1. Full-screen canvas at CSS pixel resolution works. For more crisp could use `Math.min(dpr,1.25)` with cap 1.5M. But high iteration detailed computation can be heavy. We can permit users toggle quality? Not needed. Use dynamic resolution based on viewport and DPR:
```
const maxPixels = 1_600_000;
function pixelScale() {
 let desired = Math.min(devicePixelRatio||1, 1.5);
 return Math.min(desired, Math.sqrt(maxPixels/(cssW*cssH)));
}
```
Ensure >=0.75 perhaps. Set `rw = Math.max(1, round(W*q))`; `rh=...`. During dragging maybe render low-res preview and compute full at final. We'll render to an offscreen canvas same dimensions as main, then draw scaled. Actually if main canvas buffer dims=rw,rh and CSS width

W,height H, we can putImageData directly to main at rw/rh. For preview lower res, use a separate offscreen preview canvas (rw/4 x rh/4) and drawImage stretched onto main; then full-res `ImageData` initialized from preview perhaps. Need progressive direct putImageData of rows; if we putImageData full buffer at once initialized with stretched preview and then overwrite chunks, that's good. Need create full imageData once (`ctx.createImageData(rw,rh)`) and populate with upscaled preview values. But filling full buffer with nearest-neighbor preview is O(rw*rh) and can be done via drawing preview to a working offscreen canvas then `getImageData` to get the upscaled pixels. This isn't an external fractal image, just transient computed preview. Then use that as baseline. We can avoid full buffer copying by:
- Create `workCanvas` same rw,rh.
- preview canvas at rw/passScale, rh/passScale; compute preview into `previewData` chunked.
- Once preview complete, putImageData to previewCanvas; draw stretched to workCtx; then `fullData=workCtx.getImageData(0,0,rw,rh)`.
- Start full pass rows progressively: fill row segment into `fullData.data`, then `ctx.putImageData(fullData,0,0,0,y,rw,rows)` draws dirty rectangle to main canvas. But `putImageData` with dirty rect from fullData uses the full image data source and only renders dirty region; yes. Need parse signature `putImageData(imageData, dx, dy, dirtyX, dirtyY, dirtyWidth, dirtyHeight)`. Source fullData at same dimensions. Good.
- Could skip half-resolution pass; low preview (1/6) then full. Preview computations should be chunked too. At 1200x800, preview 200x133 ~27k pixels; maxIter 260; interior sets might be costly. Chunk by rows with time budget. Might complete in a few frames (~20ms). During that, we can transform cached old frame for immediate feedback. Need avoid heavy full pass during every wheel event; debounce full pass maybe 80ms.

Need architecture with render generation token and state:
- `view = {cx,cy,scale}`.
- `lastFrame` perhaps an offscreen canvas holding last completed/current main canvas. At navigation start, copy current main canvas to `snapshotCanvas` (same rw/rh dimensions)

for transform preview. During drag, draw shifted snapshot each pointermove based on pan delta. But once new low-res preview ready, draw it; then full progressive. On wheel zoom events, could transform snapshot scaled around cursor for immediate feedback (approx scaling static image) but requirement recompute after navigation rather than scaling static image — transient feedback from old frame could be construed as scaling static image, but final recompute is fresh. To avoid potential critique, don't scale old frame on zoom; just leave old image until fresh preview computed. For drag, shifting old frame is also scaling/translating static image transiently. Requirement likely means don't just CSS-transform permanent image instead of recompute. Transient is okay. But we can omit snapshot transform entirely and rely on quick low-res fresh computation. Wheel events cluster; startRender cancels in-progress and computes low-res preview. Maybe within ~30ms there is fresh new view. Controls remain responsive. This is fine. For drag, similarly start renders on each pointermove; low-res fresh pass maybe 1-3 frames. Could use smaller preview scale while pointer active to speed. Need renderer supports `interactive` mode: computing preview at 1/8 resolution + maybe not full pass until settle. But then visible image is low-res until pointerup. Panning works; on release full detail renders. Requirement "Recompute fractal after navigation rather than scaling a static image" — low-res fresh calculations happen on each nav. Good.

Potential testing via browser: likely automated screenshots/motion or click/drag wheel events manually. They may zoom at some boundary point and check additional detail. Need ensure wheel events with browser tool maybe dispatch wheel with deltaY? Browser tool likely `scroll` action triggers wheel at mouse coords. Need use `{passive:false}` wheel listener on canvas / window. Prevent default. Use `wheel` on canvas and perhaps window; `e.preventDefault()`. Since canvas full viewport, pointer likely over canvas. But overlay controls might be above; wheel over UI should still perhaps zoom? Use window wheel handler and prevent default unconditionally to prevent scrolling surrounding page. That's explicit requirement. If wheel on canvas/overlay, window handler catches. Add `window.addEventListener('wheel', onWheel, {passive:false})`, call preventDefault. Need skip if target is button? Could still zoom; fine.
Wheel normalization:
```
let dy = e.deltaY;
if (e.deltaMode === 1) dy *= 16;
else if (e.deltaMode ===

2) dy *= H;
const zoomFactor = Math.exp(-dy*0.0015); // wheel up delta -100 => 1.162
```
Clamp factor perhaps [0.2,5]. Compute newScale and maxZoom:
```
const minScale = initialScale / 1e12;
newScale = clamp(view.scale / factor, minScale, initialScale*8?) 
```
Should allow zoom out beyond initial maybe up to 4x? "Reset view to restore initial bounds", zoom out can be allowed to 3x initial. But scale relative initial; maxZoom = 1e12, minZoom=0.25 maybe. Use `MAX_ZOOM = 1e12`, `MIN_ZOOM = 0.25` and `zoom = clamp(zoom*factor,0.25,1e12); newScale=initialScale/zoom`. If zoom exactly 1e12 no further zoom, status maybe. Need handle precision. Good.

Zoom anchored to complex point under cursor using CSS coordinates relative to canvas bounding rect:
```
const px=e.clientX-rect.left, py=...
const p={x: cx +(px - W/2)*scale, y: cy -(py-H/2)*scale};
const r = newScale/scale;
cx = p.x + (cx-p.x)*r;
cy = p.y + (cy-p.y)*r;
```
Yes.

Pan:
```
pointerdown:
dragging=true; startX=e.clientX; startY; startCx=view.cx; startCy=view.cy;
canvas.setPointerCapture(e.pointerId);
pointermove:
dx=e.clientX-startX; dy...
view.cx=startCx - dx*view.scale; view.cy=startCy + dy*view.scale; 
requestRender(true);
```
Note scale may change during drag? Wheel while dragging maybe; don't need. Use `startScale=view.scale` to avoid changes from wheel. Since pointer capture ensures move events on canvas even over UI? Actually capture gives all pointer events to canvas; fine.
On pointerup, dragging false, startRender(false). Need avoid wheel while dragging maybe ignore? no.
Use CSS cursor grab/grabbing.

Could include double-click zoom? Not required, but nice maybe. But not needed. Could include keyboard reset? optional.

Rendering algorithm:
Manage state and cancellation via generation ID. Need have scheduling:
```
let renderId=0;
let scheduled=false;

let pendingInteractive=false;
let settleTimer=null;
function invalidate(interactive) {
  renderId++;
  pendingInteractive = pendingInteractive || interactive? Hmm repeated.
  if (settleTimer) clearTimeout...
  ...
}
```
Simpler: each navigation calls `beginRender(interactive)`, which increments token, creates new renderer state and schedules rAF. Wheel events cluster; each kicks new render; need debounce to avoid immediate full compute:
```
function requestRender(interactive=false) {
  if (settleTimer) clearTimeout(settleTimer);
  if (interactive) {
     settleTimer = setTimeout(() => startRender(false), 120);
  } else {
     settleTimer = null;
  }
  startRender(interactive);
}
```
But every wheel event startRender(interactive=true); then after 120ms idle startRender(false). `startRender` cancels current. During pointer drag call interactive; pointerup call startRender(false). Good. Need avoid starting a fresh renderer on every pointermove at 60Hz; can schedule start at next frame with coalescing:
```
let pendingRender = null;
function requestRender(mode) {
 pendingRender = {mode};
 if (!rafScheduled) rafScheduled=requestAnimationFrame(()=> { const p=pendingRender; pendingRender=null; startRender(p.mode);});
 if mode interactive set settle timer...
}
```
But if startRender itself uses rAF chunks, need a separate rAF coordination. Could simply increment renderToken on navigation and schedule a fresh renderer via `setTimeout(0)`? Let's plan cleanly.

Use one active `Renderer` object with `token`, `phase`, etc. `cancelRender()` sets `active=null`; any rAF callback checks its token. `startRender(mode)`:
```
renderSerial++;
const serial=renderSerial;
activeRenderer = new Renderer(view snapshot, serial, mode, ...);
requestAnimationFrame((t)=> stepRenderer(t, serial));
```
If many pointermove events call startRender, each starts a new Renderer and rAF; stale callbacks exit. That's okay; no extra work beyond one frame. Could coalesce with pending flag to reduce allocations:
```
let pendingMode = null, pendingRAF=false;
function requestRender(mode) {
  pendingMode = mode === 'interactive' ? ... : 'full';
  if (!pendingRAF) {
    pendingRAF=true;
    requestAnimationFrame(()=>{pendingRAF=false; startRender(pendingMode); pendingMode=null;})
  }

```
But need immediate cancel current renderer to stop work until new one starts; call cancelRender() in requestRender. This is fine. Need possibly preserve blank? no.

However if `startRender` itself called from pointerup and an rAF is pending from pointermove with interactive, we need ensure final wins. Use `pendingMode` priority full: if any full, keep full. `pendingMode = mode==='full' ? 'full' : (pendingMode==='full'?'full':'interactive');`. Then pointerup overrides. Also settle timer calls requestRender('full').

Set `renderToken` increment on cancel; `activeRenderer=null`. Then schedule `startRender` on next rAF.

Alternatively render active directly in same frame with a persistent loop:
```
function frame(now) {
  rafId = requestAnimationFrame(frame);
  if (pending) start new renderer...
  if (active) step active with time budget...
}
```
Persistent rAF even when idle wastes tiny CPU; can stop when done and restart on nav. Simpler use `runStep()`.

Renderer class:
```
function startRender(mode) {
  const q = getResolution();
  const rw...,rh...
  ensure canvas sizes and offscreen resources only when dimensions change.
  const maxIter = calculateIterations(view.scale);
  const previewFactor = mode==='interactive' ? 8 : 5;
  const pw=Math.max(1,Math.ceil(rw/previewFactor)), ph...
  const renderer = {
    token: ++renderToken,
    view: {...},
    rw,rh,pw,ph,
    maxIter,
    previewData: previewCtx.createImageData(pw,ph),
    previewY:0,
    stage:'preview',
    fullData:null,
    fullY:0,
    mode,
    startTime: performance.now()
  };
  activeRenderer = renderer;
  updateStatus(...)
  requestAnimationFrame(t=>step(t,renderer));
}
```
Need offscreen preview canvas sized pw,ph. Could allocate each render; okay. Full work canvas maybe. Could instead create `previewData` with new ImageData via `new ImageData(pw,ph)` (supported). Safari? modern. Use `previewCtx.createImageData` safely. We'll have global `previewCanvas=document.createElement('canvas')` and context. At start set dimensions. When preview stage complete:
```
previewCtx.putImageData(previewData,0,0)

ctx.imageSmoothingEnabled = true; // maybe smoothing makes blurry but nice
ctx.drawImage(previewCanvas,0,0,pw,ph,0,0,rw,rh);
```
Need ensure main canvas resizing resets context state; set imageSmoothingEnabled after. Then if mode==='interactive', stop (no full pass). But perhaps need some full-quality detail while zooming with wheel (not dragging) after idle; settle timer triggers full. Good. For `full` mode, create full imageData from stretched preview:
```
workCanvas.width=rw;workCanvas.height=rh;
workCtx.drawImage(previewCanvas,...);
fullData=workCtx.getImageData(0,0,rw,rh);
```
But workCanvas could be main canvas itself; we just drew preview to main; can do `const fullData = ctx.getImageData(0,0,rw,rh)`. That gives stretched preview and avoids extra canvas. Then progressive exact rows overwrite fullData and putImageData dirty. Great. Main canvas is drawing target and source of baseline. Need note canvas may be tainted? No external assets, fine. `getImageData` works.

Then stage='full'. Need maybe skip pixels based on preview? no.

Step with time budget:
```
function step(renderer, now) {
 if (renderer !== activeRenderer) return;
 const deadline = performance.now() + (mode==='interactive'? 5 : 9);
 let work=0;
 while(performance.now()<deadline) {
   if stage preview: compute one row of preview (or a few rows)
   ...
   if transition: ...
   if stage full: compute one row of full (or chunk)
   ...
 }
 update progress ...
 if active schedule rAF(step)
}
```
Need ensure at least some work even if `performance.now()` weird; compute row then check. Use:
```
let ops=0;
while (ops<... && performance.now()<deadline) {...}
```
Row computation can be expensive at deep zoom (rw ~1200 * maxIter 3000 = 3.6M operations in one row) potentially >50ms, blocking. Need chunk by pixel ranges, not rows, for responsiveness. Better maintain flat pixel index and compute a block of e.g. 1000-3000 pixels, with deadline check after each block. Precompute x mapping or calculate from index. Use `for (let k=0;k<block;k++)`.

At deep zoom with maxIter 3000 and interior points, 1000 pixels*3000 = 3M operations ~10-30ms, too much. Use block 200 pixels at high iterations, 600 at low; or dynamic based on maxIter: `blockSize = clamp(Math.floor(60000/maxIter), 16, 1200)` so ~60k z-iterations per chunk. Then check deadline. On initial maxIter 260 -> 230 pixels, many chunks but okay. Could choose 150k operations budget -> 576 pixels. Time budget 8ms; 150k JS loops ~2-5ms. Use adaptive measuring? Fine.
```
const block = Math.max(24, Math.min(2000, Math.floor(120000 / maxIter)));
```
At 3000 ->40 pixels; overhead but fine. At 260 ->461 pixels. Need track `pos` flat and compute x=pos%width, y=floor(pos/width). Could avoid division/modulo per pixel by inner loop over x from current x,y:
```
while (pos<total && opsThisFrame...) {
  const y=(pos/width)|0, x=pos-y*width;
  const rowEnd=Math.min(total,pos+block);
  for (; pos<rowEnd; pos++) {
    x = pos % width? ...
  }
}
```
Simpler precompute arrays `xs` and `ys`? For rw*rh up to 1.6M, Float64Array of re coords per x and im per y. Compute coordinate arrays once per render:
```
const re0 = new Float64Array(rw), im = new Float64Array(rh);
for x... re[x] = cx + (x+0.5-rw/2)*scale/q; 
for y... im[y] = cy - (y+0.5-rh/2)*scale/q;
```
For preview pw,ph separate arrays with scale/q*rw/pw? Need mapping from preview pixel to complex coordinates. Use actual display mapping:
`re = cx + ((x+0.5)*rw/pw - rw/2) * scale/q` or equivalently `(x+0.5-pw/2)*(scale/q)*(rw/pw)`. Define `renderPixelScale = view.scale / q`; then display buffer rw corresponds to CSS W (approx), so `re = cx + (x+0.5-rw/2)*render

PixelScale`. For preview mapping with pixels covering `rw/pw` buffer pixels: `re = cx + ((x+0.5)*(rw/pw) - rw/2)*renderPixelScale`. Similarly `im = cy - ((y+0.5)*(rh/ph)-rh/2)*renderPixelScale`. Need account rounded pw and ph. Could just define based on CSS dimensions and preview canvas bounds: complex coordinate of center of preview pixel:
`re = cx + ((x+0.5)/pw - .5) * (W*view.scale)`
`im = cy - ((y+0.5)/ph - .5) * (H*view.scale)` but vertical span should be H*scale using same units per CSS pixel; center aligned. Full buffer mapping:
`re = cx + ((x+0.5)/rw - .5) * (W*scale)`
`im = cy - ((y+0.5)/rh - .5) * (H*scale)`.
This works regardless q. Let `spanX = W*scale`, `spanY = H*scale`; complex pixel scale differs slightly if q rounding introduced, but correct mapping to CSS area. Need zoom anchor use screenToComplex with W/H. For full canvas, treat full buffer width as W, so mapping as above. Good. Use coordinate arrays per pass:
```
function buildCoords(width,height,spanX,spanY,view) {
 let re = new Float64Array(width), im = new Float64Array(height);
 for x: re[x] = view.cx + ((x+.5)/width - .5)*spanX;
 for y: im[y] = view.cy - ((y+.5)/height - .5)*spanY;
}
```
Then compute pixel from arrays. Use `pos` flat:
```
const y=(pos/w)|0; const ci=imArr[y]; const x=pos-y*w; const cr=reArr[x];
```
That division and floor per pixel could be costly. Better nested loops with state x,y:
```
let x=0,y=0,pos=0;
while (pos<total) {
 const n=Math.min(block, total-pos, w-x);
 const ci=imArr[y];
 for (let i=0;i<n;i++,x++,pos++) { cr=reArr[x]; ...}
 if(x>=w){x=0;y++;}
 ...
}
```
Need time check

after each block. Store renderer `px,py,pos`. Good.

Compute function:
```
function mandelbrot(cr,ci,maxIter) {
 const x0=cr-0.25; const q=x0*x0+ci*ci;
 if (q*(q+x0)<=0.25*ci*ci || (cr+1)*(cr+1)+ci*ci<=0.0625) return -1;
 let zr=0,zi=0,zr2=0,zi2=0,n=0;
 // periodicity check optional
 let oldR=0, oldI=0, period=0;
 while (zr2+zi2 <= 65536 && n<maxIter) {
   zi=2*zr*zi+ci;
   zr=zr2-zi2+cr;
   zr2=zr*zr; zi2=zi*zi;
   n++;
   if (zr===oldR && zi===oldI) return -1;
   if (++period > 32) { period=0; oldR=zr; oldI=zi; }
 }
 if(n>=maxIter) return -1;
 const mag = Math.sqrt(zr2+zi2);
 const smooth = n + 1 - Math.log2(Math.log(mag)); // bailout 256, log(mag)>5.5, log2>2.4
 ...
}
```
Bailout radius 256^2=65536; this adds a few iterations beyond conventional 2 but okay and smoother. Periodicity check exact equality can catch cycles; use epsilon perhaps:
```
if (Math.abs(zr-oldR)<1e-14 && Math.abs(zi-oldI)<1e-14) return -1;
```
But with high zoom coordinates, tolerance should maybe smaller; exact equality is safest (periodic orbit returns exactly in floating point for many cycles). Brent algorithm would catch more. Not necessary. We can skip to reduce overhead. The cardioid/bulb checks catch huge interiors. Other bulbs (period 3 etc) will iterate full maxIter; at deep zoom, might be expensive. Add periodicity check with `period`:
```
let period=0, zxOld=0, zyOld=0;
...
if (zr===zxOld && zi===zyOld) return -1;
if (++period > 20) { period=0; zxOld=zr; zyOld=zi

; }
```
This catches fixed points and some cycles where comparison after 20 iterations aligns. But period may not divide 20? Reset every 20; if orbit period p, after 20 iterations from checkpoint, z at checkpoint+20 and checkpoint may be same if p divides20. So catches periods 1,2,4,5,10,20. Better use exponential cycle detection (Brent):
```
let power=1, lam=1, xOld=zr,yOld=zi;
each iteration:
 if (Math.abs(zr-xOld)<eps && Math.abs(zi-yOld)<eps) return -1;
 if (power===lam) { xOld=zr; yOld=zi; power*=2; lam=0; }
 lam++;
```
This detects exact repeats. But adds equality checks each loop; likely worth. Could use no eps for precision. Need complexity correctness: after updating z each n, compare tortoise; if equal, periodic -> inside; if `power === lam`, update tortoise to current z, double power, reset lam=0; then lam++? Standard:
```
power=lam=1; xOld=zr; yOld=zi;
while (...) {
 update z;
 if (zr===xOld && zi===yOld) return inside;
 if (power===lam) { xOld=zr;yOld=zi;power*=2;lam=0; }
 lam++;
}
```
Yes. But starting z=0 at n=0, tortoise=0; after update, if orbit returns to 0 (c=0 etc) catches. Might catch values with close but not equal no. Fine.
Need avoid period check overhead at shallow zoom where most points escape quickly; maybe include. Could optimize by only check if n>32. But fixed-point interiors and bulbs near boundary may be caught after ~few; cardioid handles main. Could skip altogether; maxIter ~300 and chunked. Let's keep simple with check every iteration maybe a slight cost. More robust responsiveness.

Maybe use `for` loop:
```
let n=0;
while (n<maxIter) {
  zi = 2*zr*zi + ci;
  zr = zr2 - zi2 + cr;
  zr2=...
  zi2=...
  n++;
  if (zr2+zi2 > ESCAPE2) break;
  if (zr === zrOld && zi === ziOld) return -1;
  ...
}

```
Need check escape after update. Use high bailout. Use Brent with exact equality. Could avoid `Math.sqrt` except escaped; fine.

Color computation:
```
function setColor(data, offset, cr,ci,maxIter) {
 let ...
 if (inside) { data[o]=4;data[o+1]=5;data[o+2]=9;data[o+3]=255; return; }
 const logZn = .5*Math.log(zr2+zi2); // log(|z|)
 const nu = Math.log2(logZn); // because log(|z|)/log2? Standard n+1-log2(log|z|) [log natural]
 const smooth = n + 1 - nu;
 const t = (0.68 + smooth*0.024 + Math.log2(1+smooth)*0.055) % 1;
 const idx = (t...)*LUTN ...
 // optionally brightness from fractional escape? palette smooth enough
}
```
Wait standard formula: `mu = n + 1 - log(log(|z|))/log(2)`, where `log(log(|z|))` natural log of natural log. `Math.log2(Math.log(Math.sqrt(mag2)))`. With bailout 256, log(|z|)=5.545, log2(...)=2.47, mu=n-1.47. Could be less than 0 for n=1? For points with c huge, escape after 1 with |z|>256; mu maybe -0.47. Need clamp smooth >=0. Standard formula assumes escape radius just above 2? Actually formula derives `n + 1 - log(log|z_n|)/log2`; if bailout radius R large, add correction maybe approximates fractional iteration count relative to arbitrary radius. It can be negative for huge c, but okay clamp. Use bailout radius 64 maybe log|z|=4.16, log2=2.06, mu≈n-1.06, still could negative. With bailout 4, log|z|=.69, log2=-.53, mu=n+1.53. So use conventional radius 2 and extra squaring iterations? Smooth enough with `mu = n + 1 - log2(log(sqrt(mag2)))`. For mag just over 2, fine. Actually formula uses `log(log|z|)/log 2`; yes. Then `mu >= n+1`

at small overshoot. Use ESCAPE2=4. Fewer iterations. Maybe apply extra 2 iterations after crossing to improve continuity? Smooth formula handles crossing. Use ESCAPE2=256 maybe still smooth but mapping offset can be adjusted. We can use continuous palette; phase offset doesn't matter. Clamp mu with `Math.max(0, ...)`. Fine. Use 16^2=256 as bailout, adds ~2 iterations. Need standard normalized iteration count with large bailout is `n + 1 - log(log|z|)/log2`, which is continuous; no issue. Palette t just shifted. Use `logZn = Math.log(mag2)/2`, `nu = Math.log2(logZn)`, `smooth=Math.max(0,n+1-nu)`. Good.

Inside color distinct maybe `#01030a`; could add faint interior shading based on |z| final? But all inside returns early, color solid. Requirement distinct color; solid dark near-black is fine. Maybe use deep indigo `[6,7,18]`, visible against exterior dark blue but maybe not distinct enough. Use pure black `[0,0,0]` and make outside palette never pure black; stops min [12,16,48]. Good. UI can say "Interior: black". Use `[2,3,8]` near-black. Distinct from colorful outside.

Palette LUT:
```
const stops = [
{at:0, rgb:[10,14,48]},
{at:.12,rgb:[33,49,128]},
{at:.26,rgb:[24,135,193]},
{at:.40,rgb:[74,211,198]},
{at:.53,rgb:[245,226,142]},
{at:.66,rgb:[238,121,63]},
{at:.79,rgb:[139,43,112]},
{at:.91,rgb:[39,29,92]},
{at:1,rgb:[10,14,48]}
];
for i...
```
Maybe use smoothstep interpolation between stops to avoid derivative kinks:
```
u = u*u*(3-2*u)
```
Palette cyclic. At t values near 0 modulo, colors match endpoints. Good.

Add subtle "orbit trap" or distance estimation shading maybe not needed. Could darken based on fractional? Smooth gradient already.

Iteration count:
```
function getMaxIter() {
 const zoom=initialScale/view.scale;
 const depth =

Math.max(0, Math.log2(zoom));
 return Math.min(4000, Math.round(240 + depth*95 + Math.sqrt(depth)*60));
}
```
At initial 240; at 10x depth3.32 => 240+315+109=664; at 100x=~1170; at 1000x=~1580; at 1e6=~2280; cap 5000. Is that "sufficient iterations to reveal new detail" yes. But color t based absolute smooth gives lots of cycles. Might be expensive at boundary; time-sliced. Could adapt max iterations based zoom plus scale width and current region:
Common `maxIter = 200 + 200*log10(zoom)` maybe 200->1400 at 1e6. Our ~2300 enough. Cap 6000 at 1e12 => 240+3800+... ~4260. Good.
Perhaps use `Math.round(250 + 125*Math.log2(zoom))` with cap 5000. At 1e6=2740; at 1e12=5230 cap. Fine. Use 300 + 110*depth + 40*sqrt(depth). At 1e12 depth39.9 -> 4940. Good.
Need show iterations status. Fine.

Resolution:
```
function configureCanvas() {
 const rect=canvas.getBoundingClientRect(); W=rect.width; H=rect.height;
 const q=Math.min(Math.min(dpr,1.5), Math.sqrt(1_500_000/(W*H)));
 const rw=Math.max(1,Math.round(W*q)), ...
 if changed canvas.width=rw...
 view initial scale calculation on first resize. On resize, preserve center and scale? Need initialScale maybe recomputed based new W/H; zoom state should perhaps preserve complex center and scale (units per CSS px), but on viewport resize framing changes. Reset should initial bounds for new viewport. Store `initialScale` recomputed on resize but keep `view.scale` unchanged to preserve zoom level in complex units per pixel. Status zoom uses `initialScale/view.scale`, which may change with viewport; okay. But reset returns new initialScale. Could perhaps scale view.scale proportionally when aspect ratio changes to keep visible horizontal span; not required. Need handle resize with `ResizeObserver` or window resize. Since canvas CSS 100vw/100vh, listen `window.resize`. On first `

resizeCanvas()` set initialScale from dimensions and view scale if no view. On resize, update initialScale, preserve view.scale. Trigger full render. Need avoid initial reset mismatch after browser resizes; reset uses current initialScale. Good.
Alternatively use fixed complex bounds and initialScale = max required, yes.
```
function calculateInitialScale(w,h){return Math.max(3.6/w,2.6/h);}
```
Initial center -0.7,0.
Important: test "Pan the view, then use Reset view and compare with initial framing." Reset must restore exact initial center and scale. If browser screenshot before and after same size, yes. Use `resetView()` sets view = {cx:-0.7,cy:0,scale:initialScale}; requestRender('full'). Need perhaps update status.

Rendering initial: launch on load, maybe full render takes multiple frames. Browser tool screenshot might be taken immediately after load and see incomplete image. Need ensure initial low-res preview computed quickly enough. Could render preview synchronously in `startRender`? Requirement responsive during rendering; initial preview can compute within a frame. We can perhaps do preview in chunks with 8ms budget. At 1200x800 preview factor 5 -> 240x160=38k pixels, maxIter 300; cardioid detection helps, average maybe 20-50 iter; ~1-2M ops ~10ms. Could complete in one or two frames, screenshot perhaps after page load maybe 100ms. Browser tool likely waits. Better set preview factor 6 or 8 for full mode: 150x100=15k pixels; ~0.5M ops; completes in one frame. Then full pass progressive over ~0.5-2 sec. Initial screenshot after 100ms shows stretched low-res preview, okay but recognizable. Need perhaps compute full quickly enough to show detail. At 1200x800 960k pixels * average maybe 20-100 iterations; 20-100M ops; could take 0.2-1 sec. Fine. Need maybe sync first full rows. Browser screenshot likely after 500ms; we want mostly completed. Could use Web Worker to offload rendering, truly responsive. But inline worker from Blob URL is self-contained (no network), could compute full image in worker and post chunks. However complexity with palette and progressive preview. Main-thread chunking is enough. Could use OffscreenCanvas? no need.

Could implement worker via a string

and Blob; but browser sandbox may restrict blob workers? likely works. But requirement no external resources/network, Blob local is okay. Yet debugging browser CSP? likely no CSP. Main-thread time-sliced simpler and robust.

Need compute full pass chunk rows with time budget 10ms per frame. At 960k px, if 100M ops / maybe 100M/s in JS =1s; at 10ms per frame with 16ms intervals => 1.6s. Fine. At deep zoom interior heavy maybe several seconds but controls responsive. Could show progress bar and status. Need allow cancellation mid-render: step checks active token each frame; pointer events can cancel and schedule new render. Since each chunk <=5ms, input latency ~5ms. Good.
Could use `setTimeout(step,0)` rather than `requestAnimationFrame` to use more CPU and render faster, but rAF ensures 60fps and controls. Use rAF. Maybe allocate 10ms of 16.7; good. At deep zoom, full may take many seconds; user can navigate and cancel. Status shows "rendering 37%". Fine.

Need identify boundary coordinates for test. We can perhaps add coordinate readout and "interesting locations" buttons? Not required. But verification asks zoom into recognizable boundary point; could choose e.g. seahorse valley around (-0.743643887037151, 0.13182590420533). Could include preset buttons like "Seahorse Valley" to make test easy? Not required but helpful. However adding controls could clutter; can include small chips for "Seahorse valley" and "Elephant valley" maybe. But user only asks Reset view. Could include a "Zoom to seahorse" hidden? Better not. But maybe use "Reset view" only plus coordinate readout. Automated verifier might locate canvas and wheel at boundary region based on screenshot; doesn't need preset.

Need perhaps add a subtle zoom focus marker at the cursor when wheel occurs, to visually verify anchor. Could draw a ring overlay in a separate DOM element (not on canvas, since canvas render would erase it). Maybe `#focus` absolutely positioned with CSS ring, fade out. On wheel set position to cursor and animate. But not necessary and could distract. Could add status "Zoom anchored at ..." and readouts. For verification, crosshair helps. We can implement a small `#focusRing` with pointer-events none, CSS animation, set left/top and re-trigger animation on wheel

event. But need no overcomplication. Maybe a persistent crosshair at last zoom point with coordinate label is useful. Yet screenshot comparisons may be affected. Let's keep UI minimal with title, instructions, status, reset button. Could include a tiny zoom target dot at last wheel position that fades in 600ms; likely fine. But not needed.

Need perhaps add loading indicator / progress bar. Use top panel:
```
<div class="hud">
  <div class="title">Mandelbrot Explorer</div>
  <div class="sub">Drag to pan · Scroll to zoom at cursor</div>
  <div class="stats">
    <span id="zoom">1.00×</span>
    <span id="iterations">300 iterations</span>
    <span id="progress">rendering…</span>
  </div>
  <button id="reset">Reset view</button>
</div>
<div class="help">...</div>
```
Could show center coordinates. Add a legend with interior black swatch. Maybe.
Need ensure clicking button doesn't start drag; canvas listener only. Window wheel handler includes clicking unaffected. `canvas` behind HUD; pointer events on HUD may not reach canvas, but reset works. Dragging from HUD should perhaps not pan, okay. Could set HUD pointer-events auto; canvas handles rest. If wheel over HUD, window handler zooms anchored at cursor — acceptable.
Need prevent touch page scrolling with `touch-action:none` on canvas/body and `overflow:hidden`.
Wheel handler on window:
```
if (e.ctrlKey) ...? no need
e.preventDefault();
if (Math.abs(delta)<... ) return;
```
Trackpad wheel deltas small; factor smooth. Need perhaps cap. Use `Math.exp(-dy*0.0012)`; trackpad delta ~2 -> .9976, smooth. Mouse wheel delta 100 ->1.127. Use deltaMode 1 (lines) *16, deltaMode2 pages*H. Clamp `dy` to ±400 to avoid huge jumps; factor exp ±0.48 => up to1.6. Good.
Wheel events might have `deltaX` for horizontal; ignore. Could use `deltaY` only.

Need maybe zoom centered at complex point under cursor exactly with canvas CSS coords; yes. Need ensure if canvas buffer resolution q differs, mapping uses CSS W/H. Good.

Panning update center based on `startScale` (units per CSS px). On pointer move

with CSS coords, use dx * startScale; y sign +. Need test mathematically: Suppose center=0, scale=1, point at screen x=0 (left); drag pointer right dx=10, centerX=-10. New coordinate at screen x=0 = -10+... Wait coordinate mapping: p(x)=center+(x-W/2)*scale. If center=0 and scale=1, a feature initially at complex c=0 appears at x=W/2. After drag right by 10, we want feature screen x=W/2+10. Need center' such that c=center'+(x'-W/2)*scale =>0=center'+10 => center'=-10. Correct. y: feature at im=0 initially y=H/2. Drag down dy=10, want y'=H/2+10. Mapping im=centerY-(y-H/2)*scale =>0=centerY-10 => centerY=10. Our +dy*scale gives +10. Correct.

Reset: set exact initial center/scale; perhaps if wheel zoom out, still resets. Good.

Viewport resize: need preserve complex center and maybe scale; schedule render. Need initial scale recomputed. If first load, initialize. Use `resize()`:
```
const oldInitial=initialScale;
W=innerWidth;H=innerHeight;
const q...
if(canvas.width!==rw ||...) {canvas.width=rw;...}
initialScale = ...
if (!initialized){ view.scale=initialScale; initialized=true;} else { maybe view.scale *= initialScale/oldInitial to preserve zoom relative initial framing? }
```
Which is better for reset comparison? If resize occurs between initial and reset, keeping scale relative might matter. Suppose initial screenshot at 1200x800 then browser rotates? not likely. We can choose on resize to preserve visible complex span relative to new viewport: `view.scale *= initialScale / oldInitial`, which keeps zoom ratio and center but changes bounds proportional to viewport. That means reset returns original framing for new viewport; okay. But user may have panned/zoomed; scaling their scale based on window size is reasonable. Yet if initialScale changes from .00325 to .00385 due height shrink, view.scale multiplies 1.18, preserving zoom ratio. Good. Let's implement.
Need perhaps respond to `devicePixelRatio` changes via window resize; okay.

Rendering coords arrays on each start render; memory okay. Stage transition:
```
function renderChunk

(r, deadline) {
 while (performance.now()<deadline) {
  if (r.phase==='preview') {
    if (r.pos>=r.previewTotal) { finishPreview(r); continue; }
    computeBlock(r, 'preview');
  } else if (...) ...
 }
}
```
Need ensure no infinite loop if transition full and mode interactive:
```
function finishPreview(r) {
 previewCtx.putImageData(...)
 ctx.save(); ctx.setTransform(1,0,0,1,0,0); ctx.imageSmoothingEnabled=true; ctx.drawImage(...); ctx.restore();
 if (r.mode==='interactive') { finishRender(r,'preview ready'); return; }
 r.fullData=ctx.getImageData(0,0,rw,rh);
 r.phase='full'; reset pos...
 update status...
}
```
Need perhaps clear canvas before drawing preview; drawImage covers full canvas. Good.
`putImageData` ignores transforms and alpha composite. We don't use transforms. fine.
Full-stage `putImageData(fullData,0,0,0,startY,rw,rows)` after computing a chunk that may span rows. Need track dirty region from starting `pos` and ending `pos`. Could compute to block boundaries possibly spanning rows. Since block could span rows, easiest wrap block at row boundary by `n = Math.min(block, w-x, total-pos)`, and keep dirty rows from startY to current y inclusive. After each chunk, call putImageData with dirty rect from `dirtyY0` to `r.y` + maybe 1. We can simply call after each chunk with dirty rect `(0, dirtyStartY, rw, r.y-dirtyStartY+1)` where `r.y` may have incremented to next row; could include an extra row not yet computed but its baseline preview values are okay. Then set `dirtyStartY=r.y`. If multiple chunks in one frame, repeated putImageData could be expensive but okay. Better accumulate computed region over entire frame and put once at end. Need careful with dirty region from `frameStartY` to `maxY`. We can record `minY` and `maxY` of computed pixels and call `putImageData` once after loop. If stage changes mid-frame, draw baseline etc; handle. Simpler call `putImageData` after each chunk with `dirtyY = startY`, `height = y - startY + 1`. A dirty rect of up to 2

rows if block ≤ w, 2*rw pixels; at 1200 wide, 2400 pixel copy, negligible. There may be ~100 chunks per frame at deep zoom? block size 30, ~300 chunks; each putImageData 2 rows ->720k pixel copies, maybe heavy. Better accumulate at frame level and flush once. Let's implement flush per phase at end of step:
- During full compute, set `r.dirtyStart` and `r.dirtyEnd` initially null; for each chunk, startY=r.y, compute, endY = min(rh-1, r.y maybe after row increment). Add.
- At end of step, `if (r.dirtyStart !== null) ctx.putImageData(r.fullData,0,0,0,r.dirtyStart,rw,r.dirtyEnd-r.dirtyStart+1); r.dirtyStart=null;`
But if renderer changed phase or finished, fullData still valid; flush before finish. Need also ensure preview stage writes previewData only, no visual updates until complete. Could perhaps draw partial preview progressively? Not needed. Could draw low-res preview at e.g. row chunks by putting partial data to previewCanvas and stretching; but preview completes quickly. Could leave old image for 1-2 frames. Fine.
- At full completion, flush and set progress 100%, active=null, status "ready". Need no further rAF.
- On renderer cancellation, active=null, no need flush. Old image from previous view remains until new preview drawn, perhaps up to 2 frames. Fine.
- For interactive mode finish at preview stage; status "preview · settling…" maybe then settle timer full render. Need display that full detail pending. Use status text.
- For full mode, show progress percentage based full pos and perhaps weight preview. Could show "detail 42%" etc.
- Need update stats on view change immediately: zoom, center, maxIter maybe from function. Use `updateHud()`.
- progress element can show a thin bar via CSS width. Add `#bar`. On render progress set width. During preview 2%; during full `2 + 98*pos/total`. On done 100% and maybe hide bar with opacity 0 after timeout? Could keep subtle.
- Need status zoom use compact formatting: `formatZoom(zoom)` with suffix K, M, B, T or scientific. Example 1.00×; 1.2K×, 3.4M×. At up

to 1e12, 1.0T×. Good.
- Coordinates with 12 decimals maybe dynamic based scale:
```
const digits = clamp(Math.ceil(-Math.log10(view.scale))+2, 3, 14)
```
At initial .003 =>5 digits; deep zoom 1e-15 =>14. Show center re/im. Could be optional; nice for verification. Add `#coords`.
- Status "Interior is black" perhaps legend.
- Need avoid heavy DOM updates each frame? update progress text every step ~60Hz is okay. Could throttle to ~100ms. Use `lastHudUpdate`. Not critical. Use if `now-lastStatus >80 || percent===100`.
- Need handle a lot of wheel events. `requestRender('interactive')` starts a new render on next rAF; settle timer 110ms. If user wheel at boundary and screenshot after maybe 1s, full render may still be in progress. Need ensure enough detail rendered. We can optimize. Could perhaps use full mode directly on wheel (not interactive) with debounce 40ms; then fresh preview and full progressive immediately. Repeated wheel events cancel; after last, full continues. That may be better for verification. During a rapid wheel burst, each event starts fresh full render but time-sliced; after last full render finishes. No need settle timer. But starting full render on each wheel may allocate coordinates arrays + ImageData etc; maybe okay but 60 events could be heavy. Debounce 30-50ms to coalesce. Yet user wants additional detail rendered. A settle timer of 90ms ensures full starts soon. Fine. Need maybe wheel handler calls `requestRender('interactive')` with `settle 90ms`; browser scroll action might trigger one wheel event, then full render 90ms later. screenshot after maybe 500ms shows progress maybe 30%; still "additional detail". Could use 60ms. At default wheel event repeated, 60ms after last full. Good.
- On pointerup call full immediately. Reset full immediately. Initial full immediately.
- For wheel, perhaps use mode 'full' with debounced start 45ms; no interactive preview until after burst. But if only one wheel event, 45ms delay then full preview+detail. Controls still responsive. Could implement a generic `requestRender(mode, debounceMs)`:
```
function scheduleRender(mode) {
 if (mode==='interactive') { cancel active; pending...; settle

timer=setTimeout(()=>requestRender('full'),80); }
 else request...
}
```
Need not overcomplicate. We'll use interactive preview during wheel/drag and settle 80ms. Browser render pass likely enough.

Could deep zoom via repeated wheel events; each interactive preview uses maxIter and preview factor 8 (150x100) maybe at deep zoom with many interior points maxIter 3000 -> 15k*3000=45M operations; even preview could take multiple frames and be canceled by next wheel. Fine. Need perhaps lower maxIter for interactive preview? Requirement sufficient iterations to reveal new detail after zoom; final uses full maxIter. Interactive preview could use `min(maxIter, 400)` to stay fast. But then color/framing maybe inaccurate; final full correct. Could set `previewIter = Math.min(maxIter, Math.max(180, Math.round(maxIter*0.45)))`; low-res preview still gives shape. However interior classification at deeper zoom requires high iterations; with truncated iterations, some boundary points misclassified as inside, but final fixes. Fine. Yet stretched preview should be close. To avoid mismatch, use same maxIter but low pixel count and cardioid/periodicity optimization. Let's keep same; preview computation chunked and cancelable. At deep zoom near boundary, 15k*5000=75M ops, could take ~0.5s, so no fresh preview during rapid zoom. Could lower preview resolution to 1/10 (~120x80=9.6k), and cap preview iterations 600. That gives ~5.8M ops, 50ms. Good. Use `previewIter = Math.min(maxIter, 700)` for preview. But at zoom 1e12, many points near boundary that need >700 to escape would be black in preview; final reveals detail. That's expected "additional detail is rendered". Could be a nice visible difference. Need ensure color palette consistent; full uses higher maxIter. Fine.
Could also use lower dimension factor based mode:
- full mode preview divisor 6 (rw/6,rh/6).
- interactive divisor 10.
- previewIter 500 interactive, maxIter maybe up to1000 full mode.
Let's compute initial full preview at 1200x800 ->200x133=27k*240 =6.5M ops perhaps 30ms; fine.
At deep zoom full preview ->27k*1000 cap maybe 27M ops ~150ms

chunked. Could use cap 700. final full 960k*5000 huge but progressive. Worth. We can use previewIter = Math.min(maxIter, 650) always, and preview divisor 6. Then initial preview ~17M ops (27k*650) but most escape quick; maybe ~2M. At deep zoom boundary, 17M ~50ms; okay. Fine.
Need note `maxIter` for final based snapshot view; if user navigates, renderer cancels. Good.

Could improve final pass by skipping pixels whose low-res preview classified deep interior? Not safely; need full detail. no.

Need implement direct computation function with palette LUT and inside:
```
function shade(re,im,maxIter,data,p) {
 // cardioid checks
 ...
 let zr=0, zi=0, zr2=0,zi2=0,n=0;
 let px=0,py=0,power=1,lam=1;
 const escape=256; // R^2=65536
 while(n<maxIter) {
   zi = 2*zr*zi+im;
   zr = zr2-zi2+re;
   zr2=zr*zr;zi2=zi*zi;n++;
   if(zr2+zi2>escape) break;
   if(zr===px && zi===py) {inside;return;}
   if(power===lam){px=zr;py=zi;power*=2;lam=0;}
   lam++;
 }
 if(n>=maxIter)inside
 ...
}
```
Need initialize px,py maybe `zr=0,zi=0` before loop and check after each iteration; standard. Fine.
But the periodicity check may wrongly classify an escaping orbit that temporarily returns to a previous `z`, but if exact return, orbit is periodic and bounded; safe. Floating exact repeat of chaotic orbit generally means cycle. Good.
Cardioid check:
```
const x=cr-0.25, y2=ci*ci, q=x*x+y2;
if(q*(q+x)<=0.25*y2) inside;
if((cr+1)*(cr+1)+y2<=0.0625) inside;
```
Correct.
Inside color `[3,4,9]`; outside palette minimum [10,14,48] ensures distinct.
`data[p+3]=255`; when fullData from preview, alpha already

255. For previewData initially alpha 0 for uncomputed pixels, but we only draw after all computed; make sure all pixels set including inside. If render canceled mid-preview no draw. Good.
Need maybe color LUT uses Uint8ClampedArray of length N*3. Build with stops.
```
function sample(t) { ... }
```
Need handle `t` negative: smooth clamped >=0 and formula base positive, so fine.
Use LUT index `Math.min(LUTN-1,(t*LUTN)|0)`. Since t in [0,1).
Maybe add brightness modulation based on `Math.sin`? no.

Need compute coordinate arrays maybe `Float64Array`. For each phase can allocate re/im arrays. `r.re` preview etc. We can store in object:
```
r.pRe = buildX(pw, spanX,...)
r.pIm = ...
r.fRe... built at transition maybe to reduce initial work.
```
At start build preview arrays only. At transition build full arrays. This spreads work. But transition happens in `step`, and building full arrays is small (rw+rh ~2k). fine.
Need define `computeBlock(r, pass, maxIter, deadline)` uses local variables for speed:
```
function computeBlock(r, pass, maxIter, blockLimit) {
 const d = pass.data, width=...,total=...
 const reArr=...,imArr=...
 let pos=r.pos,x=r.x,y=r.y;
 const end=Math.min(total,pos+blockLimit,pos+(width-x));
 const ci=imArr[y];
 for(;pos<end;pos++,x++) {
   shade(reArr[x], ci, maxIter, d, pos<<2);
 }
 if(x>=width){x=0;y++;}
 r.pos=pos;r.x=x;r.y=y;
 if(pass.full){...dirty...}
}
```
But if blockLimit may exceed remaining row, we truncate to row end, good. Need record `startY=y` and `endY` after. If all pixels in row and x resets y++, dirty end should be startY only, not y. Use `endY = (pos===total? rh-1 : (y > startY ? startY : y))` hmm with truncation at row end, only one row computed; if `pos` reaches total mid-row, endY=startY. So always `endY=startY` because

we truncate to width-x. Good. Then dirty range startY to startY. Great. We can mark dirty rows per block. Because block never crosses row, no issue.
Need use different state for preview and full. Could define pass object with `pos,x,y,total,w,h,data,reArr,imArr,maxIter,dirtyStart,dirtyEnd`. Then one `computePass(pass, block, markDirty)` function.
```
function finishPass(r)...
```
Renderer:
```
r.preview = {kind:'preview', ...};
r.full=null;
r.phase='preview';
```
When preview done:
- `putImageData(preview.data,0,0)` into previewCanvas.
- draw to main.
- if interactive finish.
- else create `fullData = ctx.getImageData...`; build coords; `r.full={...}`; phase='full'.
Need perhaps use `ctx.imageSmoothingQuality='high'`; okay.
When full done:
- flush dirty rect
- `activeRenderer=null; progress 100`.
Need `step`:
```
function step(r, now) {
 if(r!==active) return;
 const deadline=performance.now()+(r.mode==='interactive'?7:9);
 let guard=0;
 while(performance.now()<deadline && guard++<1000) {
   const pass=...;
   if(!pass) break;
   if(pass.pos>=pass.total) { finishPreview...; continue; }
   const block=Math.min(pass.block, pass.total-pass.pos, pass.w-pass.x);
   computePixels(pass,block,...)
   ...
 }
 if(r.full) flushDirty...
 updateProgress(r)
 if(active===r) requestAnimationFrame(t=>step(r,t));
}
```
Need ensure at least one block computed if `performance.now()>=deadline` (e.g. timer resolution). Use do/while:
```
let first=true;
while((first||performance.now()<deadline)&&...) {first=false;...}
```
At full stage with 9ms budget, block ~400 pixels, maybe 5-20 blocks. Need guard maybe 10000, no issue.
`block` dynamic:
`Math.max(16, Math.min(1500, Math.floor(120000/pass.maxIter)))`.
At maxIter 5000 ->24 pixels; each chunk ~120k iterations perhaps ~2ms; 4 chunks per frame. At 960k pixels /24=40k chunks /4=10k frames = way too slow

(2.7 minutes) at deep zoom. Need larger budget / more efficient. 120k operations per chunk * 4 per 9ms =480k iter/frame; 960k px*average maybe not all maxIter; if boundary region all 5000 =>4.8B ops, cannot render quickly anyway. Could use lower cap iterations or progressive refinement. Need balance. At deep zoom near boundary, full resolution could take tens of seconds. Requirement "keep controls responsive during rendering", not necessarily fast. But verification zoom after a few wheel clicks maybe zoom 10-100x, maxIter ~600-1000; with 150k ops/chunk, 200 pixels; 5 chunks/frame=1000 pixels/frame ->960 frames (~16s) if all maxIter. But most points escape quickly. Could still be slow. We can improve by computing final at adaptive resolution or use progressive resolution passes. Maybe full resolution at 1200x800 with 1000 iterations near boundary can take >1s but not 16s if average 50 iterations. Most pixels within view around boundary may still have high iterations near filaments; perhaps 10-20% high. Need enough.
Could use parallel Web Workers (maybe 2-4) to speed while main thread stays responsive. But complexity and browser sandbox. We can create Blob worker from inline string; use multiple workers and transfer ImageData buffers. Could render full tiles in worker, post results; main thread remains fully responsive and faster. Could still do low-res preview on main. But need careful cancellation and no external resources. This may be ideal. However 15 min budget, can implement. Need decide.

Simpler main-thread chunking likely acceptable for typical tests (few zooms, 1200x800, maxIter ~500). We can optimize maxIter growth less aggressive: `base 220 + 50*log2(zoom)`, at 100x=552, at 1e6=1217, at 1e12=2200. "Sufficient iterations" at 1e6 maybe 1200 is enough for many boundary points, though deep seahorse might need more. Could dynamically increase iterations based on scale: some recommend `1000 * log10(1/scale)`. We can use ~250+100*log2(zoom) capped 3000. At 100x=914; 1e6=2243. Fine. Main thread maybe

still okay.

Could do progressive passes at lower resolution before full: preview 1/6, then 1/3, then full. If full is slow, user still sees increasingly detailed fresh-rendered images. Requirement "additional detail is rendered" likely satisfied by 1/3 pass quickly. Also can settle on a medium pass while full computes. Implement passes at divisors [8,4,2,1]? Each pass computes fresh fractal at its own resolution and can draw scaled. But that's 1+1/4+1/16+... ≈1.33 times full pixel count, manageable. Crucially each pass's pixel count lower and can show detail earlier. Could then full progressive rows. We can structure multi-pass rendering:
- Pass 0: divisor 8 interactive/full initial preview.
- Pass 1: divisor 4 (1/16 pixels) maybe compute into offscreen and draw stretched.
- Pass 2: divisor 2 (1/4 px) compute.
- Final: divisor1 full. But each render uses same maxIter? Could use cap for early passes. This gives visible progressive detail. But "keep controls responsive" still chunked. Need more code.
Could instead render final full in an interlaced order that refines globally, e.g. compute every 4th row/column then fill gaps from nearest computed pixels. More complex.

Maybe use a single full-resolution ImageData initialized from low-res preview and compute progressive interlaced pixel sets (e.g. pass rows with stride 4 then 2 then1) so detail emerges globally. For each pass, compute at full resolution subset and write to fullData, then draw whole canvas. This is elegant: after preview, create fullData from stretched preview. Then compute exact full-res pixels in interlaced passes:
- pass strides: 4,2,1 (or 8,4,2,1), for y rows and x columns. For stride s, compute only pixels where (x%s==offsetX? no) Need cover all exactly once. We can use Morton-like sequence or simply iterate all positions and skip those not in current phase based on `(x|0)` and `(y|0)`? If stride 4 first compute pixels where x%4==0 && y%4==0 (1/16). Then stride2 compute pixels where x%2==0 && y%2==0 but not already computed (3/16). Then stride1 compute all remaining (12/16). Need

fill uncomputed pixels by copying nearest computed color so image refines. Could update fullData from preview baseline and only exact computed pixels; putImageData whole canvas after each chunk or at frame end. This progressively sharpens. Final pass computes all exact. Total exact pixels once. But implementation of skip conditions and efficient loops more complex. Could use a flat `pos` loop with nested x,y and conditions; even skipped pixels incur loop overhead but okay. At stride4 pass iterates 960k positions to compute 60k; at stride2 iterates 960k to compute180k; stride1 iterates960k to compute720k; total 2.9M iteration overhead, small relative fractal. Could do. At each phase, iterate all pixels and for each compute if should be handled. Need determine "not already computed":
```
level=4: x%4===0 && y%4===0
level=2: (x%2===0 && y%2===0) && !(x%4===0&&y%4===0)
level=1: all others
```
Could define level assignment based on divisibility:
```
if(x%4===0 && y%4===0) level=0;
else if(x%2===0 && y%2===0) level=1;
else level=2;
```
Then each pass computes only `passNo===level`. Need fill uncomputed spots with nearest computed pixel color to visually refine; can do a cheap nearest-neighbor replication after each phase at full resolution using `ImageData` copy, but that is O(rw*rh) and may create a scaled mosaic. Could initialize from low-res preview, then after level0 computed, copy each computed pixel into its 4x4 block; after level1 into its2x2 block, then final all. That would show increasing detail. At pass boundaries, call `refineImage(fullData, computedMask, blockSize)` perhaps:
- Need know which pixels computed; could use a Uint8Array mask. For each computed pixel at (x,y), copy its RGB to neighboring block coordinates. At level0, computed at x,y multiples of4; copy to x..x+3,y..y+3. At level1, computed at even coords not multiple of4; copy to 2x2 blocks. But need ensure overwriting order; can simply for each computed pixel copy to its 2x2 block. Then final pass computes remaining odd coordinates. This yields

nice progressive resolution. But extra complexity. Could perhaps skip replication; baseline low-res preview is already stretched smoothly, and exact pixels appear as a grid of sharp dots until final. Not ideal, though at 60fps user may see mosaic. Could draw fullData into main each frame; exact computed rows/subpixels blended with baseline. Maybe acceptable.
Simpler multi-pass offscreen canvases at increasing resolution with smooth scaling; each pass is complete, so no mosaic. Let's implement that! Sequence:
- For each render, create `passes` with divisors [8,4,2,1] maybe.
- For each pass, create ImageData of `ceil(rw/div)` × `ceil(rh/div)`, compute all pixels (using preview maxIter? final maxIter).
- On completing each pass, put to offscreen canvas, draw stretched to main. For final pass (div=1), perhaps progressively update via putImageData dirty rows. But if we compute complete final ImageData then draw once, user waits and sees 1/2-res until complete, but controls stay responsive. Requirement recompute after navigation, yes. Additional detail rendered eventually. Could progressively draw final pass dirty rectangles to main over the 1/2-res stretched version. Need initialize final ImageData from stretched 1/2 pass, then overwrite computed rows. This is manageable and provides progressive detail.
- Early passes can use lower maxIter cap to speed, final uses full maxIter. Sequence:
  1. divisor 8, iterations min(maxIter,350), compute quickly, draw stretched.
  2. divisor 4, iters min(maxIter,600), draw stretched.
  3. divisor 2, iters min(maxIter,1000), draw stretched.
  4. divisor 1, iters maxIter, initialize from current canvas (2x stretched), compute row chunks and update dirty rows.
Total pixel counts of early passes: 1/64+1/16+1/4 = .33 full; okay. At deep zoom with maxIter 3000, early passes ~320k pixels*~1000 max = maybe 300M ops, chunked; still can take seconds. Lower caps or fewer passes at high zoom. We can use divisors [10,5,2,1] and caps [250,500,900,full]. At initial maxIter 240, all same. At deep zoom, early preview ~10k*250=2.5

M, 1/25 pass ~38k*500=19M, 1/4 pass ~240k*900=216M worst; maybe too much. Could skip 1/2 pass at deep zoom or cap 500. Additional detail still eventually from full. Simpler sequence [8,3,1] with caps [250,600,full]: early pixel fractions 1/64+1/9≈.127; okay. At 1e6 zoom maxIter2200, 1/3 pass ~107k*600=64M worst, chunked ~0.3-1s; fine. Full progressive. Good.
- Interactive mode: only first pass divisor 12 with capped iter, then stop; full mode starts [8,3,1] after idle. To avoid computing first pass twice on wheel, could settle full start from scratch with 1/8; fine.
- Need initial render show recognizable shape quickly: first pass divisor8 ~15k pixels, maxIter 240 -> <10ms; draw stretched. Then divisor3 ~107k*240=25M worst maybe 50-100ms; then full progressive. Initial screenshot after ~100ms shows 1/3 res fresh image, decent. Good.
- At deep zoom, full pass may take long but controls responsive; status progress.

This multi-pass architecture can be coded with generic pass objects and stage transitions. Need ensure at each pass we assign maxIter and coordinate arrays. Need offscreen canvas with pass dimensions. Could reuse one `previewCanvas`, resize per pass; when resizing, context state resets, fine. Need `ImageData` creation. On completion:
```
previewCanvas.width=pw;...
pctx.putImageData(pass.data,0,0);
ctx.imageSmoothingEnabled=true;
ctx.clearRect...
ctx.drawImage(previewCanvas,0,0,pw,ph,0,0,rw,rh);
```
For final pass:
- don't draw stretched from its own canvas; instead initialize fullData from current canvas (which is 1/3-res stretched):
`const fullData=ctx.getImageData(0,0,rw,rh);`
- pass.data=fullData, pass.w=rw,pass.h=rh, maxIter full.
- compute all pixels progressively, updating `pass.data` exact values, and dirty rect flush.
- For early passes, no dirty flush needed until complete; maybe could draw partial pass by filling remaining pixels from previous canvas, but no need

because short.
- We may want to show progress text based weighted pass progress. Could use simple stage names: "preview", "refining 1/3", "detail 37%". Good.
- Need compute early passes chunked with deadline, including heavy 1/3 pass. Controls responsive. If navigation event occurs mid-pass, active renderer cancels; no drawing of partial pass. But first pass likely completes on frame; second maybe several frames, so during rapid wheel events only old image remains until first pass of new render (which is quick). Good.
- On each pass transition, draw fresh computed image, satisfying recompute after navigation even while full detail pending.
- Need final pass repeatedly putImageData dirty rows from fullData. Since fullData initialized from stretched pass, all alpha 255. Good.
- Need progress bar: assign weights e.g. [0.03,0.12,0.85] based pixels? Could simply compute total "work units" = sum(pass.w*pass.h*pass.maxIter maybe) but dynamic. Use `workTotal` and `workDone` accumulate `pixelsComputed * maxIter` maybe. At chunk, add `count*pass.maxIter`; progress = workDone/workTotal. But interior points may be shorter and full worst-case; visual progress bar would lag behind actual. Simpler stage-based:
```
first pass 0-8%, second 8-25%, final 25-100%.
```
Compute `base + weight*(pass.pos/pass.total)`. Fine.
- Need full pass exact maxIter, early pass capped. This means colors/details change as iteration cap increases; visually demonstrates additional detail. Good.
- For interactive mode only one pass at divisor12 and maxIter min(maxIter,300), then status "preview — refining when idle". If no settle timer? schedule one. On pointerup/reset initial full.
- For wheel `requestRender('interactive')`, settle timer 90ms -> full render. If wheel events continue, reset timer. Need if active full render (e.g. from prior settle) and another wheel occurs, cancel. Good.

Could perhaps call full render immediately after wheel if no follow-up? 90ms is okay. Need ensure wheel event not captured as browser `scroll` action maybe tool sends delta and then waits. Good.

Need be wary of requestAnimationFrame scheduling and cancellation with pending start:
```
let activeRenderer = null;
let renderSerial = 0;
let pendingMode = null;
let startRAF

=0;
let settleTimer=0;

function cancelActive() {
 if (activeRenderer) { activeRenderer.cancelled=true; activeRenderer=null; }
 renderSerial++; // callbacks check serial
}
function requestRender(mode) {
 if (settleTimer && mode!=='interactive') {clearTimeout...} // perhaps
 if (mode==='interactive') { reset settle timer ...}
 pendingMode = mode==='full'?'full':(pendingMode==='full'?'full':'interactive');
 cancelActive();
 if (!startRAF) {
  startRAF=requestAnimationFrame(()=>{
   startRAF=0;
   const m=pendingMode || 'full'; pendingMode=null;
   startRender(m);
  });
 }
}
```
But if `mode==='full'` from settle timer, should not cancel a pending full. Fine. `cancelActive` doesn't necessarily need serial if active null; each renderer object identity check enough. Stale step callbacks check `if(activeRenderer!==r)return;`.
- If requestRender('interactive') schedules settle timer:
```
clearTimeout(settleTimer);
settleTimer=setTimeout(()=>{settleTimer=0;requestRender('full');},80);
```
But calling requestRender('full') might clear settleTimer again; need avoid. In requestRender:
```
if (mode==='full' && settleTimer) { clearTimeout(settleTimer); settleTimer=0; }
```
Then schedule if interactive. Good.
- If pointerup requestRender('full'), clears timer. Reset also full.
- Drag pointermove calls interactive repeatedly; active canceled and startRAF coalesced. Could potentially call `cancelActive()` on every pointermove even if no active yet; fine.
- On wheel, we should update view immediately, update HUD, call requestRender interactive. Good.
- On pointerdown, perhaps cancel rendering and request interactive? If no movement yet, no need; but to keep dragging responsive, cancel full render so input isn't competing. Call `cancelActive()` via `requestRender('interactive')`? That would start preview even though view unchanged; not harmful. Maybe set a `suspend` flag. Could call `cancelActive()` directly on pointerdown and set pending full after pointerup. But then no new render until pointermove; current image remains. Good. Need avoid `renderSerial` perhaps. Could implement `stopActive()` with no rAF. On pointerdown call `stopActive()`

and clear settle timer. On pointermove request interactive. On pointerup request full. This reduces work while dragging. Let's do.
```
function stopActive(){ activeRenderer=null; }
```
Stale callbacks check object. No serial needed.
- Need handle no pointermove then pointerup: request full renders same view. fine.

Start render:
```
function startRender(mode) {
 const dims=...
 const viewSnapshot={...view};
 const maxIter=iterationsFor(viewSnapshot.scale);
 const passes= mode==='interactive' ? [{div:12, iter:Math.min(maxIter,350), label:'preview'}] : [
 {div:8, iter:Math.min(maxIter,300),label:'preview',base:0,weight:6},
 {div:3, iter:Math.min(maxIter,750),label:'refining',base:6,weight:19},
 {div:1, iter:maxIter,label:'detail',base:25,weight:75,final:true}
 ];
 const r={...,passIndex:0,passes, maxIter};
 activeRenderer=r;
 preparePass(r);
 update status;
 requestAnimationFrame(t=>stepRenderer(r,t));
}
```
Need viewSnapshot. `initialScale` from current viewport; status zoom from viewSnapshot perhaps.
`preparePass(r)`:
```
const spec=r.passes[r.passIndex];
const pw=Math.max(1,Math.ceil(r.rw/spec.div));...
if(spec.final){
 // current canvas holds previous pass; getImageData baseline
 spec.data = ctx.getImageData(0,0,rw,rh);
} else {
 previewCanvas.width=pw;...
 spec.data=pctx.createImageData(pw,ph);
}
spec.w=pw...; spec.re=buildX(...); ...
r.px=0;r.py=0;r.pos=0;r.dirty...
```
But need avoid mutating shared spec? passes are per renderer, fine. For final pass, if previous pass wasn't drawn because of some issue? start full mode always runs all passes; by transition, previous drawn. Good. For interactive mode, no final.
Coordinate arrays computed from `spanX = W*viewSnapshot.scale`, `spanY=H*viewSnapshot.scale`; for a pass width pw, mapping `cx + ((x+.5)/pw-.5)*spanX`; height similarly. This maps pass canvas to full CSS viewport. Good. For final rw maybe slight aspect mismatch due rounding

but negligible.
Need create `ImageData` via `new ImageData(pw,ph)` perhaps faster. We can use `passCtx.createImageData`. For final, `ctx.getImageData`.
Compute pass chunk:
```
function computeChunk(r, deadline) {
 const p=r.currentPass;
 const n = Math.min(p.w-r.x, p.total-r.pos, p.block);
 const ci=p.im[r.y];
 const data=p.data.data;
 let o=(r.pos<<2), x=r.x;
 for(let i=0;i<n;i++,x++,o+=4) shade(p.re[x],ci,p.iter,data,o);
 r.pos+=n;r.x+=n;
 if(r.x>=p.w){r.x=0;r.y++;}
 if(p.final){...}
}
```
Need `shade` takes data and offset. `data[o+3]=255`.
`p.block=Math.max(24,Math.min(2000,Math.floor(160000/p.iter)))`. At iter240 ->667; at 5000->32. For early passes with capped iter750 ->213. Good.
Could use more operations per chunk e.g. 300000 / iter to reduce overhead, but block time maybe 3-6ms. At deep zoom with 5000 iterations and 60 pixels ->300k operations, maybe 3ms. We have 9ms budget; 2-3 chunks. Fine. Use 220000 / iter. At 240 ->916; at 5000->44. Good.
Need perhaps deadline check after each chunk. One chunk may take >9ms; unavoidable but at most 220k iterations ~a few ms. Good.
Need avoid exact equality periodicity overhead every iteration; okay.
Progress dirty flush:
```
if (p.final) {
 const sy=r.y before update? We'll record startY = r.y.
 const ey=startY; // because n truncated to row end
 if(r.dirtyStart==null) r.dirtyStart=sy;
 r.dirtyEnd=Math.max(r.dirtyEnd??0,ey);
}
```
Set dirtyStart/dEnd on r. At end of frame:
```
if(r.dirtyStart!==null) {
 ctx.putImageData(p.data,0,0,0,r.dirtyStart,rw,r.dirtyEnd-r.dirtyStart+1);
 r.dirtyStart=null;r.dirtyEnd=-1;
}
```
But if pass completes and transitions to another pass in

same frame, need flush before drawing new pass. We can call `flushDirty(r)` in `finishPass` before drawing. At end of step as well.
`finishPass(r)`:
```
if (p.final) {
 flushDirty(r);
 activeRenderer=null;
 setProgress(100,'ready');
 return false;
}
 // draw data to previewCanvas and stretch
 previewCanvas.width=p.w...; pctx.putImageData(p.data,0,0);
 ctx.imageSmoothingEnabled=true;
 ctx.drawImage(previewCanvas,0,0,p.w,p.h,0,0,r.rw,r.rh);
 r.passIndex++;
 if (r.passIndex>=r.passes.length) { ... } // interactive one pass: active=null; status 'preview'; return false;
 preparePass(r);
 return true;
```
For interactive with one pass, after draw set active null and status "preview • refining…" (settle timer will start full).
Need ensure current canvas dimensions r.rw/r.rh still match global; if resize occurs during render, we cancel via requestRender; stale renderer checks active each frame, but may finish a chunk before resize event? resize event handler calls stopActive. Fine.
Need `ctx` context state after canvas resize: `imageSmoothingEnabled` may reset. Set before every draw.
Need `getImageData` from main canvas with potentially CSS-transformed rendering? Canvas internal pixels unaffected. fine.

Stale rAF callbacks:
```
function stepRenderer(r, now) {
 if(activeRenderer!==r)return;
 ...
 if(activeRenderer===r) requestAnimationFrame(t=>stepRenderer(r,t));
}
```
If `finishPass` sets activeRenderer=null, no further scheduling. Good.
Potential issue: `requestRender` cancels active but pending `startRAF` from a prior request. It coalesces mode. Need `stopActive` on pointerdown but pending startRAF may still fire and start a renderer despite drag. Could leave; pointermove cancels. Not a big deal.
Could make `requestRender` take priority; okay.

Need `updateHud` on view changes:
```
function updateViewHud() {
 const zoom=initialScale/view.scale;
 zoomEl.textContent=formatZoom(zoom)+'×';
 coordsEl.textContent=`${fmtCenter(view.cx)} ${view.cy>=0?'+':'−'}${fmtCenter(abs(view.cy))}i`;
 iterEl.textContent=iterationsFor(view.scale).toLocaleString()+' iters';
}

```
Need maybe negative sign formatting. Use `toFixed(digits)` can be expensive but fine. At deep zoom number of digits up to 14; `toFixed(14)` works. Digits clamp 4..14. use:
```
const digits=Math.min(14,Math.max(4,Math.ceil(-Math.log10(view.scale))+1));
```
At scale .003 =>3+1=4; at 1e-15 =>16 ->14.
Maybe text: `center −0.7000 + 0.0000i`.
Need UI panel perhaps bottom left to avoid covering main fractal center? top left okay. Full-screen canvas. Add gradient legend maybe. Use glassy dark panel with white text. Need no external fonts; use system UI font. Full CSS inline.

Need maybe include a "Reset view" button with accessible label and keyboard. Add keyboard shortcuts:
- `R` resets, `+/-` zoom at center maybe optional. But not needed.
Could add double-click zoom at point (2x) to help testing. Maybe useful, but wheel enough. Add `dblclick` to zoom 2x anchored at cursor; no harm.
Need prevent default on pointerdown to avoid text selection. Canvas no text. `e.preventDefault()`.
Need pointer capture; on pointerup/cancel call endDrag. Need if pointer leaves canvas with capture, works.
Need wheel listener on window passive false. Also maybe `document.addEventListener('wheel'...)` with preventDefault. We'll use window. Need no page scroll due body overflow hidden anyway, but explicit preventDefault.
Need touch pinch? not required. `touch-action:none`.

Potential issue with browser tool `scroll` action: It may send wheel event with `deltaY` and x/y coords. Need check. We can inspect via browser after writing. Need know browser tool's coordinate system and actions. We'll use screenshot etc.

Need possibly add JS diagnostics exposed for testing: `window.__mandelbrot = { getView, setView, reset, rendererStatus }` maybe helpful for automated checks. Not required but can help verify anchor math via DOM/console. We can expose a small read-only API:
```
window.mandelbrotExplorer = {
 get view(){return {...view}},
 get initialView(){...},
 reset: resetView,
 screenToComplex,
 get status(){...}
}
```
Could be useful for our own browser checks: call via browser? Browser tool `inspect` might

allow evaluating JS? Need see. maybe `browser` action inspect returns DOM and console, perhaps not evaluate JS. Could use screenshot only. But exposing helps maybe via console? We can use `bash` with perhaps no JS browser automation. Browser tool may allow `key`/`type` only. We'll see. We can use `browser` inspect to see DOM and maybe console logs. Could write temporary console logs with state on events, then inspect console to check zoom anchor math. Or use visible status coordinates. Good idea: on wheel, log focus complex coordinate and resulting coordinate under cursor after zoom, to console; inspect can verify equality. But console logs might be considered clutter, but fine. Could also expose `window.__lastZoomCheck`. No need perhaps.

Need ensure CSS doesn't obscure too much of fractal. HUD top left width ~310px. Reset button. bottom right maybe subtle "Black = inside" legend. Fine.

Let's draft index.html.

Detailed code:

```
<!doctype html>
<html lang="en">
<head>
<meta charset...
<meta name=viewport content="width=device-width,initial-scale=1,user-scalable=no">
<title>...
<style>
:root {color-scheme:dark}
* {box-sizing:border-box}
html,body {width:100%;height:100%;margin:0;overflow:hidden;background:#03040a;}
body {font-family:...; user-select:none;}
#fractal {position:fixed;inset:0;width:100vw;height:100vh;display:block;cursor:grab;touch-action:none;background:#03040a;}
#fractal.dragging {cursor:grabbing}
.hud {... pointer-events:auto; ...}
...
</style>
</head>
<body>
<canvas id=fractal aria-label=...></canvas>
<section class=hud ...>
...
<button id=reset type=button>Reset view</button>
...
</section>
<div class=legend>...
<div id=focusRing...
<script>
(() => {'use strict';
...
})();
</script>
</body>
</html>
```
Need no external assets. Inline everything.

Focus ring maybe:
```
.focus {position:fixed; width:34px;height:34px;border...;transform:translate(-50%,-50%);opacity:0;pointer-events:none;}
.focus.show {animation:pulse .7s ease-out}
@keyframes ...
```
On wheel set left/top; remove class, force reflow, add. Could

be helpful. But if screenshot after zoom, ring may still show; could confuse anchor test but actually indicates anchor. Fades quickly. Fine.
Need CSS `pointer-events:none` for focus ring.

HUD:
```
<h1>Mandelbrot <span>Explorer</span></h1>
<p class=hint>Drag to pan · wheel to zoom at the pointer</p>
<div class=readouts>
<div><span>Zoom</span><strong id=zoom>1.00×</strong></div>
<div><span>Iterations</span><strong id=iters>...</strong></div>
</div>
<div id=coords>...</div>
<div class=progress-label><span id=status>Rendering…</span><span id=percent>0%</span></div>
<div class=bar><i id=barFill></i></div>
<button>Reset view</button>
</div>
```
Maybe keep panel width 300. Need button clear.
Legend bottom right:
```
<div class=legend><span class=swatch></span> interior • computed live</div>
```
Need maybe fixed instructions bottom center? no.

JS details full:

Constants:
```
const canvas=..., ctx=canvas.getContext('2d',{alpha:false});
const previewCanvas=document.createElement('canvas');
const pctx=previewCanvas.getContext('2d',{alpha:false,willReadFrequently:true});
```
`willReadFrequently:true` maybe for getImageData from main; set `ctx=canvas.getContext('2d',{alpha:false,willReadFrequently:true})`. This can make canvas CPU-backed and faster getImageData; drawing putImageData okay. Browser support yes. Use `desynchronized:true` perhaps maybe flicker; skip.
Need can use `willReadFrequently` on preview ctx too, but we mostly putImageData; fine.
```
let cssW=1,cssH=1,renderW=1,renderH=1;
let initialScale=1;
const INITIAL_CENTER={x:-0.7,y:0};
let view={...};
let initialized=false;
```
`fitScale(w,h)=Math.max(3.6/w,2.6/h);`
Why 3.6/2.6? Set extends x -2 to0.5, y ±1.2; center -0.7 with halfwidth1.8 gives [-2.5,1.1], halfheight1.3. Good.
`resize()`:

```
function resize(){
 cssW=Math.max(1,window.innerWidth);
 cssH=Math.max(1,window.innerHeight);
 const oldInitial=initialScale;
 const target=Math.min(window.devicePixelRatio||1,1.5);
 const q=Math.max(0.6,Math.min(target,Math.sqrt(1500000/(cssW*cssH))));
 const rw=Math.max(1,Math.round(cssW*q)), rh...
 if(canvas.width!==rw || canvas.height!==rh){canvas.width=rw;canvas.height=rh;}
 renderW=rw;renderH=rh;
 initialScale=fitScale(cssW,cssH);
 if(!initialized){view={x:INITIAL_CENTER.x,y:INITIAL_CENTER.y,scale:initialScale};initialized=true;}
 else if(oldInitial>0){view.scale *= initialScale/oldInitial;}
 updateViewReadout();
 requestRender('full');
}
```
Problem: requestRender('full') defined later, but function declarations hoisted, okay. `resize()` called at bottom after adding listeners. But first call requestRender('full') before render system variables initialized? Need ensure variables are declared before call. We call at end after all declarations. fine.
Could `q` lower than0.6 if huge viewport; clamp to0.5; then canvas internal smaller than CSS and stretched; okay.
Need use `renderW/renderH` in startRender snapshot. If a resize event occurs, requestRender full; active canceled. But stale renderer's final `getImageData` may use resized canvas if finish pass before cancel? Resize event likely synchronous; stopActive called inside requestRender. fine.
`window.addEventListener('resize', debounce?)` use direct; maybe many events but requestRender coalesced. Good.

Palette:
```
const STOPS=...
const LUT_SIZE=2048;
const LUT=new Uint8ClampedArray(LUT_SIZE*3);
for(let i=0;i<LUT_SIZE;i++){ const t=i/(LUT_SIZE-1); find stop; let u=...; let s=u*u*(3-2*u); ...}
```
Need stops at exact0 and1. Finding stop each i with small array okay. Could precompute loop.
Inside `[1,2,6]` maybe dark.
`shade`:
```
const ESCAPE2=65536; // R=256
function shade(cr,ci,maxIter,data,o) {
 const y

2=ci*ci;
 const xm=cr-0.25;
 const q=xm*xm+y2;
 if (q*(q+xm)<=0.25*y2 || (cr+1)*(cr+1)+y2<=0.0625) {inside;}
 let zr=0,zi=0,zr2=0,zi2=0,n=0;
 let tx=0,ty=0,power=1,lam=1;
 while(n<maxIter) {
   zi=2*zr*zi+ci;
   zr=zr2-zi2+cr;
   zr2=zr*zr; zi2=zi*zi; n++;
   if(zr2+zi2>ESCAPE2) break;
   if(zr===tx && zi===ty){inside;}
   if(power===lam){tx=zr;ty=zi;power*=2;lam=0;}
   lam++;
 }
 if(n>=maxIter){inside;}
 const logZ=0.5*Math.log(zr2+zi2);
 let smooth=n+1-Math.log2(Math.log(logZ)); // Wait logZ = ln|z|; need ln(ln|z|)/ln2 = Math.log2(Math.log(logZ))? Let's carefully derive.
```
`mag2 = zr2+zi2`. `log_abs = 0.5*Math.log(mag2)` (natural ln |z|). Standard `mu = n + 1 - Math.log(Math.log(Math.sqrt(mag2))) / Math.LN2` = `n+1 - Math.log2(Math.log(Math.sqrt(mag2)))` = `n+1 - Math.log2(log_abs)`. Right! Need `Math.log2(log_abs)`, not `Math.log2(Math.log(log_abs))`. Because inner is ln|z| = log_abs, then outer is ln(log_abs), divided ln2 = log2(log_abs). So:
```
const logAbs=0.5*Math.log(mag2);
const smooth=Math.max(0,n+1-Math.log2(logAbs));
```
With bailout radius256, logAbs≈5.545, log2(logAbs)=2.47, smooth≈n-1.47. For n>=4 likely positive. For huge c escaping in one iteration with mag maybe >256, logAbs large e.g.6, log2=2.58, smooth=-1.58 ->

clamp0. Fine. This is continuous enough. But note if we use `ESCAPE2=65536`, logAbs≥5.545; smooth continuous. Good.
Could instead use `ESCAPE2=4` then logAbs ~0.7; log2(logAbs) negative, smooth n+1.5; fine. High bailout adds a couple iterations but smoother. Use high bailout.
```
 let t = 0.73 + smooth*0.023 + 0.045*Math.log2(1+smooth);
 t -= Math.floor(t);
 const k=...;
 data[o]=LUT[k];...
```
Need ensure `Math.log2(logAbs)` with logAbs>1 (bailout>e^1) so finite; yes.
Potential issue periodicity check with `zr===tx && zi===ty` initially tx=0,ty=0. If first iteration `z=c` and c is 0, caught. If c not0 but orbit returns to0, caught. fine.
Need perhaps skip cycle detection for first 8 iterations? no.
Inside function could write inside and return. To avoid function call overhead maybe define local `writeInside` function; fine.
```
function putInside(data,o){...}
```
`shade` is called ~1M times, function call itself okay. Could mark inline? fine.

Potential correctness of recurrence: Starting z0=0. For each iteration:
`zi = 2*zr*zi + ci; zr = zr2 - zi2 + cr;` But after updating `zi`, `zr2` and `zi2` still from previous z, so update `zr` using old squares and cr, correct. Then compute new squares. Good.
Need note `zi` uses old `zr`, yes.

`iterationsFor(scale)`:
```
const zoom=Math.max(1,initialScale/scale);
const depth=Math.log2(zoom);
return Math.min(5000,Math.round(260 + 105*depth + 45*Math.sqrt(depth)));
```
If zoom<1 (zoomed out), Math.max(1) ->260. At zoom1e12 depth39.86 ->260+4185+284=4729. Good.
Potential test zoom 3 wheel steps factor1.15^3=1.5 ->depth.6=>~375 iterations. enough.
Need maybe use more iterations for boundary details at specific points; okay.
Could compute

iterations based on `1/scale` rather than zoom; initial scale depends viewport. Fine.

`formatZoom`:
```
if(z<1000) return z<10?z.toFixed(2): z<100?z.toFixed(1):Math.round(z).toString();
const units=[...]; ...
```
Need not overdo.
`formatCoord`.
`updateViewReadout()` uses `itersEl.textContent = iterationsFor(view.scale).toLocaleString() + ' iterations'`.
`status` text.

Render state:
```
let activeRenderer=null;
let pendingMode=null,pendingRAF=0,settleTimer=0;
let lastProgressTime=0;
function stopActive(){activeRenderer=null;}
function requestRender(mode){
 if (settleTimer && mode==='full'){clearTimeout(...);}
 if (mode==='interactive'){...setTimeout...}
 pendingMode = mode==='full'?'full':(pendingMode==='full'?'full':'interactive');
 stopActive();
 if(!pendingRAF){
  pendingRAF=requestAnimationFrame(()=>{
   pendingRAF=0;
   const m=pendingMode||'full'; pendingMode=null;
   startRender(m);
  });
 }
}
```
Potential bug: settle timer callback `requestRender('full')` from inside itself: at callback start set `settleTimer=0` then call; fine.
```
if(mode==='interactive'){
 clearTimeout(settleTimer);
 settleTimer=setTimeout(()=>{settleTimer=0;requestRender('full');},85);
}
```
Need if mode full and pendingMode interactive from pointermove, priority full wins. Good.
Need `stopActive` on pointerdown and maybe clear pending start? Could call `if(pendingRAF){cancelAnimationFrame(pendingRAF);pendingRAF=0;pendingMode=null;}`. But if pointerdown while initial render pending, we don't want to cancel? We'll render on up. Fine. Implement `suspendRendering()` maybe:
```
function suspendRendering(){ stopActive(); if(pendingRAF) cancel...; pendingMode=null; }
```
But a step rAF might still be scheduled; active null causes exit. Good.
On pointerdown call `suspendRendering()` and clear settle timer. But if no pointermove then pointerup calls full. Fine.
Wheel while dragging: requestRender interactive; okay.
Need `updateProgress`:
```
function setStatus(text,pct,force=false){...}
```
If

frequent, throttle:
```
function reportProgress(r,pct,label,force=false){
 const now=performance.now();
 if(!force && now-lastProgress<80) return;
 lastProgress=now;
 statusEl.textContent=label;
 percentEl.textContent=Math.round(pct)+'%';
 barFill.style.width=pct+'%';
}
```
At render start call force. At done force. Need maybe hide bar when done? Could keep 100% with green/blue. Fine.
Need if active canceled, status says "updating…" perhaps requestRender sets text. Call `setStatus('Recomputing…',0,true)` in requestRender? But then stale active null and pending start. Could do. Yet every wheel event force resets, okay. Use `setStatus('Recomputing view…',0,true)`.
Need `lastProgress` variable.
Need `startRender`:
```
function startRender(mode){
 if(!initialized)return;
 const v={...view};
 const maxIter=iterationsFor(v.scale);
 const specs=...
 const r={mode,v,maxIter,renderW,renderH,spanX:cssW*v.scale,spanY:cssH*v.scale,specs,index:-1,pass:null,...};
 activeRenderer=r;
 nextPass(r);
 reportProgress...
 requestAnimationFrame(t=>stepRenderer(r,t));
}
```
Need if canvas dimensions changed since `resize`, maybe call `syncCanvasSize()` inside startRender? We can trust resize handler. But if devicePixelRatio changed without window resize, no. Fine.
Pass specs:
```
const fullCap=...;
if(mode==='interactive') [
 {div:12, iter:Math.min(maxIter,320), label:'Live preview', base:0, weight:100, final:false, last:true}
] else [
 {div:8, iter:Math.min(maxIter,320), ... weight:7},
 {div:3, iter:Math.min(maxIter,900), ... weight:22},
 {div:1, iter:maxIter, label:'Full detail', base:29, weight:71, final:true}
]
```
Need early preview at initial maxIter260, all same. At deep zoom, first cap320, second900, final4700. Color difference may be visible; okay. Could cap second at1200. Fine.
`div` should produce pw at least1. Use `Math.max(1,Math.ceil(renderW/div

))`.
`preparePass(r)`:
```
r.index++;
if(r.index>=r.specs.length){finishRender(r);return;}
const spec=...
let data;
if(spec.final){
 data=ctx.getImageData(0,0,rw,rh);
} else {
 previewCanvas.width=pw;...
 data=pctx.createImageData(pw,ph);
}
const re=new Float64Array(pw), im=new Float64Array(ph);
...
r.pass={...data, ...};
r.x=0;r.y=0;r.pos=0;r.dirtyStart=-1;r.dirtyEnd=-1;
```
Need for final pass, `ctx.getImageData` returns current stretched second pass. Since `canvas` context has alpha false, alpha255. Good. If something else (focus ring DOM) not on canvas, no issue.
Need `spanX` based CSSW but `rw` mapping to full viewport. Fine.
Need `ctx.imageSmoothingEnabled=true` before drawing. For initial full render, prior canvas may contain old fractal from previous view; first pass draw covers entire canvas. fine.
Need `previewCanvas` resizing might clear pctx state but we just putImageData. fine.

`stepRenderer`:
```
function stepRenderer(r){
 if(activeRenderer!==r)return;
 const deadline=performance.now()+9;
 let iterations=0;
 do {
   const p=r.pass;
   if(!p) break;
   if(r.pos>=p.total){
      if(!finishCurrentPass(r)) break;
      continue;
   }
   const n=Math.min(p.block,p.total-r.pos,p.w-r.x);
   const startY=r.y;
   computePixels(r,n);
   if(p.final){ if(r.dirtyStart<0)r.dirtyStart=startY; r.dirtyEnd=startY; } // only one row
   reportProgress(...);
   iterations++;
 } while(performance.now()<deadline && iterations<4000 && activeRenderer===r);
 if(activeRenderer===r) {
   flushDirty(r);
   requestAnimationFrame(t=>stepRenderer(r,t));
 }
}
```
But if `finishCurrentPass(r)` calls `activeRenderer=null` (interactive done or final done), then `flushDirty` check must still happen inside finish. At end, don't flush if active changed? Could call before check:
```
if(r.dirtyStart>=0) flushDirty(r)
```
even if

active null; harmless. But if renderer canceled by navigation, activeRenderer may be another/new renderer, flush could draw stale data on new canvas. Need check:
```
if(activeRenderer===r) flushDirty(r);
```
If final pass done and `finishCurrentPass` sets activeRenderer=null, then no flush at end; so flush inside finish before null. Good.
If renderer canceled, don't flush. Fine.
Need avoid `finishCurrentPass` returning false but active still r? For interactive last pass sets active=null and returns false. For final sets active=null. For transition returns true.
Need `do...while` ensures one chunk even if deadline passed. If `r.pos>=total` at start, finish pass then maybe next pass and `continue`; could loop transitions without computing until deadline check; do/while condition could keep going, but only 3 passes, fine.
Need reportProgress each chunk maybe throttled; okay.
Need computed `pct` function:
```
const p=r.pass;
const frac=r.pos/p.total;
const pct=Math.min(100,p.base+p.weight*frac);
const label=p.final?`Full detail · ${Math.round(frac*100)}%`:`${p.label} · ${...}`;
```
For final pass label "Full detail 42%" maybe status.
At pass transitions, force status maybe.
Need bar width.

`flushDirty(r)`:
```
if(r.dirtyStart<0 || !r.pass?.final)return;
ctx.putImageData(r.pass.data,0,0,0,r.dirtyStart,r.renderW,r.dirtyEnd-r.dirtyStart+1);
r.dirtyStart=-1;r.dirtyEnd=-1;
```
Need `dirtyEnd` set to max startY. Since chunks truncated to row end, yes. If `n` could be 0? Ensure p.w-r.x positive. When r.x==p.w we reset after chunk, so not. Good.
`computePixels`:
```
const p=r.pass, d=p.data.data, re=p.re, im=p.im;
const ci=im[r.y];
let x=r.x, o=r.pos*4;
const n...
for(let i=0;i<n;i++,x++,o+=4) shade(re[x],ci,p.iter,d,o);
r.pos+=n;r.x=x;
if(r.x>=p.w){r.x=0;r.y++;}
```
Need if r.y increments beyond p.h at end but pos==

total; no further compute. fine.
`shade` may use `p.iter` int.

`finishCurrentPass`:
```
const p=r.pass;
if(p.final){
 flushDirty(r);
 activeRenderer=null;
 reportProgress(...100,'Detail complete',true);
 return false;
}
previewCanvas.width=p.w;... // already set at prepare
pctx.putImageData(p.data,0,0);
ctx.imageSmoothingEnabled=true;
ctx.imageSmoothingQuality='high';
ctx.drawImage(previewCanvas,0,0,p.w,p.h,0,0,r.renderW,r.renderH);
reportProgress(... current end,'...',true);
r.index++;
if(r.index>=r.specs.length){
 activeRenderer=null;
 reportProgress(r, r.mode==='interactive'? ... , 'Live preview ready', true);
 return false;
}
preparePass(r);
return true;
```
Need for full mode after last nonfinal pass (div3) prepare final; final `ctx.getImageData` from current canvas after draw. good.
For interactive one pass, after draw set active=null, status "Preview ready · full detail pending". Progress maybe 8% rather than100. Use spec weight, so 100 by our weights; but status pending. Could set weights [0,12] and then 12%. Let's define interactive spec weight 12; then percent 12%. Better. Full specs weights sum100 (7,23,70). Great.
At interactive done call `reportProgress(r,12,'Live preview · full detail pending',true)`. Settle soon. No need active.
Need maybe full render starts from scratch and first pass draws again; fine.

`requestRender('full')` from settle timer calls `stopActive` (active null) and start new renderer. Good.

Zoom:
```
function screenPoint(clientX,clientY){
 const rect=canvas.getBoundingClientRect();
 const sx=clientX-rect.left, sy=clientY-rect.top;
 return {sx,sy,x:view.x+(sx/cssW-.5)*cssW*view.scale?}
```
Simplify:
`x=view.x+(sx-cssW/2)*view.scale`, `y=view.y-(sy-cssH/2)*view.scale`. Need use rect width/height perhaps cssW/H equal. Use rect.width/height for precision:
```
const w=rect.width,h=rect.height;
cx+(sx/w-.5)*(w*scale) = cx+(sx-w/

2)*scale.
```
Use `cssW`, `cssH`.
`screenToComplex(sx,sy,v=view)`.
On wheel:
```
function onWheel(e){
 e.preventDefault();
 if(!initialized)return;
 let dy=e.deltaY;
 if(e.deltaMode===1)dy*=16; else if(e.deltaMode===2)dy*=cssH;
 if(!Number.isFinite(dy)||dy===0)return;
 dy=Math.max(-500,Math.min(500,dy));
 const factor=Math.exp(-dy*0.0015);
 const oldScale=view.scale;
 let zoom=(initialScale/oldScale)*factor;
 zoom=Math.min(MAX_ZOOM,Math.max(MIN_ZOOM,zoom));
 const newScale=initialScale/zoom;
 if(Math.abs(newScale-oldScale)<1e-18) return; // maybe at limit
 const sx=e.clientX,...;
 const anchor=screenToComplex(sx,sy);
 const ratio=newScale/oldScale;
 view.x=anchor.x+(view.x-anchor.x)*ratio;
 view.y=anchor.y+(view.y-anchor.y)*ratio;
 view.scale=newScale;
 updateViewReadout();
 showFocus(sx,sy);
 requestRender('interactive');
 // expose diagnostic:
 window.__lastZoom = {...}; perhaps.
}
```
Need check anchor math with y orientation: screenToComplex y=cy-(sy-H/2)*scale. Let `p` be anchor. Under new scale, center' should be p + (center-p)*r. For y: mapping im'=cy'-(sy-H/2)*newScale. Set equal p.y=cy-(sy-H/2)*oldScale. cy'=p.y+(sy-H/2)*newScale. And center-p = cy - [cy-offsetOld] = offsetOld where offsetOld=(sy-H/2)*oldScale. p+(center-p)*r = p+offsetOld*r = cy-offsetOld+offsetOld*r = cy + offsetOld*(r-1). Other formula p+offsetNew = cy-offsetOld+offsetOld*r = same. Good. So generic `p+(center-p)*r` works for both.

Need zoom limits: if factor pushes beyond limit, ratio still computed; anchor stays under cursor. Good.
`MAX_ZOOM=1e12`, `MIN_ZOOM=0.35` maybe. If zoom out beyond .35, view larger but still okay. Reset restores. `

factor` with dy up to500 ->2.127; min zoom .35. Good.
Need track `lastZoomCheck` maybe:
```
const after=screenToComplex(sx,sy);
window.__lastZoom = {anchor:{...},after:{...},error:Math.hypot(...),zoom...};
```
This helps our verification if browser inspect can evaluate? Maybe not. Could log to console:
`console.debug('zoom anchor', ...)` on every wheel could flood. Maybe expose only. We can use browser tool `inspect` maybe returns evaluated JS? We'll see. Could add custom DOM data attributes:
```
document.documentElement.dataset.zoomAnchorError = ...
```
Then inspect DOM perhaps includes dataset. Browser tool inspect may show DOM. That's useful. Set `document.body.dataset.zoomAnchorError = error.toExponential(2)` and other view data. But adding attributes is harmless. Could use status? We'll expose via `window.mandelbrotDebug`. Better.
Need maybe `browser` tool can execute arbitrary JS via `inspect`? Tool schema only action/x/y/text etc. `inspect` returns DOM/console perhaps perhaps text can be JS? uncertain. We can rely on screenshots and maybe DOM dataset if inspect shows element attributes. We'll see.
Add `<output id=debug...>` hidden? Could use status coordinates. Not necessary.
Potential automated tester checks canvas pixels and wheel; our math correct.

`showFocus`:
```
focus.style.left=`${sx}px`; top...
focus.classList.remove('show'); void focus.offsetWidth; focus.classList.add('show');
```
Need animation end remove class perhaps:
```
focus.addEventListener('animationend',()=>focus.classList.remove('show'));
```
Fine.

Pan events:
```
let drag=null;
canvas.addEventListener('pointerdown',e=>{
 if(e.button!==0 && e.pointerType==='mouse')return;
 e.preventDefault();
 canvas.setPointerCapture(e.pointerId);
 drag={id:e.pointerId,x:e.clientX,y:e.clientY,cx:view.x,cy:view.y,scale:view.scale};
 canvas.classList.add('dragging');
 suspendRendering();
});
canvas.addEventListener('pointermove',e=>{
 if(!drag||e.pointerId!==drag.id)return;
 const dx=e.clientX-drag.x,dy=e.clientY-drag.y;
 view.x=drag.cx-dx*drag.scale;
 view.y=drag.cy+dy*drag.scale;
 view.scale=drag.scale;

 updateViewReadout();
 requestRender('interactive');
});
function endDrag(e){... if(drag) {drag=null;canvas.classList.remove(...);requestRender('full');}}
```
Need potential conflict: `requestRender('interactive')` on pointermove schedules settle timer; on pointerup `requestRender('full')` clears it. Good.
Need pointercancel call endDrag but perhaps if canceled due touch, still full. fine.
Need call `canvas.releasePointerCapture` maybe wrapped try. no need.
Need avoid wheel while dragging updating `drag.scale` from initial; if wheel occurs, view.scale changes but drag.cx/cy/h scale stale. Could ignore wheel while dragging or update drag baseline. Simpler in onWheel `if(drag)return` (after preventDefault). That prevents zoom while dragging, normal. Fine.
Double-click:
```
canvas.addEventListener('dblclick', e=>{
 e.preventDefault(); zoomAt(e.clientX,e.clientY,2); requestRender('full') maybe interactive.
});
```
Could define `zoomAtPoint(sx,sy,factor)`. Wheel uses it. For double click factor2 and call interactive. Need not include; but nice. We can implement helper.

`resetButton.addEventListener('click',()=>{resetView()})`;
`resetView()`:
```
view={x:INITIAL_CENTER.x,y:0,scale:initialScale};
updateViewReadout();
focus.classList.remove('show');
requestRender('full');
```
Need perhaps clear `window.__lastZoom`. no.
Keyboard:
```
window.addEventListener('keydown',e=>{if(e.key.toLowerCase()==='r'&&!e.metaKey...)resetView();});
```
Could be extra.
Need panel not capturing pointer drag from canvas? fine.

`window.addEventListener('wheel', onWheel,{passive:false});`
Need maybe `document.addEventListener('gesturestart', preventDefault)` for Safari? no.

Initialization:
```
resize();
window.addEventListener('resize',resize);
...
```
Order: add listeners before `resize()` maybe. Need update HUD readouts. call `resize()` at bottom. It calls requestRender('full') after all functions declared. Good.
Need perhaps initial canvas render synchronously before first paint? We could in `resize()` call `startRender('full')` directly rather than rAF, but requestRender schedules next frame. Fine. To make initial screenshot robust, compute first preview synchronously? Maybe browser tool waits

for network idle / load; rAF likely executed. Could call `startRender('full')` directly on initial resize, then step scheduled. But `stepRenderer` also rAF; first pass won't compute until one frame. Could call `stepRenderer(activeRenderer)` synchronously after start; that computes ~9ms and draws first pass maybe. Then schedule rest. This can ensure initial canvas has preview immediately. We can do in `startRender`: after `preparePass`, call `stepRenderer(r, performance.now())` directly instead of rAF. But then each navigation starts with immediate 9ms work, still fine. It could make wheel event handler itself spend 9ms, acceptable. On pointermove at 60Hz, requestRender coalesces start to next rAF, then step sync 9ms inside rAF, okay. For initial load, sync within script, maybe first pass draws before load event. Good. Let's call `stepRenderer(r)` synchronously at end of startRender. But stepRenderer schedules another rAF if active. Need ensure if first pass not complete, old canvas blank until next frame; still maybe. We can force first pass computation to completion synchronously (it is small) with a bigger budget? Could implement `stepRenderer(r, 12)` and loop; first pass likely completes within 12ms. If not, maybe second frame. Fine. Could call a special `drawQuickPreview(r)` synchronously computing first pass regardless of deadline, at divisor8 ~15k pixels*260 avg ~few ms; then draw. But at deep zoom cap320, same ~5M ops worst ~20ms. Still okay. Could avoid complexity; rAF wait 16ms is negligible. Browser tool screenshot likely after >100ms.

Need ensure `requestRender` from `resize` at bottom doesn't run before script finishes? rAF after, fine.

Potential issue with full progressive rendering at high maxIter: `putImageData` with dirty rect from `fullData` and source `fullData` at `dx=0,dy=0`. Signature uses dirty rect in source coordinate space; yes. It writes only dirty region to canvas. Good.
Need alpha:false context with putImageData alpha; all255. fine.
Need `ctx.drawImage(previewCanvas, ...)` with alpha:false context; okay.
Need maybe set `ctx.imageSmoothingEnabled=false` for final pass? putImageData ignores. For preview, true gives smooth gradient; okay.

Need ensure CSS `#fractal` width/height 100%; canvas internal resolution set. Good.

Need perhaps palette mapping at low iteration; let's check initial view color. At c far outside, n maybe1-3, smooth clamp maybe0-1, t ~.73+.02 etc -> palette around reddish/purple. At c just outside set, n large, t cycles. Interior black. Nice.

Need maybe implement a subtle glow around interior boundary based on distance estimation? Not required; smooth escape time gives bands. Fine.

Need maybe use "distinct color for points treated as inside" with status legend. yes.

Need browser check. We'll write file. Need perhaps use `write` tool. Let's compose carefully. We can use heredoc? write tool with content. Need ensure no syntax errors. We'll run `node --check` maybe extract script with Python? Could use bash to parse with Node by extracting script or just browser console. We'll inspect.

Let's write.

Need inspect. First syntax check perhaps extract script via Python and node --check. Also run browser reload/inspect/screenshot. Need understand browser tool output. Let's do syntax and browser reload maybe parallel? Browser reload uses index.html, syntax tool can run in parallel maybe.

We have initial screenshot shows fractal, in progress. Need check console no errors. Need syntax check with node using sed perhaps extract with awk. We can use `node -e` reading file and regex to check via vm.Script. Let's do. Also need browser interactions: zoom into recognizable boundary point near cursor and check stays near cursor, additional detail. Need use browser tool actions. Need understand wheel behavior. Browser tool has scroll action with x,y,delta. Use negative delta to zoom in likely. Need maybe screenshot after. We can use `browser` scroll with x,y,delta perhaps. Need check DOM maybe status. We can also use click maybe double-click? `click` action doesn't specify double. `scroll` likely wheel. Use scroll at boundary point e.g. between main cardioid and period-2 bulb? Recognizable boundary point around x=575,y=400 (cusp at -0.75,0), or seahorse valley top between cardioid and period-3 bulb around x maybe 770? Let's map initial view. Browser viewport 1200x800. initialScale=max(3.6/1200=.003,2.6/800=.00325)=.00325. center x=-0.7, center y=0. Screen x for complex c: (c+0.7)/.00325 +600. For c=-0.75 =>584.6. y for im=0 =>400. So cusp at joining main cardioid/period2 bulb near x=585,y=400, visible in screenshot around x=570? Screenshot canvas perhaps scaled to 1200x800, yes. Need zoom at e.g. x=580,y=400 or a boundary point with detail like seahorse valley between main cardioid and top bulb around c=(-0.12,0.74)? Actually seahorse valley around c=-0.75+0.1i (x585,y369), between main cardioid and period2 bulb top. That's recognizable boundary. Use scroll at (585,370), delta negative maybe -300. Need see factor. Browser scroll delta maybe sends wheel with e.deltaY=delta. our factor=exp(-delta*0.0015) -> delta -300 =>1.57x zoom, modest. Could repeat 8 times to get ~40x. Need check anchor. Need maybe use scroll with delta -500 max =>2.12x each; repeated 6 => ~

90x. But note `dy` clamped -500. Browser `scroll` action maybe delta values sign opposite? Need test. Could use one scroll then inspect zoom DOM. Let's do syntax check first and browser scroll. Need perhaps execute in parallel? Syntax check independent. Need maybe browser action reload? Let's use multi_tool parallel with bash node check and browser scroll; but if scroll uses same browser session after reload, okay. Need be careful browser actions sequential. We'll call one at a time for interactions. First syntax.

Need check initial render completes maybe use browser inspect after a bit (tool calls take time). Let's call browser inspect/screenshot. Also perhaps can use browser `key` to trigger R etc. Need verify interactions. Let's scroll at boundary point. Need maybe use `scroll` action x,y,delta. Let's do one large negative delta and inspect DOM.

Uh oh! Zoom anchor seems wrong: center changed from -0.7 to -1.5798 +0.5865i after zoom at (585,370), expected center ~ -0.7? Let's calculate anchor at (585,370): x=-0.7+(585-600)*.00325=-0.74875; y=0-(370-400)*.00325=+0.0975. For factor 1.82, ratio=.55, new center = anchor + (oldCenter-anchor)*.55 = (-0.74875 + (.04875*.55))=-.72194, y=.0975 +(-.0975*.55)=.0439. But DOM says center -1.5798+0.5865i, drastically moved. Why? Maybe browser scroll event `e.clientX/clientY` are not x,y? It might dispatch wheel at current mouse position from prior (0,0)? Let's calculate center if anchor at (0,0): x=-0.7-600*.00325=-2.65, y=0+400*.00325=1.3. New center=anchor+(oldCenter-anchor)*.55 = -2.65+1.95*.55=-1.5775; y=1.3-1.3*.55=.585. That matches DOM! So browser tool `scroll` event clientX/clientY likely (0,0) or scroll action uses delta to scroll at (0,0), ignoring x/y? Hmm. Need understand. It says frame screenshot ring maybe at top left under HUD? I don't see focus ring maybe x=0,y=0, hidden under HUD. So browser tool's `scroll` action may position pointer? Maybe `scroll` action x,y are from/to? Schema: scroll has x,y,delta, perhaps x,y maybe scroll offsets? Need maybe use `mouse move` first? Browser tool doesn't have mousemove action explicitly; `drag` can move pointer perhaps. Could use `drag` from target to target? Or `click` at x,y before scroll to set pointer. Tool `scroll` likely sends wheel at x,y but perhaps coordinate semantics: maybe x,y are deltaX/deltaY? Need inspect expected. Could use `drag` to position mouse via pointer move? Browser tool action `drag` perhaps from x,y to toX,toY; likely mouse down/move/up. Need maybe set pointer via `click`

then `scroll`; but the tool might route to page.mouse.wheel at current mouse position. We can maybe use `browser` action `click` at x,y then scroll with x/y absent; but still maybe wheel at current position. Need test.

First anchor math appears correct for actual client coordinates; tool event apparently at (0,0) despite x,y. Need verify with a click+scroll. But need check `window.mandelbrotZoomCheck` perhaps inspect DOM doesn't include JS object. Could maybe use console via `browser` action `inspect` with text? Tool's `inspect` may support JS expression in text? Need explore. Could use `browser` key? We can add a diagnostic element hidden with data attributes, and inspect DOM; but inspect output may include attributes if text? Currently dom output text only. Could maybe alter visible `#coords` to show zoom anchor error temporarily; but we can calculate from center. Need just test browser tool event coordinate semantics.

Try `click` at (585,370) then `scroll` with x=585,y=370,delta=-100. However clicking canvas triggers pointerdown/up and `endDrag` -> full render; fine. Then scroll maybe at same location. Need first reset view to baseline. Use click reset button at (160,253). Then perhaps click boundary point, scroll. Let's do reset click then maybe `drag` from point to point? Need inspect after reset.

Reset works initial framing. Need verify zoom tool coordinate issue. Let's click at boundary then scroll with no x,y maybe browser uses last mouse position. Could use click at (585,370), then scroll with x omitted? Schema requires action and optional x,y,delta; maybe x,y default perhaps 0. Let's test click then scroll with x=585,y=370. If still center at -1.5 perhaps tool wheel event uses (0,0). Then try `scroll` with x maybe not used and instead we need position pointer via `drag`. Let's do click boundary (this triggers endDrag full render), then scroll -100 with x,y maybe.

Now scroll with small delta -100 maybe.

Now center -0.7068 +.0136; expected for factor1.162 at anchor(-.74875,.0975), ratio.86: center=-.74875+.04875*.86=-.7068, y=.0975-.0975*.86=.01365. Exactly. So browser wheel uses last pointer position, click positioned pointer; x,y in scroll perhaps perhaps not relevant? The first scroll had no prior pointer click, so position was (0,0). Need perhaps we should ensure app handles wheel at mouse position from browser; it does. Fine.

Need now zoom repeatedly into boundary point and check anchor. Use scroll several times with -400 each (mouse position remains at 585,370 from click). Need maybe each scroll event uses last pointer position; yes. Could call multiple scroll actions sequentially, maybe each triggers interactive preview and settle. We can call `scroll` 5 times in separate tool calls; or one call with delta -1600? Schema delta min -1600, our code clamps dy to -500, so factor max2.12. Need perhaps use calls. Could use `browser` action `scroll` with delta -1600 but clamp to -500. Multi-tool parallel cannot sequence? Could use one `bash` maybe inject synthetic wheel events with browser tool? Browser `type` text into console? no. We can issue multiple tool calls perhaps via multi_tool_use.parallel would run concurrently on same browser, not good. Sequential calls. Need time budget okay.

Need choose recognizable boundary point. Ring at (585,370) seems right at cusp between cardioid and period-2 bulb; zoom reveals details around circle (ring marker). Need maybe zoom 4-5 times to 20-40x. At each scroll -400 factor1.82. Starting1.16, after4 maybe12.7. Need additional detail rendered; iterations increase to ~650. Good. Could perhaps use -500 factor2.12, after4 =>23.4x. Need check full detail finish. Browser screenshot after each maybe included. We can call scroll with delta -500 repeatedly. But `delta` maybe browser scroll action with -500 and tool may send wheel with deltaY=-500. Our clamp. Good.

Need ensure anchor stays near cursor. We can compute center from DOM and map anchor after each zoom to (585,370). Need maybe use `window.mandelbrotZoomCheck` via browser inspect? We can add a visible status maybe not necessary;

we can compute expected. Need maybe add custom `data-*` attributes to body and inspect output perhaps not shown. Could use `browser` action `inspect` with text maybe ability to evaluate JS. Let's try `browser` action inspect with `text` maybe perhaps it's an expression. But not needed if we can compute center and check invariant mathematically; could report. Maybe test with `console.log`? We could add a hidden `<pre id=debug>` whose textContent shows anchor error; browser DOM output would include it if text. This could help verify. But user doesn't need it, and we can modify to log to console on each wheel once? Actually browser inspect returns console array; if we `console.info` anchor error from app, we could inspect. But adding logs on every wheel isn't harmful; but could be considered clutter. We can add a one-time console log at initial load: `console.log('Mandelbrot explorer ready')`; but doesn't verify. We can perhaps use `browser` tool `inspect` with text containing JS expression to evaluate? Let's explore quickly. Use action inspect with text maybe `window.mandelbrotZoomCheck`. Need tool schema says text can be up to2000 for `type` likely, but inspect could accept. Could call and see.

Inspect ignores text. Could use `browser` action `key` with text to open devtools? no. We could temporarily add a debug element that shows `window.mandelbrotZoomCheck.error` in DOM, then check inspect output. But we can also compute from center. Let's maybe add a hidden? Browser DOM text includes visible text; if we add a `<span id="diag" class="sr-only">` it may still show in DOM text, maybe. But this is not needed for user app. Could use a `data-*` attribute and `browser` inspect maybe not. Could use console logs from app and inspect console; `console` output is shown. Add `console.debug` on wheel with anchor error; then browser inspect will show console array. That would let us verify exact invariance. But console logs on wheel are okay and can be removed before final. Could temporarily add a debug listener in script via `console.log` in `zoomAt`, then remove after check. But tool reload required after edit. We can do that if useful. But math is exact by construction, and center after zoom confirms anchor. Need perhaps strict verification: compute center from DOM and use scale to derive point under cursor. We can calculate with JS in bash given numbers; not requiring browser runtime. But full runtime check maybe need `window` state. Could expose debug text in `#status` briefly? Focus ring already shows cursor. We can visually see ring at boundary point and after zoom cursor still at same boundary feature. Screenshot shows ring at (585,370) near cusp. Need zoom further and see boundary remains near ring/cursor. Let's do repeated scroll. Each call may have current mouse at (585,370). Need maybe focus ring persists only .65s; screenshot immediately after scroll shows ring. Good.

Need maybe avoid resetting render each scroll by rapid calls; settle timer 85ms. Browser tool calls likely >85ms apart, so each triggers full render and maybe cancels. Fine. Could call scroll five times quickly in separate tool calls; each process maybe ~? Fine. Maybe use `motion` tool to capture frames? not necessary.

Let's call scroll -500 four times sequentially.

At 2.46× center -0.7289+.0579. Check anchor complex p at (585,370): scale=.00325/2.46=.001321; p.x=center+(585-600)*.001321=-.7289-.0198=-.7487; p.y=center-(370-400)*.001321=.0579+.0396=.0975. Exactly initial anchor. Great. Cursor ring at boundary cusp remains. Need more zoom.

At 5.21× anchor still at ring. Need zoom more, perhaps 20x reveals detail at cusp; note this point (-0.74875+0.0975i) may be inside/outside? At 5x screenshot, ring at boundary between black and colored valley, good. Another -500 to11.05×, another to23.4×. Need check.

At 11x ring remains at boundary; preview is low-res stretched (blurry) but full detail pending. Need wait/ inspect after render completes. Browser tool screenshot after a little or `inspect` after no delay? We can maybe use `browser` action `screenshot` after some time; tool calls have inherent delay. Let's scroll one more then inspect full detail.

At 23x screenshot shows low-res preview (blurry) and full detail pending. Need check after full detail settles. Use `browser` inspect after maybe tool call time.

Great full detail rendered, boundary point at ring/cursor (ring faded but centered around x585,y370) and additional spirals. Need verify math invariant more exactly maybe use center from DOM: 23.3× approximate, scale=.00325/23.3=.0001395; at x585 offset -15 → -0.00209, y370 offset -30 → +0.00418; anchor complex= -0.74666-0.00209=-0.74875; +0.09332+0.00418=0.09750. Exactly initial. Good. We can report.

Need verify pan and reset compare initial framing. Need drag from e.g. (700,450) to (800,500) and inspect center; then reset via button and inspect. Need maybe use browser `drag` action with x,y,toX,toY. Let's do. Need ensure current render completed. We'll drag from e.g. (700,400) to (820,470). `dragging` starts at pointerdown, pointermove updates center by -dx*scale +dy*scale. At zoom23.3 scale .0001395, center shift x=-120*.0001395=-.01674; y=+70*.0001395=.00977. So center around -0.7634+0.1031i. Then reset returns -0.7000+0.0000i, zoom1.00x, iterations260. Need screenshot compare initial. Let's drag.

Pan works: center changed exact expected, zoom unchanged, render underway. Need reset and compare initial framing. Click reset at (160,253) then inspect after rendering.

Reset screenshot at 51% full detail but fractal complete from lower res plus progressive rows maybe fine. Need compare initial framing: initial screenshot maybe had same center and zoom. Need inspect after complete.

Good. Need maybe check initial screenshot from first reload was same framing? It showed full detail 23%/46%; likely same. Need perhaps compare via screenshot pixel? Could use browser screenshot initial now, but earlier initial screenshot not attached (omitted). We can reload and inspect after full detail to compare. But reset view mathematically identical to initial. We can check by reading code: reset sets view initial. Need perhaps browser verify by reload and screenshot; could call reload then inspect to 100%. But tool reload will reset and render. We have already initial reload output "Full-resolution detail 23%" and center -0.7000 +0.0000i, zoom1.00×, iterations260. Reset output same. Good.

Need check console no errors - inspect outputs console [] all along. Need perhaps test wheel scroll prevention. Body overflow hidden and preventDefault; no scrolling. Since full screen no scrollable content, page scroll position stays 0. Could perhaps use browser inspect with DOM includes maybe not scrollY. Could expose maybe use `browser` action screenshot after wheel; no visible page scroll. Fine.

Potential issue: focus ring isn't visible in final full detail screenshot because faded, okay.

Need maybe test responsiveness during rendering: requirement controls responsive during rendering. We saw wheel events while full render in progress update zoom and center, and drag while rendering works. We could deliberately click/drag while initial rendering, but current interactions responded. Good.

Need maybe check "Recompute after navigation rather than scaling a static image": our lower-res passes recompute fractal; full pass initializes from lower-res and progressively replaces. We saw additional detail at 23.3×, iterations increased 260→833, and screenshot full detail reveals spirals. Good.

Need maybe check smooth escape-time gradient and interior distinct: screenshot shows smooth gradient and black interior. Good.

Potential hidden concern: The attached screenshots show the full set is shifted to the right/down? Initial center -0.7, set spans x screen maybe [200,960], y [50,740]. Complete main cardioid and surrounding lobes visible. Fine. Initial bounds include full set; top/bottom antenna visible. Great.

Potential concern: Canvas display is 1200x800 but screenshot seems 1200x800. fine.

Need maybe check huge zoom / iteration adaptation and precision limit; not necessary. But could see if zoom anchor remains through wheel at large zoom and status. We tested up to23.3x. Could maybe do one more at deep zoom to

check controls responsiveness and iteration count. But time budget maybe fine. Need perhaps test up to100x and full detail render speed. Important requirement "sufficient iterations to reveal new detail as user zooms" perhaps at 23x iterations833 and screenshot detail. Good. Could maybe check at 100x, iterations~1000, still render. But no need. Need maybe fix any issues discovered:
- Initial wheel event at (0,0) when pointer not positioned centered at top-left: that's expected browser tool behavior, not app issue. We had to click to set pointer. Real user wheel has cursor position from mouse; okay.
- Could there be a bug with `lostpointercapture` event calling `endDrag(e)` twice after pointerup? We set dragging=null in first endDrag, second returns. fine.
- Could there be a bug with `reportProgress(null,...)` referencing r but not used; fine.
- Could full renderer be canceled if pointerdown on canvas while HUD? no.
- Could wheel over reset button call zoom and click? It does; window listener catches; not an issue.
- Could first render's `startRender` call `stepRenderer` synchronously inside rAF and then `stepRenderer` schedules another rAF; okay.
- Could `requestRender('interactive')` call settle timer, then settle full while active renderer may still be from prior full? It cancels.
- `suspendRendering()` on pointerdown cancels pending start but doesn't cancel a stale `stepRenderer` rAF; active null check stops. fine.
- One issue: `window.addEventListener('wheel', onWheel, {passive:false})` on browser tool scroll event with x=585,y=370 but pointer at (0,0) from previous state had clientX=0,clientY=0. That's tool behavior. Fine.
- Another issue: anchor focus ring position uses `e.clientX/clientY`; if canvas is full window, same as sx/sy. okay.
- `canvas.setPointerCapture` may throw if pointerdown from unsupported? unlikely. fine.
- `screenToComplex` uses cssW/cssH; if browser zoom changes (device scaling) still innerWidth CSS px. okay.
- `resizeCanvas` preserves zoom ratio but on reset uses current initialScale. good.
- `formatZoom` for 1e12 outputs `1.00T`; fine.
- Coordinates use Unicode minus in label but JS toFixed produces `-`, output `center -0.

7000 + 0.0000i`; fine.
- Interpolation smoothstep means palette loops start/end same, but derivative at endpoints zero; good.
- Smooth formula: `Math.log2(logAbsZ)` where logAbsZ is natural log |z|, correct. Need perhaps verify standard normalized iteration count uses `log(log|z|)/log 2` (natural outer log), so yes. Good.
- High bailout radius 256 means points can have large `zr2+zi2` before escape; if `c` huge, first iteration might overflow? Initial view c up to ±2.7, no; at zoom out up to maybe ±7.6, still fine. At pan far away maybe c could be enormous if user drags many times; z could overflow to Infinity, `Math.log(Infinity)=Infinity`, `Math.log2(Infinity)=Infinity`, `smooth=0`, palette okay. But `Infinity` in `zr2+zi2` fine. Could `zr===tortoiseR` with NaN? If overflow leads NaN? no. Could no issue.
- `power` doubling could grow huge but max5000, fine.
- `writeInterior` function called a lot, okay.
- Progress bar stays 100% when done. fine.
- HUD covers top-left but no issue.

Need maybe verify file present. Use `ls -l index.html` perhaps. Need perhaps run browser reload once at end and inspect initial output/console after rendering; we already did initial reload at start. But addendum says "Run application in browser and inspect initial output and console. Use browser tools for brief pass ... Fix clear problems ... Save final file ... report what actually checked and which remain unverified." We did. Need maybe final file saved already; no edits needed. But perhaps need final browser reload after any? We haven't modified file since initial write. Fine. Need maybe final `bash` verify file and maybe syntax. Already syntax check. Could perhaps check no external resources with grep (no http/src). Need do a quick grep to ensure no external requests and file present. Also maybe reload final and inspect console. Let's do both in parallel? Browser reload and bash grep independent. Use multi_tool parallel.

Interesting file bytes changed from 22938 to22957? Wait initial syntax check said 22938; now ls shows22957. Did something modify file? Perhaps browser tool reload wrote something? No, maybe JS syntax check length was JS string? Actually first `node -e` output "HTML bytes: 22938"; now `ls -l` 22957. Could be browser tool auto-saved DOM modifications? Or file was modified by tool? Need check. Why 19 bytes difference? Maybe `grep -Eic` counting? no. Could be browser tool appended something to index.html? Need inspect file tail/head or diff? We don't have original backup. Maybe browser tool toggles some instrumentation script in HTML when reload; perhaps adds a marker script to index.html and hot-reload tool modifies file. Need check for external or injected script. This is important: final file must self-contained. Let's inspect suspicious strings around end. Use `tail` (but instructions say use read instead of cat/sed; can use read with offset). Need find file length lines and read tail. `wc -l`, `grep -n` for suspicious maybe.

No injected external. Why byte diff? Maybe initial `node` regex output length in JS characters differs from UTF-8 bytes due Unicode characters (minus sign, multiplication sign, middle dots, em dash). Yes `s.length` counts UTF-16 code units, while ls bytes counts multi-byte UTF-8. 19 bytes difference from 10+ Unicode chars. Fine. No issue.

Need maybe final inspect after full render and console. Could call inspect after a bit. Then final answer. But maybe we should consider potential requirement "no network requests" - grep zero matches. Good. Need maybe final browser inspect after reload to ensure completion and console. Let's call.

Need final response concise report what checked and unverified. But before final, maybe need consider if we should mention zoom anchor verification with pointer positioned via click due tool quirk. We can say checked wheel zoom at boundary point near (-0.74875+0.0975i) from 1× to23.3×; center/readout math preserved point under cursor, iterations rose260→833, full-resolution detail completed. Pan changed center while preserving zoom, Reset restored center -0.7000+0.0000i, 1.00×,260 iterations and matching initial framing. Console empty. No external resources. Unverified: touch pinch, very deep zoom near 1e12 precision limit, other viewport sizes/DPR. Need be honest: wheel default prevented by code but page scroll not explicitly measured; since body overflow hidden and no scroll, screenshot no scroll. Could mention wheel `preventDefault` implemented, but actual browser page scrolling not directly measured. Need maybe include that as unverified. Also perhaps "additional detail" checked visually at23.3x. Good.

Need maybe mention final file `index.html` exists. No need to include code. Should we mention no fixes were needed? We didn't discover clear problems; first tool scroll at (0,0) was harness pointer position, not app. We can say no clear app defects found; no edits after initial write. Fine.

Need ensure final response not too verbose, desired4. Use bullets maybe.

Let's craft:
"Created `/tmp/job-ZjJmax/index.html` (single self-contained file; inline CSS/JS, no external refs). Browser checks: ... Remaining unverified: ..."

Need perhaps mention `window.mandelbrotZoomCheck` debug API? not needed. Could mention to be precise that anchor invariance was checked from center/zoom readouts and visible focus ring; error expected zero. We didn't actually read error object, but we know from math. We can say "the complex coordinate under the fixed cursor computed from the center/zoom readouts remained ~−0.74875+0.09750i". That is actual check. Good.

Potential issue: initial screenshot at full detail has black interior and gradient; yes.

Let's final.