Mandelbrot explorer · ling-3.1-flash

Need build single file index.html. Need use browser inspect. Requirements full-screen canvas, Mandelbrot complex coords smooth escape-time gradient, distinct inside. Initial complete main cardioid and lobes. drag pan, wheel zoom centered cursor. Recompute after nav, sufficient iterations reveal detail zoom, controls responsive rendering. Reset. prevent wheel page. Need likely implement chunked rendering/Web Workers? No external. Full-screen canvas. Controls responsive during rendering: use requestAnimationFrame tile/chunk rendering, maybe progressive low-res then refine? Wheel zoom immediate low-res then detail. Keep buttons responsive. Could render in slices via rAF or worker. Need ensure no network. Need test browser maybe headless via browser tool. Need create robust app.

Need think architecture.

Canvas full viewport, devicePixelRatio maybe limit 2. Complex bounds initial x [-2.2, 1.0], y [-1.25, 1.25]? Complete cardioid and lobes. Standard [-2.5,1.0], [-1.25,1.25]. Main cardioid and surrounding lobes. Use aspect ratio. Initial bounds x [-2.2, 1.0], y [-1.25, 1.25] maybe width 3.2 height 2.5, aspect 1.28. Full screen typical 1.5, letterboxing? Better fit bounds while preserve aspect. Initial center (-0.6,0), width 3.4, height 2.2? Main cardioid x from -0.75 to .25, period-2 bulb x -1.25 to -0.75, y around .5. To show surrounding lobes, x [-2.2,1], y [-1.25,1.25]. On wide screen, preserve aspect 3.2/2.5=1.28, canvas 1200/800=1.5, fit height then width 1000 centered. But "Initially show complete main cardioid and surrounding lobes", fine. Could use bounds x [-2.4,1.2], y [-1.35,1.35], aspect 3.6/2.7=1.333. At 1200x800 aspect 1.5, width 1066.7. Good. Or adapt initial to canvas with x [-2.2,1.0], y [-1.25,1.25], preserving.

Rendering: Canvas ImageData, each pixel compute. To keep responsive, progressive tile rendering. Could render in horizontal bands each frame, maybe 4 bands? Full HD ~2m pixels; each up to 256 iterations potentially expensive. At initial many inside/escape quick. We can render in chunks using requestAnimationFrame, with maybe target 12 ms per frame, and show overlay progress. But user interactions during render: if pan/zoom while rendering, cancel current job and start new. For responsiveness, render immediate low-resolution preview (e.g., every 4th pixel) then full-resolution progressive? That gives immediate feedback and recompute. But requirement "Recompute fractal after navigation rather than scaling a static image." Low-res computed then refined is okay. Need ensure no static scaling. Could render at current resolution in tiles. On wheel zoom, cancel and start new job immediately; perhaps render one full pass in chunks. To make cursor point stay near cursor: update bounds and render. Zoom factor 1.2 or 1.25. Keep complex point under cursor stable mathematically. Need account canvas displayed coordinate and pixel mapping. We can compute center new:
view.xMin etc. zoom(factor, px, py): complex z = pixelToComplex(px,py); new width = width/factor; new xMin = z.re - (px / canvas.width)*newWidth; similarly y. For DPR, use CSS pixel coordinates and mapping in CSS pixels; canvas backing dimensions dpr. Render at backing. Use CSS pixel coordinate for events and map to backing. Could define view in CSS pixel coordinate dimensions and render pixel loops with backing scale. Easier: canvas.width = clientWidth*dpr, height; view bounds correspond to full canvas. pixelToComplex(bx,by). Event offsetX CSS -> bx=offsetX*dpr. Or use CSS coords and scale in rendering. Better use backing.

Initial bounds with aspect preservation. Need perhaps no letterbox; map view to full canvas directly, causing initial aspect distortion depending screen. Distortion okay? Mandelbrot should not distort. Better preserve aspect by expanding bounds to canvas aspect. Given base bounds, fit into canvas aspect. If canvas wider, expand height; if taller, expand width. This means complete. Implement fitView(baseXmin etc, aspect). On reset, recompute fit.

Iterations: base 256 maybe increase with zoom. "sufficient iterations to reveal new detail as user zooms". Use iterations = clamp(Math.round(256 * Math.log2(zoomFactor?)) maybe based on scale relative initial). Track minScale = initial width / current width. iterations = Math.min(4096, Math.max(256, Math.floor(300 * Math.log2(scale + 1))))? At initial scale 1 -> 300. zoom 10x -> ~997; 100x -> 2000; 1000x -> 3000. Good. But deep zoom floating precision fails around 1e-13; no need. Smooth coloring:
zn = zx*zx+zy*zy; if escape, log_zn = Math.log(zn)/2; nu = Math.log(log_zn / Math.log(2)) / Math.log(2); smooth = iter + 1 - nu (standard). Use smooth value for gradient. Distinct inside color near black (#000 or #05060a). Could color inside pure black with subtle? distinct.

Procedural colors: palette generated procedurally, e.g. cyclic cosine palette or HSL. Smooth gradient with interpolation. Use custom palette array maybe 1024 colors generated with cosine palette:
color t = smooth / iterations; hue = (t*360 + maybe phase) % 360; HSL to RGB. But per-pixel HSL conversion costly. Precompute palette of 2048 RGB entries procedurally using cosine palette:
r = 128+127*cos(2π*(a3*t + b3?)). Standard:
red = 9*(1-t)*t^3*255 etc could create. Better use cosine palette:
palette[i] with t=i/(N-1):
r = 0.5 + 0.5*cos(2π*(0.5*t + 0.0))
g = ... offsets 0.33, b 0.67. But this yields maybe pastel. Use offsets and multiple frequencies. Could use HSL formula per palette index once. For smooth escape, palette index = smooth % paletteLength; interpolate between adjacent colors for gradient. Precompute 2048 palette. Distinct inside #000000 or #03040a. Need maybe inside points color #000010.

Performance: per pixel loops. Use local vars, escape check. Use bailout squared=256 (bailout 16) for smooth coloring. For each pixel:
x0 = xMin + (bx+0.5)*pixelWidth; y0...
x=0,y=0, iteration=0; while iteration<maxIter && x*x+y*y<=bailoutSquared { xtemp=x*x-y*y+x0; y=2*x*y+y0; x=xtemp; iteration++}
if inside (x*x+y*y <= bailoutSquared) color inside. else smooth:
log_zn = Math.log(x*x+y*y)/2; nu = Math.log(log_zn / Math.log2) / Math.log2; smooth = iteration + 1 - nu. Some formulas use iteration - Math.log2(log_zn) maybe. Standard: smooth = iteration + 1 - Math.log(Math.log(zn)/Math.log(2))/Math.log(2). With bailout 16? Actually if bailout squared = 256, log_zn = log(sqrt(zn)) = 0.5 log zn; nu = log(log_zn/log2)/log2. smooth = iter + 1 - nu. Fine.
Palette index = (smooth * scaleFactor?) maybe smooth % 512. If maxIter changes, color mapping changes. Use t = smooth / maxIter? Then gradient changes with zoom. Better use smooth / 64 or 128 cyclic to reveal detail, but inside distinct. We can use palette cyclic: idx = smooth * (palette.length / 64) maybe. For smooth gradient. Could use `paletteIndex = smooth % palette.length` and interpolate. At smooth around 0-300, cycles ~0.15 of palette if length 2048. Better use `smooth / 8` cycles. `t = (smooth * 0.125) % 1`; palette interpolation. Precompute palette 4096, index = smooth * (palette.length / 256) perhaps. Need gradient visually appealing.

Could use domain coloring? Not necessary.

Responsive rendering: Implement `Renderer` with job. Each job has view, maxIter, maybe render at full res. Use requestAnimationFrame; each frame render a set of rows, target time ~10ms. But initial full screen maybe 2 million pixels; at 256 iter, JS maybe 100ms-1s. Chunk rows maybe 10ms per frame, 30 frames. During render, controls responsive. Overlay progress. However if user drags continuously, each pointermove triggers new job, cancel old. If render only a few rows per frame, screen partially stale; but new job starts. Could render a coarse preview instantly (e.g., render at 1/4 resolution into offscreen and drawImage scaled) then progressive full resolution. But requirement not scaling static image; coarse preview is computed at current view then refined, acceptable. This improves responsiveness. Need implement carefully.

Option:
- On new view, create offscreen `previewCanvas` maybe same backing? Render low-res (scale factor 4 or 6) ImageData to offscreen canvas of ceil(w/4), then drawImage to main canvas (upscale). This is computed for current view, not scaling old static image. Then progressive full-res rows over it.
- But drawImage smoothing may blur; okay as preview.
- For wheel zoom, maybe render low-res preview synchronously (e.g., 1/6 resolution) which at 2m/36 ~55k pixels, fast. Then full-res chunks. Controls remain responsive.
- On drag, each move could be many events; throttle with rAF and only start job if view changed. Low-res preview each move maybe 55k * 256 = 14m ops, okay but could be 50ms. Use coarse factor adaptive based on viewport area, maybe 8 for >1.5m pixels. At 1200x800=960k, /64=15k. Fine. For 4K 8m /? 10 =80k. Good.
- Full-res progressive rows. To make rendering faster, use multiple row chunks per frame based on elapsed time. Use `requestAnimationFrame`.
- Need avoid blocking UI. Each frame max ~12ms. `performance.now`.
- Could use Web Worker for actual computation, but worker code inline via Blob; no external. But complexity with transferable ImageData and responsive. Main-thread chunked is responsive enough. Full-res progressive.
- Could use multiple workers? Not needed.
- Need handle DPR. Preview offscreen at maybe full backing / coarse. Draw scaled. Then full rows.
- During progressive full-res, draw rows directly to canvas. If job canceled, stop.
- For preview, create ImageData at low width/height, compute each low pixel corresponding to center of low cell; fill; put to offscreen; ctx.imageSmoothingEnabled = true maybe; drawImage. But when full-res rows drawn, they replace preview. Fine.
- If user interacts during preview/full, cancel.
- Need maybe render initial on load and resize. On resize, preserve center and scale? Could recompute view to fit? If resize, maintain current complex center and width perhaps, but ensure no blank. Implement on resize: keep center and width in complex units, adjust height to canvas aspect? Current view bounds may not match aspect after resize. Better preserve center and width, set height=width/canvasAspect; but this changes vertical scale. Or preserve center and min dimension? Simpler: keep center and current width, height=width/aspect. Then render. But if window resized after reset, framing changes. Fine. Need initial fit.
- Reset view: set base bounds fitted to current canvas aspect; render.
- UI: top-left panel with title, iteration count, zoom level, coordinates, progress. Buttons Reset view and maybe center. Requirement Reset view. Add keyboard? Not necessary. "controls responsive" buttons. Use pointer events. Need prevent wheel default: `canvas.addEventListener('wheel', handler, {passive:false}); event.preventDefault()`. Also page maybe no scroll due full screen fixed. Add `touch-action:none`.
- Drag pan: pointerdown capture, track last; pointermove update xMin -= dx*pixelWidth, etc. Need use backing coords. If pointer down and move, update view continuously. Could throttle. Use pointer capture. Cursor grab/grabbing.
- Zoom cursor: use `offsetX/Y` CSS; convert to backing. For wheel, `event.clientX - rect.left`, etc.
- Need ensure point under cursor stays near cursor while zoom. Formula. Test via browser maybe screenshot and coordinates. Could use JS evaluation? Browser tool only actions no eval. We can inspect DOM maybe. Could add debug coordinates. We can manually test by screenshots? Need maybe use browser tool. We can create file then browser screenshot, click/drag/wheel. Need verify. Browser tool likely can screenshot and inspect. We'll do.

Potential issue browser environment maybe file URL? cwd /tmp/job... index.html. Use browser action.

Need write file. Let's design code in detail.

HTML:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<title>Mandelbrot Explorer</title>
<style>
html,body {margin:0; width:100%; height:100%; overflow:hidden; background:#020307; font-family: system-ui,...;}
#app {position:fixed; inset:0;}
canvas {display:block; width:100%; height:100%; cursor:grab; touch-action:none;}
canvas.dragging {cursor:grabbing;}
.hud {position:absolute; left:16px; top:16px; color:#eaf2ff; background:rgba(5,8,16,.58); border:1px solid rgba(...); border-radius:14px; padding:12px 14px; backdrop-filter: blur(10px); max-width: 320px; user-select:none;}
...
button styles.
#status maybe bottom.
#progress {height:3px; background...}
#progressBar {width:0%}
.legend maybe inside color sample and labels.
</style>
</head>
<body>
<div id="app">
<canvas id="fractal" aria-label="Interactive Mandelbrot set"></canvas>
<div class="hud">
<div class="title">Mandelbrot Explorer</div>
<div class="stats">... spans zoom, center, iterations</div>
<div class="actions"><button id="reset">Reset view</button><button id="home">?</button></div>
<div class="hint">Drag to pan • Scroll to zoom • Reset restores full cardioid and lobes</div>
<div id="progress"><span></span></div>
</div>
<div id="toast"?> maybe "Rendering..."
</div>
<script>...
</script>
</body>
</html>

Need no external fonts.

JS:
(() => {
'use strict';
const canvas = document.getElementById('fractal');
const ctx = canvas.getContext('2d', {alpha:false});
const resetButton...
const BASE = Object.freeze({xMin:-2.25, xMax:1.05, yMin:-1.25, yMax:1.25}); maybe aspect 3.3/2.5=1.32. Let's choose x [-2.3,1.1], y [-1.35,1.35], width 3.4 height 2.7 aspect 1.259. At 1200x800 aspect 1.5, fit width? base aspect < canvas aspect, fit width and expand height: displayed width 1200, height 1200/1.259=953 >800? Wait fit base into canvas: scale = min(canvasW/baseW, canvasH/baseH). If base aspect 1.259, canvas aspect 1.5: scale=min(1200/3.4=353, 800/2.7=296) => height-limited, resulting width=3.4*296=1006, centered. Good. Complete. Fine.
Maybe x [-2.2,1.0], y [-1.25,1.25], aspect 1.28, width displayed 1024. Good.
Use BASE_XMIN=-2.2, BASE_XMAX=1.0, BASE_YMIN=-1.25, BASE_YMAX=1.25.
`view = {xMin, xMax, yMin, yMax}`.
`fitBase()` computes:
const baseW=..., baseH=...;
const cw=canvas.clientWidth||innerWidth, ch=...;
const scale=Math.min(cw/baseW, ch/baseH);
const w=baseW*scale, h=baseH*scale;
const cx=(baseXMin+baseXMax)/2, cy=...;
view.xMin=cx-w/2 etc.
This may produce vertical bounds less than base if canvas wide? scale min height, so h=baseH, w<baseW? Wait if canvas aspect > base aspect, height-limited: h=baseH, w=baseW*(ch/baseH) = baseW*canvasAspect/baseAspect > baseW. Actually example ch/baseH=296, w=1006 > base width? base width in CSS units if scale 296: 3.4*296=1006, yes less than canvas width 1200, but complex width 1006/296=3.4? Wait complex width = w/scale = 3.4. Sorry w in CSS px. Complex width remains 3.4, height 2.5. Canvas displays base bounds exactly with horizontal bars. Good.
If canvas taller, complex width expands? scale=canvasW/baseW, complex height=ch/scale > baseH. Good.

State:
let dpr = Math.min(2, window.devicePixelRatio || 1);
let renderWidth, renderHeight;
let job = null;
let rafId=0;
let jobId=0;
let palette = createPalette(4096);
let insideColor = [2,3,8]? maybe [0,0,0]. Distinct. Use [0,0,0] pure black; background also dark but inside black distinct from gradient. Maybe [0, 0, 0].
`zoomLevel` = initialWidth / currentWidth.

`resize()`:
const oldCenter = view center if initialized; const oldWidth = view.xMax-view.xMin;
dpr...
canvas.width=Math.max(1, Math.round(clientWidth*dpr)); ...
renderWidth=canvas.width...
if (!initialized) fitBase(); else { const cx,cy; const w=oldWidth; const h=w/(renderWidth/renderHeight); view.xMin=cx-w/2; ...} // This preserves horizontal scale; if aspect changes, vertical complex span changes. Could instead preserve min dimension; but fine.
scheduleRender(true);
Need avoid schedule before load.

`pixelToComplex(bx,by)`:
return {re: view.xMin + (bx+0.5)/renderWidth*(view.xMax-view.xMin), im: view.yMin + (by+0.5)/renderHeight*(view.yMax-view.yMin)};
Note y orientation: canvas y down, complex y up. view.yMin at top, yMax bottom would invert. Usually set yMin at bottom, yMax at top and formula y = yMax - (by+0.5)/h*(yMax-yMin). Need choose. Let view.yMin bottom, yMax top. Initial yMin=-1.25, yMax=1.25. Formula `im = view.yMax - (by+0.5)/renderHeight*(view.yMax-view.yMin)`. For zoom formula accordingly. Or define yMin top and set initial yMin=-1.25, yMax=1.25 means top=-1.25 (inverted). Better use yTop/yBottom. Use `view.top=1.25`, `view.bottom=-1.25`. But stats. Let's use xMin,xMax,yMin,yMax with yMin bottom and formula y = yMax - ... . Zoom: new yMax = z.im + (1 - (by+0.5)/h)*newHeight? Derive: fraction from top f=by/h; y = yMax - f*height. Given z, newHeight=height/factor, newYMax = z.im + f*newHeight; newYMin=newYMax-newHeight. Yes.
`complexToPixel` maybe for stats not needed.

`zoomAt(cssX,cssY,factor)`:
const bx=(cssX)*dpr, by=cssY*dpr; const z=pixelToComplex(bx,by);
const oldW=..., oldH=...; const newW=oldW/factor, newH=oldH/factor;
const fx=(bx+0.5)/renderWidth; const fy=(by+0.5)/renderHeight;
view.xMin = z.re - fx*newW; view.xMax=view.xMin+newW;
view.yMax = z.im + fy*newH; view.yMin=view.yMax-newH;
scheduleRender();
This keeps z at same fractional pixel. Good.
Need clamp zoom maybe factor and min width 1e-12? Floating precision. `const MIN_WIDTH=1e-12;` if newW < MIN_WIDTH return. Max maybe 1e15. Add `MAX_ZOOM = 1e12`? Mandelbrot double precision around 1e-13; but okay. To avoid infinite, min width 1e-10. Use `if (newW < 1e-10 || newW > 100) return;` Actually initial width 3.2, max width maybe 100. Good.
Wheel delta: `const factor = Math.exp(-event.deltaY * 0.0015);` For typical deltaY 100 => 1.16; trackpad. Clamp factor [0.5, 3] per event. Use `Math.min(3, Math.max(0.5, ...))`. Could use deltaMode line multiply. `if (event.deltaMode === WheelEvent.DOM_DELTA_LINE) deltaY *= 33;`.
Need prevent default.

Drag:
let dragging=false, lastX,lastY, pendingPan=false, panRAF;
canvas.addEventListener('pointerdown', e => { if(e.button!==0 && e.pointerType==='mouse') return; dragging=true; canvas.setPointerCapture(e.pointerId); lastX=e.clientX; ... canvas.classList.add('dragging'); scheduleRender maybe immediate?});
pointermove: if !dragging return; const dx=e.clientX-lastX; dy=...; if dx/dy, convert to CSS px to complex: `const w=view.xMax-view.xMin; const h=...; view.xMin -= dx * w / canvas.clientWidth; view.yMax += dy * h / canvas.clientHeight;` Because moving pointer right should image move right (view xMin decreases). y: pointer down (dy positive) image moves down, complex y increases? Canvas y down; to pan content with cursor, view.yMax += dy*h/ch? If drag down, content moves down, top (yMax) increases, yes. Then last=...; schedulePanRender throttled.
Need ensure if client coords and canvas rect, dx same. Use CSS pixel dimensions.
Throttle: `panPending=true; if (!panRAF) panRAF=requestAnimationFrame(() => {panRAF=0; if(panPending){panPending=false; scheduleRender();}});` But if pointermove fires many, view updated all before rAF, good. scheduleRender cancels current and starts new. Could maybe low-res preview each frame.
pointerup/cancel: dragging=false; release; class remove; scheduleRender full? Already rendering after last move. Maybe ensure final full job.
Need `click` not needed.

Renderer:
`function scheduleRender() { startRender(); }`
`startRender()`:
if (job) {job.cancelled=true; job=null;}
if (rafId) cancelAnimationFrame(rafId), rafId=0;
const id=++jobId;
const maxIter = computeIterations();
const jobView = {...view};
const lowScale = choosePreviewScale(renderWidth,renderHeight);
job = {id, view:jobView, maxIter, nextRow:0, previewScale:lowScale, previewDone:false, start:performance.now(), rowsThisFrame:0};
updateHud();
showProgress...
// render preview maybe synchronously but could take. For initial, preview small.
renderPreview(job);
// then raf loop
rafId=requestAnimationFrame(renderFrame);
Potential issue if renderPreview itself synchronous and view large, still okay. Need keep controls responsive; preview small. Could also chunk preview? Not necessary.
`choosePreviewScale`: area = w*h; if area > 4e6 return 8; >1.5e6 return 6; >600000 return 5; else 4. Maybe for 1200x800 area 960k =>5, low pixels 38k. Good. At 4K 8m =>8, 500k? 8m/64=125k. Fine. Preview compute 125k*300=37m maybe ~100ms, okay but maybe. Use 10 for >4m =>80k. Good.
`renderPreview(job)`:
const scale=job.previewScale; const lw=Math.max(1, Math.ceil(renderWidth/scale)); lh=...; reuse previewCanvas? Create once with max? Use `previewCanvas = document.createElement('canvas')`; previewCtx. Set width/height each job (resizing canvas clears). ImageData(lw,lh). Loop ly/lx; compute complex using same view but low pixel center? If low pixel corresponds to block, use `(lx+0.5)*scale` in full pixels. Compute. Set data. putImageData. Then ctx.imageSmoothingEnabled = true; ctx.drawImage(previewCanvas,0,0,renderWidth,renderHeight); This is a computed preview. Good.
Could disable smoothing for crisp? Smooth better.
`renderFrame(now)`:
if !job or job.cancelled return;
const start=performance.now();
if (!job.previewDone?) preview done already.
// Determine rows per frame adaptively: render at least 1 row, until elapsed < 10ms or maybe 12.
let rows=0;
while (job.nextRow < renderHeight) {
 renderRow(job.nextRow, job);
 job.nextRow++;
 rows++;
 if (performance.now()-start > 10) break;
 // But first row may take >10ms at high iter; break after.
}
if (job.nextRow >= renderHeight) { finishJob(job); return; }
updateProgress(job.nextRow/renderHeight);
rafId=requestAnimationFrame(renderFrame);
Problem: while condition checks before row; after one row if elapsed >10 break. Good.
But if rows are very fast, could render all in one frame and block maybe if 2m pixels * 300 = >100ms; while stops after elapsed >10, but check only after each row; row ~4000 pixels maybe 1ms, so good.
`renderRow(y, job)`:
const imageData = ctx.createImageData(renderWidth,1); This allocates each row, okay but GC. Better reuse `rowImageData` created when width changes. `rowImageData = ctx.createImageData(renderWidth,1)` on resize. Use `const data=rowImageData.data`.
Compute view local, maxIter, palette, pixelWidth etc.
For each x:
...
Set rgba.
ctx.putImageData(rowImageData,0,y);
Need optimize palette interpolation:
`const paletteSize = palette.length; const cycle = paletteSize / 64; let t = (smooth * cycle) % paletteSize; const i0=Math.floor(t); const i1=(i0+1)%paletteSize; const frac=t-i0; const c0=palette[i0], c1=palette[i1]; data[idx]=c0[0]+(c1[0]-c0[0])*frac;`
Palette entries as Uint8Array? Use array of [r,g,b]. For speed, use three Uint8ClampedArray or a Uint8Array of length size*4? Precompute `palette` as Uint8ClampedArray(4096*3) maybe. Access. Could use `palette = new Uint8ClampedArray(PALETTE_SIZE*3)`. Interpolation with numbers.
Maybe create palette length 2048. `const PALETTE_SIZE=2048`.
Cosine palette:
for i:
t=i/(PALETTE_SIZE-1);
// Use a richer procedural gradient: h = (t*360 + 210) % 360; hslToRgb. But per palette once. HSL gives rainbow. Use `hslToRgb((t*0.85 + 0.58)%1, 0.75, 0.55)`. This yields smooth cyclic. But hue wraps at palette end causing discontinuity if not same endpoints. For cyclic interpolation, palette end should equal start. Use h = t*360? endpoints differ (0 and 360 same hue), okay hsl(0) and hsl(360) same. Use t from 0 to1 inclusive, hue=t*360, endpoints same. But gradient cycles through full hue once. Then smooth cycling with `cycle=paletteSize/64` means 64 repeats over escape values. Good.
Could use multiple bands: hue = (t*360 + 240)%360; saturation 0.72; lightness = 0.48 + 0.12*Math.sin(t*Math.PI*2?) maybe. But if lightness endpoints same. Use HSL.
Maybe more aesthetically: `h = (0.62 + 0.78*t) % 1` (280 degrees range, not full cycle) endpoints not same causing discontinuity when cycling. Use full hue. `h=t`, s=0.75, l=0.55`. Full rainbow. Distinct inside black.
Could use `h = (t*2) % 1` with endpoints same (0 and 0), two cycles. Fine.
Let's use cosine palette for smooth and endpoints same:
`const r = 0.5 + 0.5 * Math.cos(2*Math.PI*(t + 0.00));` etc with phase offsets; endpoints same because t integer. But colors maybe not dark enough. Standard palette:
r = 0.5 + 0.5*cos(6.28318*(0.3 + 1.0*t));
g = ... (0.5 + ...); b=...
This cycles once. Use saturation? Could combine:
`const h = t; const s=0.72; const l=0.52 + 0.10*Math.sin(2π*t);` endpoints same. HSL to RGB. Good.
Implement `hslToRgb(h,s,l)` with h in [0,1). Return [r,g,b] 0-255.
At t=0 and 1 same. Palette interpolation across end handled modulo.
Color mapping: `const cycleLength = 64; const p = (smooth * (PALETTE_SIZE / cycleLength)) % PALETTE_SIZE;` If smooth=0 => palette at black? HSL hue 0 red, so boundary near set red. Good. As escape increases, cycles.
Maybe use `smooth / 10` cycles: `const p = (smooth * (PALETTE_SIZE / 12)) % PALETTE_SIZE;` 12 escape units per palette. This makes gradient. Use 24? At maxIter 300, ~12 cycles. Good. Let `paletteCyclesPerUnit = 1/12`? `p = smooth * (PALETTE_SIZE / 16)`. 16 iterations per full hue cycle. Good.
Need avoid huge smooth values at high maxIter; modulo handles.

`computeIterations()`:
const width = view.xMax-view.xMin;
const zoom = initialWidth / width;
const iterations = Math.min(4096, Math.max(256, Math.floor(256 * Math.log2(zoom + 1) * 1.7))); Let's calculate: zoom1 log2(2)=1 =>435; too high. Maybe `Math.floor(256 + 220 * Math.log2(zoom))`; zoom1 256; zoom10 992; zoom100 1728; zoom1000 2464; zoom10000 3200. Good. `Math.max(256, Math.floor(256 + 220*Math.log2(zoom)))`, cap 4096. At zoom 10000 ~3193. Good. For deep detail. Use `Math.min(4096, ...)`.
But if zoom <1 (reset fit maybe initial width exactly), log2 negative, max.
Need track `initialWidth` after first fit. `baseComplexWidth = BASE_XMAX-BASE_XMIN` constant; zoom = baseComplexWidth / currentWidth. Good.
Could increase more aggressively at deep zoom: `Math.floor(300 * Math.pow(zoom, 0.35))` at 10=562, 100=1197,1000=1995,1e6=4000. Maybe. Use `Math.min(4096, Math.max(256, Math.floor(300 * Math.pow(zoom, 0.32))))`: zoom1 300, 10=468? 10^0.32=2.09 =>627; 100=4.27=>1281; 1000=8.55=>2565; 1e6=48=>4096. Good. This reveals. Use that. At initial 300. Requirement sufficient. Cap 4096.
Maybe at zoom 1e10, 4096 insufficient but floating precision anyway.
Need show zoom as `×${formatZoom(zoom)}`.

HUD update:
`zoomValue.textContent = '×' + formatNumber(zoom);`
`centerValue.textContent = `${fmt(cx)}, ${fmt(cy)}``;
`iterValue.textContent = maxIter;`
`statusText` maybe "Rendering..." / "Ready".
Progress bar width. During job, `progressBar.style.width = ...%`. At finish 100 then fade.
Need update HUD on navigation immediately, using current view and computed maxIter. `updateHud()` called in startRender.
Potential issue startRender computes preview synchronously and then HUD. Fine.
`formatNumber`: if abs >= .001 maybe toFixed(6) else exponential. Use `Number.prototype.toPrecision(4)`.

Accessibility: buttons focus. Canvas role img. HUD.

Need maybe handle context menu? Not required.

Need ensure wheel over HUD doesn't scroll page? Requirement prevent wheel navigation from scrolling surrounding page. Add wheel listener to window with passive false and if target within app? Since full-screen no scroll. But specifically mouse-wheel zoom centered on cursor over canvas. If wheel over HUD, maybe still prevent and zoom? Could add canvas only; page has overflow hidden. To be safe, `window.addEventListener('wheel', handler, {passive:false})` and use coordinates relative to canvas; preventDefault always. But then wheel over HUD zooms too, maybe okay. Better canvas listener with passive false; surrounding page none. Requirement satisfied. Could also document listener prevent default when target is canvas. Use canvas.

Need test. Let's write file.

Now need browser inspect initial.

Interesting zoom ×0.003125 due fitBaseBounds bug: BASE_WIDTH 3.2, view width? Should 3.2, zoom 1. Why 0.003125 = 3.2/1024? Means view width 1024? Let's inspect. In resizeCanvas, fitBaseBounds uses canvas.clientWidth maybe at initial 0? It sets view with width = baseWidth * scale. But then after fitBaseBounds, code sets canvas.width etc before? Let's review order: dpr, cssWidth, canvas.width, renderWidth, rowImage, if (!view) fitBaseBounds(). fitBaseBounds uses canvas.clientWidth, okay. But perhaps canvas.clientWidth at initial is 0? It uses window.innerWidth fallback 1280, clientHeight fallback 800. scale min(1280/3.2=400, 800/2.5=320), width=1024 CSS px, height=800. Then view complex width = baseWidth? Wait width variable is CSS pixel width (1024), not complex width! Ah bug: fitBaseBounds computes scale and sets view.xMin=centerX - width/2 where width is CSS px, treating complex width as 1024. Should complex width = baseWidth / scale? Let's think. We want displayed bounds baseWidth complex units across scaled CSS width. scale = CSS pixels per complex unit. If scale=320 px/unit, displayed width in CSS px = baseWidth*scale = 1024 px. Complex width remains baseWidth = 3.2. So view x range should center ± baseWidth/2, not width/2. Similarly height baseHeight/2. But if canvas aspect causes letterboxing, we want preserve base bounds exactly and maybe not fill full canvas. However our canvas maps view to full canvas, so if we keep base complex bounds, it will stretch to full canvas and distort. To preserve aspect and fill canvas, need expand one dimension. Correct fit: determine scale = min(cssWidth/baseWidth, cssHeight/baseHeight) (CSS px per complex unit). The base bounds occupy less than full canvas in one dimension. But since canvas maps full view to full canvas, to avoid distortion we need choose complex width = cssWidth/scale and complex height=cssHeight/scale. If width-limited (scale=cssWidth/baseWidth), complex width=baseWidth, complex height=cssHeight/scale > baseHeight. If height-limited (scale=cssHeight/baseHeight), complex height=baseHeight, complex width=cssWidth/scale > baseWidth. So formula:
scale = min(cssWidth/baseWidth, cssHeight/baseHeight);
width = cssWidth / scale;
height = cssHeight / scale;
Then center base. This yields complex width >= baseWidth and height >= baseHeight, aspect canvas. In example scale=320 (height-limited), width=1200/320=3.75, height=2.5. That expands horizontally, showing extra around lobes. Good. Or if we want exact base bounds with letterbox, could render only subrectangle, but full canvas mapping easier. Use width=cssWidth/scale, height=cssHeight/scale. Then zoom initial = BASE_WIDTH / viewWidth = 3.2/3.75=0.853, less than 1. Our computeIterations uses max(1, BASE_WIDTH/width), okay but HUD zoom shows ×0.853, undesirable. Better define initial view width after fit and initialZoom = 1 by storing `initialWidth` as view width at reset. But requirement reset initial bounds; zoom relative initial should be 1. We can set `referenceWidth` to view width after fit. Use `referenceWidth` variable. Or choose base bounds to match canvas aspect? Simpler: store `initialWidth` when fit. `let initialWidth = BASE_WIDTH;` fitBaseBounds sets initialWidth = width (complex). computeIterations zoom = initialWidth/currentWidth. updateHud same. Reset sets. On resize preserve center and width, initialWidth? If window resize, reference should maybe remain initial complex width? If we preserve width, zoom remains relative to previous initial; but if resize changes aspect and view width same, fine. If reset, initialWidth=view width. Good.
Need fix fitBaseBounds. Also screenshot says rendering 164/800 rows, model doesn't support images but DOM. Need inspect after complete maybe wait. Use browser inspect? Need maybe action inspect gives DOM and console. But first fix. Also potential issue `pixelToComplex` uses global view, not job view. In zoomAt, we update global view before calling, fine. In preview, uses job view. Good.
Potential issue `renderPreview` computes `pixelWidth` based on renderWidth and job view, then fullY = (y+0.5)*scale; cIm = v.yMax - (fullY+0.5)*pixelHeight. This maps low pixel centers to full pixel centers at x*scale, good. But for lowWidth=ceil(renderWidth/scale), last fullX may be >= renderWidth? E.g renderWidth=1200, scale=6, lowWidth=200, x=199 => fullX=1194.5, +0.5=1195 <1200 good. If ceil due remainder, e.g renderWidth=1201, scale=6, lowWidth=201, x=200 fullX=1200.5 +0.5=1201, out of range by 1 pixel. cRe slightly beyond view by pixelWidth, minor. Could use `Math.min(fullX, renderWidth-1)` or compute low pixel center as `(x+0.5)*renderWidth/lowWidth` better. Use `const fullX = (x + 0.5) * renderWidth / lowWidth;` and `fullY = ...` to sample centers. Then no out of range. Do that.
Potential issue preview drawImage from previewCanvas to full renderWidth/Height; okay.
Potential issue row rendering while job view snapshot; global view may change, but job uses snapshot. Good.
Potential issue when startRender called during pan rAF, it cancels job and starts. Good.
Potential issue `endDrag` calls startRender even if no render? fine.
Potential issue `finishJob` setTimeout checks `job && job.id === jobId`, but job remains; okay.
Potential issue `resizeCanvas` calls startRender before initial event listeners? Listeners added before resizeCanvas, yes.
Potential issue `window.resize` during job, startRender cancels.
Potential issue `canvas.clientWidth` in fitBaseBounds when called from reset after layout okay.
Need edit.

Need reload and wait for render. Browser action reload then maybe inspect after delay? Tool no wait. We can run bash sleep? Browser state maybe reload returns immediately. Could use browser action inspect maybe after some time. Let's reload then inspect.

Need wait. Could use bash sleep 2 but browser separate? likely.

Initial ready. Need verify zoom at recognizable boundary point stays near cursor and additional detail. We can use browser wheel action at coordinates. Need choose recognizable boundary point. Main cardioid cusp at (-0.75,0) or boundary between cardioid and period-2 bulb at (-0.75,0), or seahorse valley near (-0.75,0.1). Use coordinates in 1200x800 viewport. Need map complex to screen. Initial view after fit: css 1200x800, base width 3.2 height 2.5, scale=min(1200/3.2=375,800/2.5=320)=320, complex width=1200/320=3.75, height=2.5. center -0.6,0. So xMin=-2.475, xMax=1.275; yMin=-1.25, yMax=1.25. Map complex (-0.75,0.1) to CSS: fx=(x-xMin)/width=(1.725)/3.75=0.46 => x=552; fy from top=(yMax-y)/height=(1.15)/2.5=0.46 => y=368. Good. Wheel at (552,368) maybe. Browser wheel action supports x,y,delta? Schema action wheel with delta maybe. Use `action:"wheel", x,y,delta: -120` maybe. Need check tool schema: browser action anyOf includes wheel; fields delta, text, toX etc. likely delta. Use.

Interesting action must equal constant? Maybe browser tool only supports listed actions but wheel not available? It listed wheel in description but validation weird maybe action enum constants not matching? Let's inspect perhaps use `scroll` action with delta? Actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No wheel. Use scroll action at x,y delta? Schema scroll. Try action scroll with delta -240.

Oops scroll at coordinates maybe scrolled page? It zoomed but center changed unexpectedly because event coordinates maybe interpreted differently? We expected anchored point (-0.75,0.1) stays at cursor, center should move toward point: factor 1.468, new center = z + (old center - z)/factor = (-0.75 + (0.15)/1.468, 0.1+( -0.1)/1.468) = (-0.6478,0.032). But got center -1.197,0.398, meaning cursor coordinates perhaps not 552,368? Maybe browser viewport not 1200x800? It says coordinates use 1200x800, but maybe actual canvas smaller? Or scroll action delta applied as page scroll and our handler? Wait center -1.197,0.398 corresponds anchor at around? Formula center_new = z + (center_old - z)/factor. Solve z = (center_new*factor - center_old)/(factor-1). factor=1.468, center_old=(-0.6,0). zx=(-1.197*1.468 +0.6)/0.468 = (-1.757+0.6)/.468=-2.472; zy=(0.398*1.468)/0.468=1.25. That's top-left corner! So scroll event coordinates maybe (0,0), not specified? Browser scroll action ignores x/y? It scrolled at top-left. Need use click/drag maybe. Could use `type`? No. Maybe action `motion` can move to x,y then scroll? Let's inspect docs? Not pi docs, browser tool. Try `motion` with toX/toY maybe moves pointer. Then scroll without coords. Schema motion likely pointer motion. Use motion toX 552 toY 368.

Motion maybe just screenshot animation? Need understand tool actions. `scroll` has x,y but ignored? Maybe x,y are viewport coordinates for scroll action but our handler uses event.clientX; perhaps browser scroll dispatches wheel at top-left due no support? Could test click at coordinates then inspect? Click maybe can click reset. Drag can pan with from/to? Schema drag has x,y,toX,toY likely. We can test pan. But first reset via click at reset button coordinates. Need locate button maybe top-left around x=100,y=100. Use click action with x,y.

Click at 100,100 did nothing? Maybe click action coordinates ignored or button not there? HUD at left top, reset button around x=70? Let's calculate HUD top 16, width 330, h1 etc. Reset button y maybe 95, x center 95. Click should reset. It didn't, perhaps browser click action not supported? Maybe actions require `toX`? Hmm.

Could use key? Tab to button then Enter. Use key action maybe. But for verification, can use drag action. Need understand tool behavior. The browser tool likely simulates actions at coordinates, but maybe `click` requires x,y and action constant? It accepted. Why no reset? Maybe button is not at (100,100) due HUD? Let's screenshot? Model doesn't support images, but DOM not layout. Could use `type`? Maybe key action with text "Tab"? Let's try key action.

Maybe browser tool actions are limited and coordinates not applied? The DOM output only, no screenshots due model. Need still verify via code reasoning. But we can use drag action to pan and inspect center. Try drag from 600,400 to 300,400.

Drag worked: center x changed from -1.197 to -0.559 (right by 0.639), y same. Drag distance 300 CSS px left should pan image left? We dragged from x600 to x300 (pointer moves left), view center should increase (image moves left, view center right) by 300/cssWidth * viewWidth. Current view width = initialWidth/1.468 = 3.75/1.468=2.554; cssWidth maybe 1200; dx=-300 => center change = -dx*width/cssWidth = 0.6385. Exactly center from -1.197 to -0.5588. Good. Drag works. Wheel at x,y ignored and used 0,0? Maybe scroll action doesn't support coordinates in this tool. Could test drag to reset? Not needed. We can verify zoom anchor by using drag? No zoom. Could maybe use keyboard? Not implemented. Could use browser `type` to input? no.

Need maybe use `scroll` with x,y but it ignored coordinates due tool bug. Could still verify anchor mathematically in code. But user asks verify zoom into recognizable boundary point and check stays near cursor. We should ideally test with browser. Maybe scroll action's x/y are not event coordinates but scroll viewport? It seems used (0,0). Could use `motion` to set pointer position before scroll; motion didn't change? Maybe motion action is for screenshots, not pointer. Could use `drag` with zero distance? No zoom. Could use `click` on canvas maybe no. Could use `key` to trigger? Not implemented. Could add keyboard zoom with cursor at center, but requirement wheel. Browser tool limitation.

Maybe `scroll` action supports `x`,`y` but our handler's `event.clientX` not set because browser dispatches wheel at center? It used top-left exactly, so no. Could be because x,y fields are for scroll amount not coordinates? Let's inspect tool docs? Not available. Maybe action `scroll` schema has x,y but they are not used? It might scroll at current pointer, and current pointer initially (0,0). `motion` should move pointer but didn't affect maybe because motion is screenshot animation not pointer. Could use `drag` from 0,0 to 0,0? That sets pointer? No zoom. Could use `click` at desired point then `scroll`; click sets pointer position maybe. Earlier click at 100,100 didn't reset because maybe button not at that coordinate? But click may set pointer to 100,100 and click; if button not there, no effect. Then scroll might use pointer at 100,100. Let's test: click at desired (552,368), then scroll. Click on canvas does nothing but sets pointer maybe. Then scroll.

Click triggered pointerdown/up on canvas, endDrag startRender. Pointer now maybe at 552,368. Scroll.

Now anchor? Current before scroll center (-0.55882,0.398087), factor 1.7789/1.468=1.2118. If anchor at pointer (552,368) in current view, compute expected. Current view width=3.75/1.468=2.5545, height=2.5/1.468=1.702? Wait aspect 1.5, height=width/1.5=1.703. xMin=center-width/2=-1.836; yMax=center+height/2=1.2496. Point at (552,368): fx=552/1200=.46, re=-1.836+.46*2.554=-0.661; fy=368/800=.46, im=yMax-.46*1.703=0.466. After zoom factor 1.2118, new center = z + (old center-z)/factor = (-0.661 + (0.102)/1.211, 0.466+(-0.068)/1.211)=(-0.577,0.410). Exactly. Great! So click sets pointer then scroll uses coordinates? It worked. Thus zoom anchor verified. Need zoom multiple times into recognizable boundary point. Current center near (-0.576,0.41), not exactly boundary point? Anchor point (-0.661,0.466) maybe near boundary? Need choose recognizable boundary point. We can compute current pointer anchor after click maybe. Better reset then click at exact boundary coordinate and zoom repeatedly. But click at canvas triggers render; then scroll uses pointer. We can reset via button click. Need locate reset button precisely. Earlier click at 100,100 didn't reset maybe because button not there? Let's calculate HUD layout. At top 16, h1 height maybe 24, stats 3 rows ~? Reset button around y=112? x center maybe 95? We clicked 100,100 maybe too high (stats). Click at 100,120 maybe. Let's use click at 100,120.

No reset. Maybe click action doesn't actually click DOM? It triggered canvas pointer events? It did startRender due endDrag from canvas, so click works on canvas but not button? Maybe HUD intercepts? Coordinates maybe wrong. Let's compute more accurately. CSS at 1200x800. HUD left 16 top16 width min(330,1168)=330. h1 margin 0 0 10, font-size 17 line-height maybe 24 => h1 bottom ~40. stats: grid rows each line-height 1.45*12=17.4 plus gap 4 between rows? Three rows: ~3*17.4+2*4=60.2, margin bottom 12 => actions top ~112.2. Button min-height 34 => center y=129.2. x center = 16+330/2=181. We clicked 100,120 (inside button x? button full width from 31 to 331, y 112-146), should click. Why not? Maybe browser click action only dispatches pointer events on canvas due coordinate scaling? But it did trigger canvas at 552,368. At 100,120, HUD overlays canvas; click should hit button. Maybe HUD element not in accessibility tree? It is. Maybe browser tool's click doesn't support DOM click, only pointer events? It should. Could be button coordinates different due viewport actual not 1200? But drag calculations matched 1200. Maybe click action ignores y? Hmm.

Could use keyboard focus: reset button maybe not focusable via Tab because browser key action maybe not. Could add keyboard shortcut "r" to reset, then use key action text "r". But requirement only button. For testing, add keydown listener maybe useful. But not necessary. Could use drag from reset button? Drag on button might not click. Could use canvas pan to approximate initial then maybe not exact.

Could use browser `type` action maybe types into focused element; no.

Maybe click action requires `toX` not x? But drag used x. Click accepted x,y. It triggered canvas pointerdown at 552,368. At 100,120, perhaps HUD is not actually at those coordinates because browser viewport is not 1200? But drag calculations: before drag center -1.19738, after drag -0.55882, change 0.63856. If cssWidth maybe 1200 and view width 2.5545, dx=-300 gives 0.6386. Yes. So viewport 1200. HUD layout maybe button center y different? Let's estimate from DOM? Could inspect element positions not available. Maybe status "Ready" means no render, but reset would set zoom ×1. Not.

Could click at 181,129.

Still no. Maybe browser click action only simulates pointer on canvas because HUD has pointer-events? It does default. Could be tool's click targets first element under coordinates? Should button. Maybe action `click` not actually DOM click but pointer down/up on canvas only? Strange.

Could use key event by adding keyboard shortcut. Let's add `window.addEventListener("keydown", e => if key r/R reset)`. Then browser key action text "r" might work. But key action earlier "Tab" no effect; maybe it sends key to page but no focus? Window keydown should catch. Let's add for testing and usability. Also maybe "0" reset. Use keydown.

Reload, key r.

Reload reset to initial due page reload. Need wait then click boundary point and scroll multiple times. But now initial. Need choose recognizable boundary point. Main cardioid cusp at (-0.75,0) is recognizable but zooming there reveals? The cusp is a point; nearby boundary detail. Better "seahorse valley" at approximately (-0.75, 0.1) near boundary between cardioid and period-2 bulb? Actually seahorse valley is along negative real axis near -0.75, with spirals. A recognizable boundary point could be (-0.75, 0.1) (near cusp). We can compute screen coords for initial view: xMin=-2.475, width=3.75, yMax=1.25, height=2.5. For (-0.75,0.1): fx=(1.725)/3.75=0.46 => x=552; fy=(1.25-0.1)/2.5=0.46 => y=368. Great. Click at 552,368 then scroll several times. Each scroll action with delta -120 and x/y maybe uses pointer set by click. We can do multiple scroll actions with same x,y. Need ensure click sets pointer and doesn't pan (no drag). Then scroll. Let's wait initial ready then click.

Now scroll at 552,368 delta -120 multiple times. Each factor exp(120*0.0016)=exp(0.192)=1.2118. After 10 times zoom ~7.4. After 20 ~55. Need additional detail. Do 5 then inspect.

Expected center after zoom at (-0.75,0.1): old center (-0.6,0), factor 1.21167 => new center = z + (old-z)/f = (-0.75+0.15/1.2117=-0.6259, 0+(-0.1)/1.2117? Wait y old=0, z=0.1 => new y=0.1+(0-0.1)/1.2117=0.01745. matches. Good. Anchor stays. Do more.

After second, anchor same. Continue maybe 8 times.

Anchor point remains at cursor mathematically. At zoom 6.8, center approaching (-0.75,0.1), iterations 554. Need maybe more zoom to reveal detail, e.g. 20 total. Continue 10.

Great. Zoom 46.5 at near (-0.75,0.1), iterations 1025. Anchor point at cursor remains. Need wait for full render maybe. Then pan view and reset compare. We can use drag to pan. Current center ~(-0.7452,0.0963). Drag from 600,400 to 300,400 should pan right by viewWidth*300/1200. View width=initialWidth/zoom. initialWidth=3.75? At initial fit, yes. width=3.75/46.5=0.0806; change=0.02015. New center ~(-0.7251,0.0963). Then reset via key r. Need verify reset returns center -0.6,0 zoom ×1 iterations 300. Use drag then key r. But before, maybe wait for render complete. Use bash sleep 2 then inspect.

Now pan.

Pan works, zoom preserved, center x shifted +0.02015 exactly. Need wait then reset with key r.

Reset works via key. Need wait and inspect.

Reset verified. Need maybe check initial framing after reset compared to initial: center -0.6,0 zoom ×1 iterations 300, same. Good.

Need check no console errors. Only warning iframe sandbox, not our code. Good.

Need maybe test wheel prevent default? Browser scroll action doesn't scroll page because overflow hidden; handler preventDefault. Good.

Need maybe check code for potential bug in `fitBaseBounds` and initial framing. It expands to canvas aspect, so initial bounds are x [-2.475,1.275], y [-1.25,1.25] at 1200x800. Complete main cardioid and lobes. Good.

Need maybe check "distinct color for points treated as inside set" inside color black. Good.

Need maybe check "smooth escape-time color gradient" yes.

Need maybe check "Use sufficient iterations to reveal new detail as user zooms" iterations grow with zoom. At zoom 46, 1025. Good.

Need maybe check "keep controls responsive during rendering" chunked rAF with 11ms slices and low-res preview. Good.

Need maybe check "Recompute fractal after navigation rather than scaling a static image" startRender samples coordinates, preview and rows. Good.

Need maybe check "Prevent wheel navigation from scrolling surrounding page" passive false preventDefault. Good.

Need maybe check "full-screen canvas" CSS fixed, canvas 100%. Good.

Need maybe check no external assets. No link, no src. Good.

Need maybe check file present. Use ls.

Need maybe inspect final file around modifications to ensure no syntax issues. Browser loaded no errors. Good.

But let's deeply review code for hidden issues and maybe improve. We have time. Need ensure no bug with `initialWidth` on resize after zoom. Suppose initial fit width=3.75. User zooms to width 0.08, initialWidth remains 3.75. Resize window: oldWidth=0.08, oldInitialWidth=3.75, preserve center and oldWidth, set initialWidth=oldInitialWidth. Good. But if resize before initial view? view null, fitBaseBounds sets initialWidth. Good.

Potential issue `fitBaseBounds` uses `canvas.clientWidth || window.innerWidth`; when called from reset, canvas clientWidth is CSS width. Good.

Potential issue `resizeCanvas` sets `initialWidth = oldInitialWidth` but `oldInitialWidth` captured before `if (!view) fitBaseBounds()`. If view null, oldInitialWidth=BASE_WIDTH but then fitBaseBounds overwrites. Good.

Potential issue `startRender` called from `resizeCanvas` before `view`? fitBaseBounds sets. Good.

Potential issue `renderPreview` uses `previewCtx.createImageData` each time; okay.

Potential issue `ctx.createImageData(renderWidth,1)` on resize; okay.

Potential issue `mandelbrotColor` returns `INSIDE_COLOR` frozen array; preview and row set values. Good.

Potential issue cardioid check formula:
q = (cRe - 0.25)^2 + cIm^2. Cardioid condition q*(q + (cRe - 0.25)) <= 0.25*cIm^2. Standard: q = (x-0.25)^2+y^2; if q*(q + (x-0.25)) <= 0.25*y^2. Correct.
Period2: (x+1)^2+y^2 <= 0.25? Standard period-2 bulb center -1 radius 0.25, yes <=0.0625. Good.
These checks speed and mark inside. But points in other embedded cardioids/bulbs not inside by definition? They are inside set but will not escape within maxIterations, so loop ends with x2+y2<=bailout and returns inside. Good.

Potential issue smooth coloring with bailout 16 and iteration count. Standard smooth formula for bailout radius R: `smooth = iter + 1 - log(log|z|/log R)/log2`? Actually for R=2, formula `iter + 1 - log(log|z|)/log2`. For general R, `iter + 1 - log(log|z| / log R)/log2`. We use log(log|z|/log2)/log2, which assumes R=2 (log R=log2). But bailout radius 16, so formula should use log(log|z| / log 16)/log2 = log(log|z|/(4log2))/log2. Using log2 introduces a constant offset of log(4)/log2=2 in nu? Let's derive: correct nu = log(log|z| / log R) / log B where B=2? For smooth iteration count often `n + 1 - log(log|z|)/log 2` for bailout 2. For bailout R, `n + 1 - log(log|z| / log R) / log 2`. We use `log(log|z| / log 2)/log2`, i.e. R=2. Since R=16, difference = log(logR/log2)/log2 = log(4)/log2=2. So smooth values shifted by 2, but modulo cyclic palette so no visual issue except boundary color phase. Smoothness still continuous. Fine. Could correct for mathematical accuracy: `const logBailout = Math.log(16); const nu = Math.log(logZn / logBailout)/LOG2;` But standard formula with base? Let's verify. For z_n escaped with |z_n| large, potential function φ(z) ≈ |z|^(1/2^n)? Smooth iteration = n + 1 - log2(log|z_n| / log R?) Hmm. Common code:
`double smooth = iter + 1 - Math.log(Math.log(zn) / Math.log(2)) / Math.log(2);` with bailout `Math.sqrt(BIGNUM)`? Actually if bailout squared is big (e.g. 1e12), they use `Math.log(Math.log(zn)/Math.log(2))/Math.log(2)`. The bailout radius cancels? Let's derive.

Mandelbrot iteration z_{n+1}=z_n^2+c. For large z, |z_n| ≈ |z_{n0}|^(2^(n-n0)) times. Define ψ(c)=lim |z_n|^(1/2^n). Then |z_n| ≈ ψ^(2^n). log|z_n| ≈ 2^n log ψ. So n ≈ log2(log|z_n| / log ψ). Smooth = n - log2(log|z_n|) + const. The constant depends on bailout? Actually if we stop at first n where |z_n|>R, then |z_n| is between R and R^2 roughly, so using log2(log|z_n|) yields fractional part that depends on R; but constant offset can be absorbed. Formula often `n + 1 - log2(log|z_n|)` for R=2? If R different, constant shift. Since we only use cyclic palette, constant shift irrelevant. Smoothness (continuous across pixels) holds. Good.

Potential issue palette sampling `smooth * (PALETTE_SIZE / 16)`; if smooth around 0-1000, modulo. Good.

Potential issue `samplePalette` returns floats, assigned to Uint8ClampedArray via data[offset] = color[0]; data is Uint8ClampedArray, so rounds/clamps. Good.

Potential issue `renderPreview` draws preview with `drawImage` and then full rows. During preview, `ctx.imageSmoothingQuality="high"` maybe okay.

Potential issue job cancellation: `startRender` sets old job.cancelled=true but doesn't null job until new job assigned. Fine.
`frameId` cancel: if renderFrame scheduled, cancel. If `startRender` called from within renderFrame? Not currently except maybe resize event could fire during rAF callback? Possible. If called inside renderFrame, cancelAnimationFrame(frameId) where frameId is current (already executing) no effect, then set frameId=0 and schedule new. Old job cancelled. Good.
`panFrameId` and `startRender`: if startRender called directly (zoom) while panFrameId pending, panPending remains true and panFrameId will later call startRender again, causing extra render after zoom. Example pointermove schedules rAF, then wheel event occurs before rAF; zoomAt startRender, then rAF fires panPending true and startRender again. This could cause a brief extra render but final view correct. Could clear panPending in startRender to avoid. Add `panPending=false; if (panFrameId) {cancelAnimationFrame(panFrameId); panFrameId=0;}` at startRender. But if startRender called from pan rAF itself, cancel current rAF no effect; setting panPending false before callback? If called within callback, it sets panPending=false then schedules frame; okay. Better. Not necessary but improve responsiveness. Could add.

Potential issue `endDrag` always startRender, even if last pointermove already scheduled; fine.

Potential issue drag pan uses `canvas.clientWidth` each move; okay.

Potential issue pointer capture and click on canvas triggers pointerdown/up; endDrag startRender. Fine.

Potential issue touch pinch: pointer events with two pointers; our dragging logic with single `dragging` and lastPointer will treat second pointerdown as reset last pointer, then moves cause pan jumps; not true pinch. Requirement says "Scroll or pinch" in hint but required only mouse-wheel zoom. It says dragging pans with pointer, mouse-wheel zoom. Pinch not required. Hint mentions pinch but not implemented; could remove "or pinch" to avoid false claim. Or implement basic pinch? Not required. Better hint "Scroll to zoom at the cursor." Remove pinch. But mobile touch drag works. No pinch zoom. Requirement doesn't demand pinch. Change hint to "Drag to pan. Scroll to zoom at the cursor." Good.

Potential issue keyboard shortcut not mentioned; okay.

Potential issue `statusDisplay` and `progressBar` in HUD may intercept pointer events, but canvas below. Wheel over HUD won't zoom because listener canvas only; page doesn't scroll. Fine.

Potential issue "full-screen canvas" HUD overlays part, acceptable.

Potential issue initial view: because canvas aspect 1.5 and base aspect 1.28, we expand horizontally to fill, so initial bounds x [-2.475,1.275], still complete main cardioid and lobes. Good.

Potential issue "Initially show complete main cardioid and surrounding lobes" y bounds exactly [-1.25,1.25], x expanded. Good.

Potential issue at high DPR, renderWidth maybe 2400, renderHeight1600, preview scale 10, low pixels 384k? area 3.84m? Wait renderWidth*renderHeight=3.84m >2m? choose scale 8, low pixels 60k. Good. Full rows 1600, each 2400 pixels, chunked. Good.

Potential issue performance at 4K with DPR2: area 33m? choose scale10, low 830k maybe preview heavy but okay; full rows 2160? Actually canvas height 1600? 4K CSS 3840x2160 DPR2 => 7680x4320 area 33m, choose 10, low 830k, preview maybe 250m ops, could block ~1s. But typical not. Could adapt preview scale more aggressively for huge area: if area > 10m return 16; >5m 12. Let's adjust maybe. At 33m, scale16 =>2m low pixels, still heavy. scale20 =>830k. Use thresholds: >12m 20, >6m 14, >3m 12, >1.5m 10, >800k 8, else 6. But preview too coarse maybe okay. Full rendering at 33m with 4096 iterations could be slow but chunked. Not required. Keep moderate.

Potential issue "controls responsive during rendering" at huge full-res, each frame 11ms; preview synchronous could block for large area. Could chunk preview too, but not necessary for typical. To be robust, we could render preview in chunks as well, but complexity. The requirement likely tested on normal viewport. Fine.

Potential issue no `willReadFrequently` for ctx; not needed.

Potential issue `canvas.getContext("2d", {alpha:false})` and drawImage preview; okay.

Potential issue `previewCanvas.getContext("2d", {alpha:false})` then createImageData and put; okay.

Potential issue `window.devicePixelRatio` can change on zoom; resize event maybe not fired; okay.

Potential issue `MAX_VIEW_WIDTH=100` allows zoom out; wheel factor <1 (scroll up? We use deltaY negative for zoom in, positive deltaY -> factor <1 zoom out). Good. Reset bounds.

Potential issue `MIN_VIEW_WIDTH=1e-10` allows deep zoom but double precision. Fine.

Potential issue `formatNumber` for zoom large uses toLocaleString with max 6, e.g. ×1,025? Actually zoom 46.5. For zoom 1e7, exponential. Good.

Potential issue center display for y uses formatNumber, negative zero maybe "-0.000000"? Could be. Not important.

Potential issue `hslToRgb` with l = 0.53 + 0.08*sin(t*2π), endpoints same (sin0=sin2π=0). Good.

Potential issue palette first and last colors match, interpolation across boundary smooth. Good.

Potential issue inside color pure black and page background #020308, but canvas filled with black inside; distinct from gradient. Could maybe use very dark blue (#000005) to distinguish from outside black? Requirement distinct color for inside; pure black is distinct from colorful gradient. Good.

Potential issue outside near boundary with smooth=0 samples palette hue 0 (red), good.

Potential issue main cardioid check returns inside before iteration, correct.

Need maybe add `aria-live` for status? Not necessary.

Need maybe remove keyboard shortcut if not in hint? Could mention "Press R to reset." Add to hint maybe. Not required. Could keep.

Need maybe test reset button click via browser failed due tool issue, but code listener correct. Could test with `browser.action=click` maybe not working on button due HUD; but key works. We can trust. Maybe browser click action only triggers pointer events, not click? It triggered canvas pointerdown/up but not button click because button requires click event and tool maybe dispatches pointer events only, not mouse click. It did not fire button click. In real browser, button works. Fine.

Need maybe use `browser.action=type` to type into focused? no.

Need maybe check console for errors after all interactions. Inspect shows only warning. Good.

Need maybe adjust hint and pan pending. Let's make small improvements.

Need reload after edit to ensure no errors and initial ready.

Wait then inspect.

Need final report concise but include what checked and unverified. But before final, maybe ensure file is self-contained and no external resources. Already grep. Need maybe mention browser tool couldn't render screenshot due model, but DOM/status checked. We should report actual checked behaviors:
- initial load: HUD zoom ×1, center -0.6,0, iterations 300, status Ready.
- zoom at boundary point near (-0.75,0.1): repeated wheel scroll at same coordinates; zoom increased to ×46.5, iterations 1,025, center moved as expected and anchor remained at cursor (verified via HUD math). Additional detail rendered (status Ready after chunked rendering).
- pan: drag left 300px shifted center by expected amount while preserving zoom.
- reset: pressed R (keyboard shortcut) and HUD returned to ×1, center -0.6,0, iterations 300, Ready; reset button listener present but browser tool's click didn't trigger DOM button click in this harness? We should be honest: Reset button code wired; verified reset via R because harness click did not activate button. But user asked Reset view; we can say reset behavior verified via keyboard shortcut, button click handler is wired but not exercised by harness? Maybe we can try to verify button via dispatching click using browser? No eval tool. Could maybe use `type` action after focusing button with Tab, but key action didn't seem to send. Maybe browser `key` action sends to canvas? It did r and window listener caught. Could focus button with key? Tab didn't. Maybe because key action text "Tab" not recognized; could use text "Tab" maybe not. Not worth.
- wheel default prevented via passive:false; no page scroll.
- console only sandbox warning, no JS errors.
- visual screenshot unavailable because browser model doesn't support images; so actual pixel appearance unverified, but DOM/status and computations checked.
Need mention full-resolution rendering is chunked with rAF and low-res preview, so controls responsive (observed status rows updating and interactions during render).
Need maybe mention file path.

Before final, maybe check line count and ensure no accidental syntax issue after edit. Browser loaded. Good.

Need maybe consider if user expects no keyboard shortcut? It's extra, fine.

Potential concern: The addendum says "Run the application in the browser and inspect the initial output and console. Use the available browser tools for a brief pass through the representative checks in the task, focused on readily accessible behavior and remaining time budget. Fix clear problems you discover and recheck affected behavior. Save final file, then briefly report what you actually checked and which behaviors remain unverified." We did. Need final with checked/unverified.

Potential concern: We used `browser.action=scroll` to simulate wheel; it dispatched wheel event? Our handler responded, so yes. It used coordinates after click set pointer. Good.

Potential concern: We added keyboard shortcut after verification; reloaded and checked initial. Good.

Potential concern: We didn't verify reset button visually due tool click limitation. But code is straightforward. Could maybe verify by using `browser.action=click` with `toX`? Maybe click action expects `toX`? Let's inspect schema: browser action click has x,y,toX,toY? It accepted x,y. Maybe button not clicked because HUD has `pointer-events` default but tool's click dispatches pointer events to canvas only? Wait at 552,368 canvas click triggered pointerdown and endDrag startRender. At 181,129 HUD button, no startRender because button doesn't have pointerdown listener; but if click event fired, reset would happen. It didn't. So tool's click likely only dispatches pointer events to canvas, not DOM click? Maybe it dispatches mouse events at coordinates but button's click should fire. Unless HUD is not hit because browser's click action targets the canvas element specifically (maybe it always targets main canvas). So cannot verify button. Fine.

Could use `browser.action=key` with text "Enter" after focusing reset via mouse? No focus. Could add `document.getElementById("reset").focus()`? Not. Could use keyboard shortcut only.

Potential concern: Keyboard shortcut listens on window and triggers reset even if user types in an input; no inputs. Fine.

Potential concern: `event.key === "0"` might reset unexpectedly if user presses 0; no inputs. Fine.

Potential concern: "Prevent wheel navigation from scrolling surrounding page" we preventDefault on canvas only. Since body overflow hidden, no surrounding scroll. If HUD wheel, page still no scroll due CSS. Good.

Potential concern: "Use Canvas 2D or WebGL and procedural colors" yes.

Potential concern: "No third-party libraries are provided" we use none.

Potential concern: "Compute Mandelbrot set from complex coordinates" yes.

Potential concern: "distinct color for points treated as inside the set" black. Good.

Potential concern: "sufficient iterations to reveal new detail as user zooms" iteration formula maybe at zoom 46 only 1025; enough. At zoom 1e6, 4096 maybe maybe not enough but cap. Could increase cap to 8192 for deeper detail, but performance. Requirement says sufficient; 4096 is reasonable. Could use 6000 cap? At deep zoom, more detail but slower. 4096 standard. Good.

Potential concern: smooth coloring with bailout 16 and maxIterations 300 initial; many points inside set return black. Good.

Potential concern: initial complete main cardioid and surrounding lobes: x expanded to -2.475..1.275, y -1.25..1.25. Yes.

Potential concern: pan formula y direction: verified drag x; not y. Could test drag vertical to ensure correct. Use drag from 600,400 to 600,300 (pointer up) should center y decrease? Current after reset. Let's test maybe. After reset initial center -0.6,0. Drag from 600,400 to 600,300 (dy=-100) should pan image up, view center y decreases by dy*height/cssHeight = -100*2.5/800=-0.3125 => center y -0.3125. Then reset. This verifies vertical. Use browser drag.

Vertical pan correct. Reset again.

Wait.

Good.

Need final answer with no more tool calls. Mention file saved. Keep concise but enough. Desired oververbosity 5. We can structure.

Need be honest about visual pixel verification unverified due screenshot model doesn't support images. Also reset button click not exercised by harness? We can phrase: "The Reset button is wired to the same resetView(); in this harness I exercised reset via the R shortcut because the browser tool's click did not dispatch a DOM click to the button." Is that too much? The user asked verify Reset view; we should mention. Maybe they don't care about harness limitations, but report actual. We can say "Reset behavior checked (via R shortcut; button handler is the same resetView function)." Good.

Need mention no console errors except sandbox warning. Good.

Let's final.